I bet you’ve been in a situation where you caught a bug, reported it and then your team member (Developer) says: “Hey, I can’t reproduce it. It’s working on my machine”. Those situations are interesting for me. When I hear that from a developer I always wonder: “Is the issue still present in the new build? Hmm… I better re-test it to be sure.” So I re-test it again, confirm that it is present, and add more information so it is easier to reproduce the bug.
Why should you file a bug report?
- To point out that there is an irregularity, or unexpected condition which does not satisfy a particular requirement.
What is the goal of a bug report?
- To document all bugs found in the appropriate project management tool. While this doesn’t necessarily mean all will be fixed, it documents the bugs. It will then be up to the product owner to decide whether a bug should be fixed immediately, moved to next release, or moved to a backlog.
In this post, I will explain what makes a solid and useful bug report for mobile applications. In order for a developer to reproduce the bug, (s)he needs information. When a developer does not need to ask you for more details about the reported bug then you have done your job well. Before opening a new bug report in your project management tool, you should pause for a second and think what info you would need if you are reading that ticket for the first time. The goal is to be understood. Every detail in there must help a developer to identify/locate where the bug is and the cause of it. In this case, minimalism does not apply. Less is not more. Also, too much info is not needed. You should write just enough information. Information that should be contained in a useful bug report, includes:
1. Title
2. Description
3. Exact steps you have made
4. Environment
5. User credentials
6. Screenshot and/or Screencast
7. Specific
8. Console Error
9. Severity/Priority
1. Title
Brief, should give insight on the issue. A few examples:
[Feature] – Description (error message if any)
Example:
1. [PERFORMANCE – ADMIN] Closing of ‘Section A’ list is taking ~25 seconds
2. [SEARCH] Error message thrown upon opening ‘My Bills’ (WRITE_HERE_NAME_OF_ERROR)
3. [API] ‘Submission Date’ is missing from the ‘Bills’
4. [iOS] Screen is sliced (not responsive) on ‘Savings’ screen
5. [Accept – Reject order] User is not able to accept/reject order. Error is thrown (order_ref)
2. Description
Should be short and descriptive. Describe more about the issue. No need to write a novel. Be concrete and keep it to a maximum of 5 sentences.
3. Steps
List all of the particular steps you have taken to cause this bug. When a developer follows these steps they must be able to reproduce it.
Example:
Steps
1. Navigate to the app and login as Edmond user
2. Navigate to Orders -> Draft
3. Swipe-left on first draft
4. Tap Delete button
5. Choose 2nd Delete Reason
6. Type random text in Delete Description
7. Tap Delete button (first error)
8. Tap for the second time Delete button (403 error – permission denied)
4. Environment
Should contain:
- Name of the Branch you have tested on
- Build number
- Device name and model
- OS version of the device
- Network connectivity and screen orientation (if relevant for particular issue)
Example:
Tested on:
iOS (branch ABS-123login/ Build 414)
Device:
iPhone6 (10)
5. User credentials
Write username and password of the user
6. Screenshot/Screencast
Sometimes developers can get more from a screencast than all of the text you wrote. So make sure to attach this. In some project management tools there is a limit of 10MB per attachment, depending on the package your client has purchased. Therefore, you need to have lightweight option. You can accomplish that, by recording a GIF. A 1 minute GIF can be less than 2MB depending on the screen size and frames per second.
For recording GIF: LICECap
For screenshot: Lightshot Screenshot
7. Specific
Any additional useful information, specific to your type of app. If the app is intended to have multiple clients with their own specific rules and setups. For instance registration code, pass-code, company code, and so on.)
8. Console Error
Errors thrown in the console can give immediate context to the developer about what might have gone wrong. Therefore, make sure that you connect your device to your computer and take a screenshot of the error that is thrown in the console.
You can do so by following these steps: Inspect mobile apps via browser
9. Severity/Priority
How urgent is the issue? Is the client waiting on this? How will the issue impact the user?
Based on these questions, and depending on the tool you use for reporting the issue, you may choose how urgent and what the level of seriousness is.
Example:
Blocker – no progress on the task is possible
Major – program crash or freeze, no workaround
Critical – serious but has a workaround
Minor – visual defect, typo or grammar
Trivial – no customer impact but doesn’t meet an aesthetic or internal standard
Conclusion
I have seen bug reports explaining very little to the developer. Saying “It’s not working,” without adequate information is just going to waste developers’ time. By being concrete, clear and providing the right information, a developer will have what he needs to fix the issue. Remind yourself that the purpose is getting stuff done. As a tester, after you asserted that core functionality is working as expected you should test the limits. While testing, think of the worst possible scenario that might happen to the end-user and test that, question everything. There could be an interesting bug hiding. Before submitting a bug report, read it and ensure you would understand it if reading it for the first time. By following the steps outlined, you will be respectful with your teammates time.
Please share your bug reporting ideas with us. Tell us what you think about the article and what you would add to make a bug report useful.
