Bug reporting is a crucial part of the software development process. It helps all team members to coordinate deliveries of good quality. When ineffective bug reporting is present it can lead to misunderstandings, a significant increase in time spent, and even delivery failure.
More than feature quality, as a QA you should pursue quality and efficiency in the project. To achieve that, here are some tips to become a master in reporting bugs, and avoid back-and-forth chat with developers.
You have to make sure what you found is indeed a bug, reproduce it multiple times, in different environments, and if that is the case, try for similar features.
Write all the steps you followed those times, including even the obvious, always thinking that a new team member could be the one that is reading and you have to take them from the beginning.
Include all the places where you found it, some features have components used in different places, so make sure it is failing everywhere you think it exists. This would help the developers to fix them all at once, so you do not have to report this again and they do not have to ask.
Here is an example:
STEPS TO REPRODUCE
You are the one that knows what's happening, remember you are responsible for making others understand what the problem is. Add all the relevant information, like the time zone; if you were on a different screen before, how fast you were clicking, if it failed exactly the fifth time every time, even if it failed when the size of the screen was exactly 400px.
By knowing this you can help developers easily find out the issue and have the ticket back in your column.
Here is an example:
Actual behavior: I am able to see the "ADD ONE" blue button at the top right of the screen when the screen size is 375px. However, when the screen size reaches exactly 400px, the button disappears.
Keep in mind this is both ways. As you report what is currently happening you should also say what is exactly being expected. Writing “It should work fine” is not helpful to anyone. This is not written only for you, it is for the whole team, from the developer who is going to fix it to the next QA who is going to test it, and even to the prod owner who wants to verify it.
Expected behavior: The "ADD ONE" button should be visible with consistent design across all mobile devices but should disappear only in the Tablet view.
Take all evidence and as complete as you need to show the real issue, sometimes a photo can not say much to someone that does not know about the problem. When collecting evidence, it's crucial to provide quality material that helps others understand the bug. Utilize your mouse to highlight important information and leverage drawing tools to illustrate specific details. By doing so, you ensure clarity and enhance the effectiveness of your communication.
And of course, do it both ways! If you are saying that something is expected, attach some evidence to support it. A screenshot of Figma with a drawing, or the link to the requirement document (specifying where), or again, a screenshot. Therefore, you can contribute to the entire team, to save time and energy.
For web apps: If the bug can have additional information in the console (developer tools) sometimes in the network tab, this can also be very helpful. Provide those error traces that deliver valuable insights into the bug's root cause, so the developer does not have to try to find it, you already have it there! Here is where to look for the proper information and a tip to add to Jira tickets:
Let your team know how important the bug is, so the developers can work on the highest priority first and help to move the showstoppers first.
This is a standard classification based on the severity and the impact that the issue will have on a user.
Having all the bugs on the board can be a mess if they do not have meaningful names, adding something general could cause confusion and a bug can be left behind. When you add names try to summarize the important things that can help others to identify what the issue is about and how severe it can be. Or if a dev is working on that feature, they will know the bug is meant to be fixed by them.
This is a name example for tickets:
Bad name: Issue with Button
Good name: Login Button Disappears on Mobile
Amazing name: Login Button Disappears on Mobile Devices at Screen Width 375px
The best thing you can do is to have a template with the information you already know your project and team need, from the devs to the product owners as final testers. You can create your template even on Jira so others can use it.
I have created the following comprehensive template by combining elements from various sources and tailoring it to reflect my experience:
(Photo or video)
In case you need additional information, you can also add it independently:
Mastering bug reporting is a crucial skill for QA professionals as it enables them to uphold product quality and facilitate clear communication with developers. By becoming proficient in bug reporting, you can streamline the process, minimize discussions and misunderstandings, and ultimately enhance the overall software quality. The success of the team relies on the commitment of each team member to continually strive for improvement. That way, you can make a significant impact together as a team.
We’d love to learn more about your project.
Engagements start at $75,000.