Bug Report
Bug Report Definition
By ISTQB glossary the definition of a bug report is a document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function.
Why Do We Need A Bug Report?
Bug Report is an important document in STLC that offers various advantages to the testing team. It keeps track of all the defects, multiple bugs, errors, and other discrepancies found during software testing and reports them.
The purpose of this post-testing documentation is to provide information to the concerned team of professionals about the level of bugs encountered during the testing process.
How to Write Bug Report
There is no exact bug report template, as it depends upon your bug-tracking system. Your template might be different.
However, the following common fields are always needed when you want to write a bug report:
- Bug id/ Title
- Severity and Priority
- Description
- Environment
- Steps to reproduce
- Expected result
- Actual result
- Attachments (screenshots, videos, text)
Let’s look at all these bug-tacking components one by one:
1. Title/Bug ID
Every bug should be given a unique identification number. Bug reporting tools should be unique numbers for the newly raised bugs so we can easily identify the bug.
Examples
Bad: “I can’t see the product when I again, tyrp it doesn’t.”
- Vague
- Aggressive
- Too wordy
asks for a solution to be implemented.
Good: “CART – New items added to the cart that does not appear”.
- This kind of Title instantly locates the issue (CART)
- It focuses on the actual technical problem.
2. Bug Severity
Bug severity is a very important factor in the bug report. It describes the effect of the defect on the application’s performance.
- Blocker: This error causes the app to fail.
- Major: A critical error indicates a major change in the business logic.
- Minor: An issue that doesn’t affect the application’s functionality but does affect the expected results.
- Trivial: It does not affect the functionality or operation of the app. It could be a typographical error.
3. Bug Priority
Following is the general gradation to decide bug priority:
- High It covers anything which affects the flow or blocks app usage.
- Medium: It adversely affects the user experience.
- Minor: All other errors like (typos, missing icons, layout issues, etc.).
4. Environment
A Bug can appear in a specific environment and not others. For example, sometimes a bug appears when running the website on Firefox, or an app malfunction only when running on an Android device and working fine on iPhone.
These bug reports can only be identified with cross-browser or cross-device testing. So, when reporting the bug, QAs should be able to specify if the bug should be observed in one or more specific environments.
5. Summary
However, adding only the Title in the bug report does not serve the purpose. So, if your Title isn’t enough, you can add a short report summary.
Your summary in as few words as possible including when and how the bug occurred. Your Title and bug description should also be used in searches, so you must ensure you have covered important keywords.
Examples:
- Bad: “I was trying to add stuff to the test, and nothing showed up when I did that or clicked on the button.”
- Good: “When I tried adding [PRODUCT] to the shopping cart, but nothing happened when I clicked the 'add' button on the specific product overview webpage.”
6. Steps to reproduce
When reporting a bug, it is important to specify the steps to reproduce it. You should also include actions that may cause the bug. Here, don’t make any generic statements.
Be specific on the steps to follow:
Here, is an example of well-written procedure:
Steps:
- Select product X1.
- Click on Add to cart.
- Click Remove to remove the product from the cart.
7. Expected result
In bug reports, describing the expected result per the technical task, test case outcomes design, or according to the tester’s opinion is important. All this helps developers to focus on quickly finding needed information.
For example:
Required fields should be highlighted in red after clicking the” Submit” button.
8. Actual Result
As it names suggests, this s field describes the actual effect of the bug. It is very important to write a clear description of the actual result.
For example:
Required fields are highlighted in green color after clicking the “Submit” button.
8. Attachments (screenshots and videos)
In bug reports, it is best practice to attach files to bug reports which makes it easier to perceive information when you need to display it visually:
For example:
- Screenshot: Screenshots can easily elaborate mistakes in the program; s convenient when the bug is highlighted with a specific annotation, circle, or arrow image.
- Video: Sometimes, it is difficult to describe the bug in words, so it’s better to create a video so that developer can rectify the defect in the program.
10. Affected Version:
It is the affected software version where the bug is reported.
11. Fix Version:
It is the software version in which the bug is resolved. So when the QA who reported the bug, checks whether it is fixed, he uses the correct software version.
12. Target version:
The target version where a bug should be targeted to be fixed. So, when the development team works on fixing a bug, they mostly target a particular application version.
13. Date Closed:
It is the date when the bug is closed by the software testing team. Closing a bug is a vital and integral part of software testing.
14. Status:
When a new bug is created, its status should be open. After that, it goes through stages like In Progress, Fixed, Running, Reopen, etc.
Example of Bug Report
Here is a small example of a bug report:
[MY ACCOUNT] Underline is displayed when mouseovering on the Update button.
Description: We need to remove the underline when mouseovering on the Update button in My Account section.
Link: http:\\test.website.com
Browser/OS: Chrome 25. OSX Yosemite 10.10.2
Steps to reproduce:
- Go to www.test.com
- Login via login credentials
- Navigate to My Account
- Mouseover on the Update button
Actual result: there is an underline.
Expected Result: no underline.
Login Data: test@test.com / mysecretpass12