10 Important points to note while Reporting a bug
Whatever you call it, A bug report or A defect report! It is the QA who makes it Good or worst. A good bug report will effectively help software testing by clearly identifying the problem thereby driving the entire project towards solving it. A badly written report can lead to serious misunderstanding and hijack the project in the wrong direction.
Here are 10 important points a QA needs to note while creating an effective bug report:-
- Is it a bug? The question seems very simple! This is a very basic; yet important question while identifying a bug. Ask questions to yourself, why is it a bug? What went wrong? Note down the actual result and the expected result. If you are not sure about the bug; compare your test case with the user story/requirement. If the requirement does not cover the scenario; raise a query to the development team.
All the reporting platforms and tools (Saviva uses Jira!) have the query feature. Based on the response, the query can be converted into a bug for reporting purpose and documentation.
2. Is your bug title clear as crystal? To explain a bug in 300 words should be comparatively easier than giving a 60-character title to the bug. However, for millennial who tweet with up to 280 characters, this is going to be an interesting challenge. “Alignment error in Transaction history screen” could become a very common title, camouflaging a critical error in the description. “App crash” is too small and might create a panic situation. Similarly, “Verification failed” has less clarity.
3. Have you explained the Bug to the point? To explain the bug in detail does not mean to write a Book! Use the correct nomenclatures, jargon, screen names, system, component, feature, type of test, type of device, test environment etc. It is important to give the right level of information to the developer, not dump them with too many unwanted details. The only tool required to write a bug description is Common sense!
A bug report must be clear enough to help developers understand the failure, including information about what QAs see, and a statement of what they expect to see. It should detail what went wrong. QA can use the following check list while writing your bug description:
- Version tested
- Steps to reproduce the bug
- Actual result
- Expected result
- Supporting attachments
- Device & version of device used (If bug is device specific bug)
- Browser tested (if bug is browser specific)
- Assumptions (Active login used / inactive account used for testing)
4. Screenshots / Attachments: Always include a screenshot of the examples of a failure highlighting a defect. This simplifies the work of developer who fixes the issue. Show some discretion while attaching screenshots:
- Name the screens shots appropriately, Not “image7890.jpg”
- If you are attaching a series of screenshots, Number them accordingly. Don’t keep the developers busy puzzling your screenshots.
- If you are attaching screen recordings/videos, keep the videos short. Do not attach Shot films.
- If the bug is simple to reproduce, avoid too many attachments that distract the developers.
5. Report one issue per bug raised: Do not club multiple defects in a single bug! Trust me, we have seen too many confusions because of this. Clarity also entails addressing only one problem per task. There could be 3 different error that occur during 1 transaction. If these 3 errors are reported as 1 bug; there is a possibility that the developer can miss out on addressing 1 out of the 3 errors reported, thereby not allowing QC to close the bug. It will also create confusion during evaluation of the efforts of development team.
Of course! The development team is going to hate us for reporting 3 bugs in the place of 1 bug, even though they fall under the same category.
6. Refer open bug report: Before you raise a bug, check if the same/similar bug has already been found and reported. Every bug you find cannot be verified with open bug report. So, before you start testing and as a part of preparation, go through the Previous bug reports if available. A bug that was previously identified and fixed could resurface in the latest version. As an expert in your area, if you could mention the history of the earlier fixed bug; it could save a lot of time and effort.
Using your bug reporting tool, link the earlier bug for reference.
7. Categorize your bugs. Most of the reporting tools have the label feature to categorize the bugs based on the type. Saviva’s QC team tested FarmTrek Mobile app and created bugs based on their app type. The labels that we created were based on 1. App type 2. User persona type 3. version etc. This way we could pull the Open bug report in Jira based on these labels.
8. Prioritize your bugs. Is the bug blocking the entire feature, or is it just cosmetic? Is the bug blocking an entire set of test cases that has to be tested? What is the risk of the bug to the project or business? These questions will help you arrive at the right level of priority and severity for each bug. A bug report with the correct priority/severity assignments will go a long way to establish a ranked pipeline of defects for the project team to fix sequentially.
Prioritize the bugs as Critical / Major / High / Minor. Some QAs usually play it safe by marking all the bugs as High. There is a huge risk in this behaviour where you might miss out on highlighting a Major bug or Have the development team work on minor bugs instead of addressing the most critical bugs which are critical to business.
For example: A simple drop down not working could be a High priority bug in general. However, because the drop down is not working, a series of test cases are blocked — This is a Major issue.
9. Should you give your opinion? A good QA will verify the bug report with every component in the check list and make sure the bug is Short and sweet and to the point! Sticking to facts will help you craft a clear and concise bug report. If you do have opinions on how the product should be designed or should have been built, Well ! . . .Please keep that for Retrospectives and other feedback mechanisms designed to collect constructive inputs. The bug report needs to focus on describing a verifiable issue with the sole purpose of fixing it. Nothing else!
10. Keep your personal agenda Aside! As a professional QA whatever be the state of your mind, do not take it out on the developer through the bug report. Having handled a QC team, I am sure the QAs evaluate themselves by the number of bugs identified or reported. Your skill set is not proportional to the number of bugs you identify. Any personal preferences or seeming inferences to the code quality or an individual, need to be kept out of the bug report. Your bug report must be diligent, impeccable and entirely based on facts.
A high-quality bug report is the true expression of a tester’s skill set. You should take pride in crafting a perfect bug report every single time. Remember, A developer is silently thanking you for giving him/her a chance to fix a bug they may have created in the first place. And the entire team will thank you for making it easier to fix bugs and deliver the final product to customers promptly.
Bug Reporting Tools: The are a handful of automated testing tools that have built-in integration with bug-tracking systems. They can automatically report the bugs and track their status. There are also separate bug reporting tools like JIRA or Mantis.
To receive our updates and latest news, Please join us.
Website: https://saviva.co/
Medium: https://medium.com/@savivaofficial
Twitter: https://twitter.com/savivatech
Facebook: https://www.facebook.com/savivatech
LinkedIn: https://www.linkedin.com/company/saviva-technologies
Instagram: https://www.instagram.com/savivatechnologies/
