Monday 5 September 2011

Non Reproducible Defects

Non Reproducible Defects:

Defects that occur during specific events or conditions can be hard to reproduce. Since its very important to find out the exact steps to reproduce before you log a defect. Below are the steps you could follow. 
1) Recollect the series of actions that you performed in order to uncover the defect. Repeat the same steps at least 2 times before you conclude that the defect is not always reproducible. 
2) Try with the same set of data. If you cannot use the same data then you could try with data that has similar properties of the once which uncovered the defect. 
3) Check application logs to see what were the other events that were occurring at the time when the defect occurred. So that you can get to know if any other user’s actions was responsible for this defect to surface. 
4) Some of the defects show up during first use only. Confirm this defect does not fall into that category. You can use softwares like Drive image (from www.powerquest.com) or Ghost (from www.symantec.com) or any other software that can help you to re-image. 
5) Some of the defects that are hard to reproduce could be caused by “Racing condition”. Racing condition is a situation when there are 2 or more threads/processes that are running in parallel and competing or the same resource (file or database table) etc., they could be trying to lock the same resource or they could be manipulating data required by other process. e.g.:- Two processes trying to update same file. So one of the updates can timeout and eventually fail as a result file update was incomplete. In this case defect occurred because these were 2 processes trying to update same file almost at the same time and this defect would not occur if 2 processes tried to access the file at different times (difference in order or few milliseconds). 
6) Check if the defect occurs during specific time. e.g.:- calculation goes wrong during 0th second of a minute etc., 
7) Defects could arise due to Memory leaks, corrupted stack etc.,. You could check application or Operating System logs for error related to memory or stack. If you suspect problems are due to memory leaks then check the Memory utilization of the test PC/server. You can also use some of the softwares available in the market for checking memory leaks like Bounds checker (from www.numega.com) or Purify (from www.rational.com) or any other software than can monitor memory usage. 
8.  As a final resort, approach developer who has coded the concerned module or functionality, explain him/her the steps that uncovered the non reproducible defect. So that he can give you some clues on what could be causing the problem and you can use the hints provided by the developer to nail down the exact steps that help in finding exact steps for reproducing the defect.

No comments:

Post a Comment