Mastering Bug Reporting: Tips & Best Practices for Effective Communication

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.

1. Reproduce the Bug and Be Specific

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

1. Log in to the portal (test environment).
2. Use the following credentials: Email - abc@email.com, Password - 1234 (Admin user).
3. Click on the "ADD ONE" blue button at the top right of the screen.

Helpful Tips:

• Add the environment/branch/device where you were testing.
• Add all specifics that are valid to the bug, this can be helpful for developers to debug it.
• Be as specific as you can, some buttons can be similar, or a new team member can get lost in the app.

2. Provide Context

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.

3. Report with Evidence

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:

1. Right-click on the screen to open the context menu. Result:

2. Select the "Inspect" option to open the developer tools. Result: 

3. Depending on the issue, navigate to the relevant tabs, with the "Network" tab being the most common one for backend calls. Select the specific call you want to inspect. Result:

4. Depending on the finding, you want to check different tabs, the most common one is the network tab, which is for the calls made to and from the backend. Select one of the calls like the one indicated here:

5. Additional tip: Most common information is Headers, Request headers, Response Headers, Payload, and Response. You can copy the information by right-clicking on the call and by selecting the option Copy, you will see all the information options. Like this:

4. Prioritize and Classify Bugs

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.

• Critical: Issue that causes complete system failure or severely impacts core functionality. So the user can’t use an important feature or even the whole app.
• High: Bugs that significantly impact essential features or cause major usability issues. Meaning that the user can’t use some features, or can tell that something is definitely not working.
• Medium: Bugs that affect non-essential features or cause moderate usability issues. So is something that we can improve for the user, as is not working completely as expected. 
• Low: Bugs that have minimal impact on functionality or usability and may be considered minor inconveniences. This is normally used for small visual issues, or small bugs that the user might not even notice what the issue is. 

5. Use a meaningful name

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

6. Use Templates

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:

USER:

ENVIRONMENT:

3. ‍

RESULTS:

• Actual:
• Expected:

EVIDENCE

(Photo or video)

In case you need additional information, you can also add it independently:

• ‍HEADERS:
• ‍REQUEST HEADERS:
• RESPONSE HEADERS:
• PAYLOAD:
• RESPONSE:

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.