Application ServicesSoftware DevelopmentDigital
Article • • 3 minute read

How to Investigate a Bug

Learn how investigating a bug can lead to improvements in the final product, the production process or product documentation.

A bug might be something you found in testing, in automation, something reported by a customer, by development, by the product owner, or by someone from another team. The issue might be in documentation, specifications, test plans, user stories on the Kanban, production code, test code, system setup, etc. At the very least, investigating can lead to a better understanding of the product. At best it can help improve the product or the production process or documentation. 

How do you investigate? It is helpful to consider the following:

  • Could this be tester error?
  • Could this be correct behavior?
  • Is this problem, or some variant of it, already known?
  • Is there someone else who can help with this?
  • Is this worth investigating right now?
  • Do we know enough right now to report it?

If you are using a bug tracking system, it's always a good idea to see if the issue, or anything similar, has already been reported. Or, ask the other members of your team to see if it is a known or expected issue.

If you investigate further, you should set out to identify and isolate the conditions that produce the bug and minimize the number of steps or conditions needed to make it occur. Sometimes the same bug can be encountered from several different "directions" coming from the same root cause. Make sure not to mis-identify these as separate defects as they would then need to be resolved as duplicates. The more you can focus in on your bug, the more useful your bug report will be. Also make sure to test "around" the defect as bugs tend to cluster.

Reproducible

Not all bugs are straightforward to reproduce. Intermittent bugs may need additional digging to find out why they are so shy. Bugs that cannot be reproduced are not a complete write-off. You sometimes need to play a longer game. Move on to something else but keep an eye on this area.

Severity 

It is also important to evaluate and report the severity of the problem. How likely is it to be found by a customer or to impact a customer? Is it cosmetic or functional? Is it blocking further testing? A bug that blocks testing in an area might be concealing the presence of further bugs and would need urgent resolution so testing can continue.

Priority 

It is not directly a tester's function to evaluate priority of addressing the defect. This is more of a team decision depending on what else is in the backlog. It might be handled by addition to an existing feature story. Otherwise it might get added as a new bug fix story that will need to be inserted to the backlog and then groomed.

Resolution 

  • Not a bug? Then is the product clear enough to be generally understood? Can better clarity be achieved by rewording? Adding a tooltip? A better icon?
  • Fix? If a fix is done, it will need to be tested, validated, and any follow-on testing tasks completed.
  • Don't fix? It could be the case that the rework effort is too great for the gain. It could be a candidate for inclusion in a readme, release notes or a wiki entry.