What if, you are trying to understand a technical document for a long time but the result is null. Irritating! Isn’t it?
Yes! Same is the case when a tester writes a lengthy bug report but a developer is getting nothing out of it. Expertise matched with perfect communication is the key to success.
A good tester maybe able to find show stopper bugs, but if s/he is not able to articulate it well then the developers would miss it and in the end create chaos. So, as a tester you need to understand the importance of effective communication while reporting a bug.
The objective of bug report is that, it must help to reproduce the problem with minimal efforts and help the developer debug and fix the problem. The good bug reports must contain most of the information precisely required to reproduce, analyze, debug and fix the problem. At times, the tester thinks that this is an obvious bug and pulls out on providing complete information assuming that developers would be smart enough to understand it automatically. But, this is just contrary to what testers at QAGENIC are taught during the rigorous training they undergo before been put before the client to work. Here we teach to provide each and every necessary detail in bug that would make it simpler for the developer to understand and fix it in one single go.
The best time to compose the bug report is only when we get the bug in the application. At that time we are aware of every fact, so the chances of missing any fact in the report are quite less.
While composing a bug, the following things should be taken prompt care of:
Before calling it a bug, make a double check to ensure that it’s not working as stated down in the baselined requirements.
Once you have concluded that it’s a bug, start to dig down to find the root cause for the same. There may be various paths leading to the root cause, but finding and fixing each and every path is not an intelligent procedure. Rather finding and fixing the core issue would resolve the bug on all the possible paths once for all.
Search the Bug Tracking Tool for duplicity:
Before reporting a bug, make a close search in the bug tracking tool using intelligent keywords to check whether that bug already exists or not. It may be reported in some other way or as comment in one of the earlier reported bugs, so make sure that you avoid the duplicity.
It should be simple, clear and precise. Should connect to the actual problem and must grab developer’s attention.
Steps To Reproduce:
Before providing the steps of user actions, describe the state of application and prerequisites. The steps for user actions should be logical and non- redundant. A tester should also try to club a few steps into one if the total number of steps is high.
Environment Tested Upon:
It is important to cite environment the application was tested upon at the time you found the bug. It also helps finding the root cause of the issue.
- Content manifesting: Details about what content the bug is reproducible on
- Content Non–manifesting: Details about what content the bug is NOT reproducible on
- Configuration manifesting: Details about what configuration the bug is reproducible on
- Configuration Non – manifesting: Details about what configuration the bug is NOT reproducible on
While performing QA activities, we generally come across some bugs which are not reproducible each time & every time. So, it is important to capture evidence around such issues when they happen, so that it would be easier to find the root cause. Provide the following as part of bug report
- Labelled screenshots
- Screen recording of the issue
- Any kind of log files
- The struts
Expected Behaviour & Actual Behaviour
It’s very important to document what behaviour the application shows after executing the steps to reproduce and then providing the expected behaviour of the system under test, gives a clear comparison as to what deviation happened which has made it call a ‘bug’.
At times you come across similar bugs but they relate to different functionalities in the application, so the best way is to log them as individual bugs and link them to each other. Nesting of bugs may eventually lead to a part of the bug to be fixed, while the remaining still reproducible and in that case a QA engineer cannot close it or re-open it.
The purpose of a bug report is to show the failure to developers so that they can resolve the bug and ensure better product quality. And while writing a bug report, the aim of the tester should be to provide clear and precise information across the board. Holding onto the information or providing way beyond what is needed is not considered a good bug report. Before you hit that submit button, and ask yourself if you have included all of the above information or not.