The summary is a general description of the bug. It gives a quick overview of the issue encountered during the tests and is the equivalent of the subject of an email.
It is necessary to give as much detail as possible on the environment, the context, in which the bug happened: the browser used and its version, the OS used and its version, the device brand, the model…
It will also be required to provide the version of the product and database tested, and if the tests have been carried out in production, pre-production or during acceptance phases.
Which devices have been affected by the bug?
- Description of the observed behavior
The nature of the defect has to be clearly explained. If a developer investigating the bug can’t understand its details, it is very likely that the report will be sent back to the tester to be completed with more explanations and details. This will cause delays in the bug fixing process.
The description thus has to contain all the necessary steps to reproduce the bug, as well as the step at which the defect was spotted. When this part is well documented, there will be no going back and forth between the testing teams and the teams in charge of carrying out the necessary corrective actions and the bug fixing turnaround time will be faster.
- Description of the expected behavior
In order to facilitate the understanding of the defect by the teams in charge of making the amendments, it is important to document the description of the expected behavior versus the observed behavior during the testing phases.
If the bug found is reproducible, it should be mentioned along with its occurrence (Does the bug happen every time?).
The severity of the defect is an element that makes understanding the impact that the defect can have on the systems and the business easier. The severity is assessed by the tester and is generally ranked on a scale of 3 levels. Those levels are chosen by each organization.
- Blocking: the defect can potentially cause serious damage and there is no solution to go around the issue. For example: an application doesn’t open and causes the OS to crash.
- Major: some major functionalities are missing or don’t work and there is no solution to go around the issue. For example: an application doesn’t display certain image formats.
- Minor: some functionalities of the application don’t work or a defect causes inconveniences, but a solution exists to go around the issue and it can be used as a temporary solution. For example: the user has to click on a GUI (graphic user interface) button twice to trigger the desired action.
The incidents also have to be classified by type: textual, graphical, functional, technical and ergonomic.
An organization can also choose to add an additional classification: suggestions. This will allow testers to provide improvement suggestions. For example: a tester wishes to suggest the improvement of a GUI element.
Once the severity of the bug has been analyzed, the implementation of the changes to be conducted has to be prioritized. Priority helps to determine the speed at which the defect has to be fixed. This is set in accordance with the importance of the business impact of the defect. The priority is often categorized in 4 or 5 levels, ranging from high (the modification has to be carried out immediately) to low (the modification has to be carried out at the next release).
A defect that has a high severity will also have a high priority. Hence, a critical defect will have a high priority in order to be resolved as fast as possible. However, a defect can have a low severity but a high priority. For example, there can be spelling mistakes in a text: the severity won’t be major as there will be no damages caused from a technical point of view. However, from a reputation and brand image point of view, this issue will have to be solved quickly.
In case an organization relies on external providers to carry out its tests, this part will generally be conducted by the client directly. Project managers or product owners will prioritize the defects internally according to their vision of the product and of the potential business impact.
Justification of the defects have to be recorded and make up a crucial part of reporting. Those visual explanations are key: they help justify the anomalies encountered, allow for thorough documentation and give the developer cues to better understand the situation. It is thus recommended to add logs, crash reports, videos and screenshots of each step of the testing phase as well as of each anomaly.
Giving special attention to the bug reports during the testing phases allows for the optimization of the time spent by developers to conduct the necessary changes. It makes the creation of a database possible, which will be used to establish KPIs that are essential to monitor the testing phases (Read our article : Mobile applications, setting KPIs).
You're interested in optimizing your test campaigns, watch a video of our tool :
