Radoslaw Rozkowinski is the author of this article. He is a Software Quality professional who likes to share his thoughts with others in order to help them conquer the testing world. And he has some top-quality advice for you!
Bugs are the bread and butter of the tester. Every day you encounter a lot of incorrect application behavior or issues that you may find even at the stage of reading the documentation. As we all know, incorrectly designed business paths are the greatest threat to the production of good quality code and, above all, the release of fully functional products to the market.
Many people can say that reporting a bug is very simple and does not require sophisticated knowledge, but is it that straightforward?
Several very important elements have a significant impact on whether a reported bug is properly understood by other people. It must contain precise information that allows them to recreate it. The bug report should clearly state what the problem is and what the correct behavior should be.
Let’s look at the elements one by one and learn together how to write a legendary good bug report!
Title (Summary)
Often underestimated, treated as unnecessary, and carelessly designed, the title is more important than you may think. Why? Because Backlog owners, before they dig deeper for more details about the issue, see only the title. Think of Management tools, like Jira: what do you see when you look at a Backlog list? And how about filter results? A board? Dashboard? No description, custom fields, screenshots, videos – the only visible element is the title. If you don’t want your bug to go unnoticed (and I bet you don’t!), the title has to stand out.
How to write a good title? Its other commonly used name is ‘summary’ – and this is exactly what the title should be. It should be long enough to inform about the nature of the bug with a reasonable level of detail, but not so long that it makes the description redundant.
Consider the following title: ‘Issue with settings button’
Is it a good title? No. Why? It doesn’t tell what the issue is. It states that there is some problem but it is too generic. Although it mentions the problem area, it is barely possible to guess the severity of the error and prioritize it correctly. It could mean anything: the button could be of the wrong color, may be inactive or maybe there is no button at all.
Now compare it to this one: ‘Settings button turns to an inactive state when user clicks on its right edge’
Better? Obviously. The summary now tells exactly what the problem is, and allows for prioritization even without looking into details.
Description
As a rule of thumb, the more relevant information in the Bug Report, the better. Note the word ‘relevant’ – it is the key. You should provide all the information to the extent that makes issue investigation and fixes easier.
The most important elements of the description are:
- Steps to reproduce the issue, with a detailed description of how the problem occurred
- Actual vs expected result
Why did I stress the ‘relevance’ so much? Because too much information may be as bad as too little. Let’s look at the following example, referring to our title:
‘Steps to reproduce:
- Open the application and navigate to Personal Panel
- Open user settings and change the avatar
- Save the avatar
- Attempt to set the day of birth in the future
- When declined, leave the user settings
- Close the app
- Re-open the app
- Navigate to Personal Panel
- Click on the right edge of the Settings button
Result: The Settings button turns to an inactive state, while it should not’
At the first sight, the above looks correct, i.e. the steps are clear, detailed, and unambiguous. Do you agree? Or maybe red flags, one after another, are raised in your head. Wait a minute… Do I really need to close and reopen the app for the bug to occur? What do my avatar and date of birth have to do with this button? And if I don’t attempt to change it? Do I need to make these steps in the same sequence…? YES. You are right. These steps smell fishy.
Assuming our summary in the previous paragraph was unambiguously designed, I would expect something like this:
‘Steps to reproduce:
- Open the application and navigate to Personal Panel
- Click on the right edge of the Settings button
Result: The Settings button turns to an inactive state, while it should not’
All the other steps, which the tester might have performed before the issue occurred, are just unnecessary noise, which blurs the real problem. It is the reporter’s task to narrow down the steps to reproduce. A good description should contain only those which are required for the problem to occur. No less, but also no more than this.
Device / Browser
Although it sounds obvious and self-descriptive – testers often forget about various details. Remember: devices not only have names, but they also have software versions, and specific resolutions, sometimes (depending on the project) there may be specific settings configured, flags turned on, etc. The type of network connection also counts (throttling is a type of testing itself).
The same regards browsers – it’s not only the name, but it is also the version, type of operating system the browser runs on, resolution, addons installed – everything may be important!
Environment
It refers to the testing environment, i.e. staging, development, UAT, production – and any subtype/version of it (depending on the project). Remember to add an application version! A really good bug report would also contain information about whether the bug is a regression issue (i.e. first occurred in the latest version of the app) or is a problem that existed in the previous versions but slipped through testing. This is very important to know. If the bug has just occurred, then it’s easier to figure out what caused it (i.e. one of the latest changes), but if the bug is not new (already existed in previous production stages) then the prioritization may not be that immediate.
Attachments
It is a common problem, especially in multicultural environments, that things are lost in translation. Wording and phrasing may vary across the team and add to the general level of ambiguity. How to handle it? Use a common language: screenshots and video recordings. Whenever in doubt, bug reviewers will watch the video of the issue, and ensure that they understood the problem correctly.
When providing an attachment, the same rule as for the description applies: do not attach irrelevant information! Imagine a 5-minute video showing the whole process of user’s registration, crawling through the app, and trying multiple scenarios, only to show in the last 5 seconds that the Settings button turns inactive! Attach only the 5-second section of the video that is relevant.
Priority / Severity
These are often mixed up, with an incorrect assumption that severe issues are automatically given the highest priority. In the Bug Report, you are unlikely to be expected to set the Priority – it is usually assessed by either the Product Manager or the Triage board.
But you are most likely expected to set the issue’s severity. How do you do this? Most teams have a predefined scale with the described meaning of each level. Here is a simple example of such a list:
- Critical – Complete loss of service or resources, work cannot reasonably continue; major functions unusable; crashes;
- Major – Significant defect or deviation from the expected functionality with a barely acceptable workaround
- Minor – a small defect where an easy workaround is present; cosmetic problems like misspelled words or misaligned text
Aaaand that’s it. It is not rocket science but it does require your attention and assessment skills. If the above elements are correctly written – the report is outstanding. Your bug is a story of quality, and the story needs some quality as well.
