top of page

Bugs and reproducing them

Whenever a new bug is found, the tester will need to create a defect in the defect tracking system they work with. This defect needs to contain clear steps to reproduce the problem, so that developers can identify the root cause of the issue. Here are some tips regarding bugs and reproducing them.

  1. Make sure you reproduced the problem at least 2-3 times. This helps to clearly identify what the steps to reproduce are, and maybe to get some additional details regarding when the issue occurs. This also helps to validate that the issue did indeed reproduce itself, before further investigation will be done.

  2. If you can't reproduce the problem several times, don't just assume that the bug occurs randomly. It is very rare for a bug to occur randomly, simply because each user action translates into a specific set of lines of code being executed each time the user performs the exact same action. The following questions can help you figure out why you can't reproduce the issue:

  3. Are you doing the same steps you did when you first reproduced the bug? Sometimes when you find a bug you are surprised by its' presence, since you probably wanted to test something completely different. Therefore you might not be doing the exact same steps in the exact same order as you did when you first encountered the problem.

  4. Are you using the same input data or type of input data as the first time? Sometimes you cannot reproduce an issue because you are not providing the same type of input data to the system as you did the first time you encountered the issue: if you sent Strings, did you send any special characters? If you sent numbers, were they integer or did they have decimals?

  5. Is there any proof in the logs that the issue occurred? If you can't figure out how the issue can be reproduced, you can at least take a look at the logs to see more information there. First of all, you could check that there was an error or an exception at the time you saw the issue. Then, you might even find some hints regarding the steps or the input data you used when you first encountered the issue. This can help in retrying to reproduce it.

  6. Is the application deployed to several servers? It might be that one of them is misbehaving. If they are behind a load balancer, it might be that the request you made when the issue was encountered was hitting the misbehaving server, but all the other attempts were hitting different, properly working ones.

  7. If you cannot reproduce the issue at all by using the exact same steps and the exact same type of input data as the first time, the cause of the issue might be a not very obvious one, like: a network glitch, a temporary DB lock or some kind of hardware issue.

It can happen that the bug that was encountered cannot be reproduced due to the root cause having a very short duration or being so infrequent that the bug was spotted only by chance. If the priority of the bug, or the inconvenience that it causes to the users are very high, it is very much advisable to investigate all the possible leads one might have regarding its' cause, so that it can be fixed before production customers will find it themselves.

Recent Posts

See All

Creating an Architecture for Your Automated Tests Writing Automated Tests in Small Increments 4 Times Your Automation Passed While Bugs Were Present Now That You’ve Created Automated Tests, Run Them!

This week my newest article was released, this time on how to use Log4j to log relevant test automation information:

bottom of page