Home     RSSRSS

Posts Tagged ‘Bug’

Checklist for Troubleshooting Web Application in Internet

March 6, 2013 by kiranbadi1991 | Comments Off on Checklist for Troubleshooting Web Application in Internet | Filed in Browser, Development, Environment, Quality, Small Businesses

One of the hard things of troubleshooting the production issues is to identify the root cause of the issue. When the application is deployed in the open internet and accessed by the variety of the browsers, and has large number of hops in the network, it becomes quite a challenging task. So in this post I will walk you through the list of things which needs to be checked at high level on client side in order to identify the root cause of the issue and before proceeding to do the review of the code base.

Browser Setting

  • What is the proxy setting of the browser, does it access the application via proxy or connection is directly to the internet.
  • How is browser configured? Does the user have administrative rights or he has basic rights on the browser settings.
  • Is the browser configured to show user friendly messages? If Yes than can we reproduce the issue by removing those user friendly messages and just displaying the actual message which application is throwing.(Please note if your application does not do proper error handling, there exists a risk that you are displaying nasty code to the users. E.g. Famous yellow screens of the .net)
  • Is the browser configured to run in standard mode or compatibility mode? This point applies to IE. (Ajax and UI Issues are most often related to compatibility mode)
  • In case the issue is related to certificate, then checking whether the relevant certificate is present in trusted store often helps.
  • If your application uses popup windows to display some information, then checking if there are any add on or setting in browsers which is blocking pop ups also helps. Some browser add on silently block pop ups without giving any information to the users.
  • Is the browser setting on default? These are the setting which is factory default. One of the easiest ways to troubleshoot issues is reset the browsers to default setting.

Client Computer Settings

  • Is the client computer behind the firewall? If yes than verifying that it’s correctly configured saves lot of time.
  • Checking the antivirus software installed on the client machine also helps. Sometimes in case where your application uses specials character, there exists a chance that badly configured antivirus might filter out or block the incoming responses.
  • Hardware and software configuration of the user’s machine. In case if your application does lot of heavy lifting on the client side, then it often helps to educate the users that minimum configuration needs to be met.

Network Infrastructure and configuration

  • Is the network correctly configured? Using the bidirectional ping command often helps to identify the network issues.
  • Is the client able to resolve the application host name correctly?
  • Checking how many hops the user needs to make to connect to the server also helps
  • In increasing user experiences. General Thumb rule I often use is more the hops user does to connect to the server, more the response time he is going to get.
  • Is there any load balancer or firewall between the server and client? If yes than checking if they are correctly configured also helps.

User access or Login Issues

  • Is the user giving the right credentials and if yes then checking if server is doing correct validation of credentials also helps.
  • Is the identity and access validation done by application or by third party component like Site minder? If by third party, then checking the third party component in isolation often helps.
  • Does the user have appropriate access level to access the resources? If yes then further troubleshooting is required. Else its waste of time.
  • If browser is client, then disabling friendly error message settings in browser will reduce the time to identify the issue by almost 50% since no extra debugging tools are required unless the case if of missing or stolen headers.

Tags: , , ,

Tips to Reproduce the Performance Issues

May 23, 2011 by kiranbadi1991 | Comments Off on Tips to Reproduce the Performance Issues | Filed in Development, LoadRunner, Quality, Scripting

Whenever the performance tester logs an incident for performance issues, the first questions ,development team asks is “ how to we reproduce the incident “ and sometimes they often refuse to agree that there exists any performance issues in the application for the simple reason that incident highlighted is often not reproducible in their environment.

There exists a norm in software development industry that if the incident logged cannot be reproduced by the tester or by the person highlighting it, then it cannot be resolved or solved for the simple reason that not enough information is available to resolve the issue or understand the issue.

I believe that performance incidents are hard to reproduce and do not often occur under functional or manual environments, so it becomes real hard to say as what really happened to the application under load. But however there are some features which most load testing tools provide which can help the performance engineers to reproduce the defect and to know as what the inputs were given to the application at that point that triggered the issues to surface under load test.

In order reproduce the incidents, performance engineer’s needs to have understanding of the functionality of the application along with technical details of the application. In case if the information is not available, then he needs to ask this information with relevant stakeholders before logging an incident. This really helps so that everyone involved stays in the same page. So in this post I would be highlighting some of the features which LoadRunner provides which when used effectively can be helpful in reproducing the incidents.

LoadRunner provides rich set of features which can be used for reproducing incidents which often cannot be reproduced manually, below are some the setting,

  • Enable Snapshot on Error: This feature I believe was introduced in 8.x versions of LoadRunner. Whenever the error occurs, it takes the snapshot of the page and saves it in Vuser logs. However it needs to be enabled in the run time setting of the script. Often snapshot or screenshot are the ones development team requires to believe that error has indeed occurred. So I suggest this feature needs to enabled if you believe that you have some performance issues in the application. However please do keep in mind that enabling this also consumes the LG’s resources.
  • Logging Functions: LoadRunner provides rich set of functions that can be used to log messages to file. However I prefer to use out put message function and disable logging completely. By using output message function (lr_output_message) function, I don’t need to have complete logging enabled, and I see all information which I want to see. I also suggest logging all the correlated values along with user defined parameters using output message function for the reason that under load, one can really find out as what values were given ,what values were captured from the server response and what values were not captured. Once we have the data from output message function, we can reuse the same data and try to reproduce it manually.
  • Extended logging: LoadRunner also provides us the features wherein we can see client request made and server response received from the servers. There might be some cases where in we would like to see as what request client has send that triggered the error in the application under load, in such a cases extended logging can be enabled. However please do note that it impacts response time and consumes lot of load generator resources. Extended logging in LoadRunner helps us to see as what used defined data parameters were used, what response was send by the server and extended trace of the function calls made by the LoadRunner. In short, it shows you the complete trace as what flows in the wire for the user. However this requires the performance engineer have sufficient knowledge to read and interpret the data captured.
  • Iteration Number: LoadRunner provides the feature wherein users can log the iteration number. Under load, each user does many iteration and uses many data points from the user defined data files; it becomes really confusing to know what data was used in which iteration while reproducing the error. So I suggest that one needs to log iteration number along with parameter used in the script either in the beginning of the action block or depending on the requirement. Iteration number along with logged information when correlated with snapshot on errors helps in most of the cases to come out with clear knowledge of the issue found.

However there are some cases of incidents where in spite of having all information, one might not be able to reproduce the incident. For such cases, I suggest that you isolate the scenario and run it having the relevant stakeholders monitoring at their respective ends.

Tags: , , ,