The most important skill which is expected from a tester is to write a bug report. Several times testers overlook this most important trait. A bug report needs to be short and yet should not miss any essential information that might be needed to fix the bug.
A good bug report is the one that describes the problem well enough that anyone related to the project will easily understand the report without the need to speak to the person who wrote it. An effective bug report helps the developers to fix bugs quickly.
Before moving to bug reporting lets quickly look at the components of the bug report.
Severity : Severity is the impact of the bug on the application. A tester should be capable of figuring out the severity of the bug. Severity can be of the following types:
- Blocker: A blocker issue prevents from performing further tests.
- Critical: A critical bug maybe something like a crash or data loss.
- Major: A major feature or functionality is not functional.
- Minor: Minor loss of function.
- Trivial: UI/Spelling mistakes.
- Enhancement: Request for new feature or some enhancement in existing one.
Test Environment
Never miss to specify the environment where you found the bug especially for compatibility issues.
- Browser/Device: Mention the browser/devices in which the bug was observed.
- OS: Mention the OS in which the bug was observed.
Summary
Summary should be concise and yet descriptive.Summary should describe the problem as best as possible. Summary is read more often than any other part of the bug report. Summary should be written in such a way the reader should be able to understand the problem without looking at the description of the bug.
Bug's can relate to different teams that are associated with the project. Its essential to include the type of bug in the summary line. This will help the developers to identify the type of the bug by looking at the summary itself.
Bug Categories: Bugs can be categories as different types :
- Crash
- Freeze/Hangs
- Functional
- Backend/DB
- Performance
- Compatibility
- Usability
- Design
- UI
- Typographical/text errors
Frequency :You might have come across the inconsistent bugs while testing. It's important that you report such bugs. Mention how often does the bug occur. Developers must be informed the frequency of the bug as well so that developers can focus on more consistent bugs first and then move on to less frequent bugs.Its a good practice to include the consistency in summary of the bug.
Before moving to bug reporting lets quickly look at the components of the bug report.
Severity : Severity is the impact of the bug on the application. A tester should be capable of figuring out the severity of the bug. Severity can be of the following types:
Severity : Severity is the impact of the bug on the application. A tester should be capable of figuring out the severity of the bug. Severity can be of the following types:
- Blocker: A blocker issue prevents from performing further tests.
- Critical: A critical bug maybe something like a crash or data loss.
- Major: A major feature or functionality is not functional.
- Minor: Minor loss of function.
- Trivial: UI/Spelling mistakes.
- Enhancement: Request for new feature or some enhancement in existing one.
Never miss to specify the environment where you found the bug especially for compatibility issues.
- Browser/Device: Mention the browser/devices in which the bug was observed.
- OS: Mention the OS in which the bug was observed.
- Crash
- Freeze/Hangs
- Functional
- Backend/DB
- Performance
- Compatibility
- Usability
- Design
- UI
- Typographical/text errors
Frequency :You might have come across the inconsistent bugs while testing. It's important that you report such bugs. Mention how often does the bug occur. Developers must be informed the frequency of the bug as well so that developers can focus on more consistent bugs first and then move on to less frequent bugs.Its a good practice to include the consistency in summary of the bug.
- Consistent (10/10) - A consistent bug can be replicated every time the test is executed.
- Frequent (7/10)- A frequent bug can be replicated like 7 out of 10 times when a test is replicated
- Occasional (5/10) - Occasional bug is more hard to replicate than a frequent bug.
- Once thus far, twice thus far - Few bugs cannot be reproduced every time you run the test.
Expected result: Write how application should behave as per the requirements. In this section you should write what the right behavior of the application should be according to the requirements.
- Consistent (10/10) - A consistent bug can be replicated every time the test is executed.
- Frequent (7/10)- A frequent bug can be replicated like 7 out of 10 times when a test is replicated
- Occasional (5/10) - Occasional bug is more hard to replicate than a frequent bug.
- Once thus far, twice thus far - Few bugs cannot be reproduced every time you run the test.
Example: The user should be directed to 'Home screen' when tapped on 'Home' icon.
Actual result: Write how it deviates from requirements.Explain what happened when the bug occurred.
Example: The user remains in the same page when tapped on 'Home' icon.
Workaround: Explain the steps in which the occurrence of the bug can be avoided. This helps the costumers and other testers to continue using the app without encountering the bug until the bug is fixed.
Example: The user can return back to 'home screen' by tapping on device's 'Back button' from any screen.
Steps to reproduce: If the bug you encountered is not reproducible then it will never get fixed. Remember these guidelines while writing steps to reproduce:
- The steps should start from launching the app and end with the action that causes the problem to be visible.
- Include any relevant configuration steps or preconditions that are needed to replicate the issue.
- Keep every point short and must have essential have one action.
- Verify if the bug is replicated following the steps you have written.
Note: Any extra detail you want to mention in the bug report.
Example:Screen orientation: Landscape Network: AirCel 3G
Attachments: A visual representation of the bug can help the developer understand the problem even more quickly. Attachments act like a proof for your bug. If you’re writing a bug for an UI issue its a must to take the screenshot of the nug and attach them to your bug report. Annotate your bug and represent the area of the bug.
The following are different attachments that you can include in your bug report:
1. Screenshots: Add screenshots to illustrate UI issues. Annotate the bug and represent the area of the bug by encircling it.
- The steps should start from launching the app and end with the action that causes the problem to be visible.
- Include any relevant configuration steps or preconditions that are needed to replicate the issue.
- Keep every point short and must have essential have one action.
- Verify if the bug is replicated following the steps you have written.
 |
| Annotate the bug and represent the area of the bug by encircling it. |
2. Videos: Attach videos for the cases where steps involved in replicating the bugs is complex.Below are few tips:
- Ensure that you perform actions slowly while recording the bug so that developers can understand the replicating steps.
- Actions in the video should match the steps listed in the bug report.
- Compress the videos to reduce the file size before attaching them. Make sure you do not lose quality when you compress the video.
- Ensure your disable the sound in the video (If taken from a camera).
- It's a good practice to show the touches in the videos so that the developers know the taps you did while demonstrating the problem.
3. Logs: The crash logs can also be attached with the bug report. This helps the developers to find the root cause quickly.
Pro Tips
- Check if the bug is known or already reported by someone
else.
- If you have multiple issues, it is better to file them
separately so they can be tracked easily.
- Enter build version number for every issue. Else you may not
remember in which build where the issue was reported.
- Reproduce the bugs few times and then proceed to write the
"steps to reproduce" .Your bug should be reproducible when developer
follows the steps you have written.
- Read bug report before you submit the bug: Read the entire
report before you submit a bug. Ensure you have entered all the required information.
Spell check for mistakes. Get rid of confusing sentences if any.
- QA is a constructive process. Never criticize the developer
for the bugs .Communicate findings on the product in a neutral, fact-focused
way without criticizing the person who created it.
- If you do not know which developer to assign the bug then
assign it to the development lead.The lead will assign bug to the concerned
developer.
It is not easy to convey a bug in short yet in an effective
way.The skill of bug reporting will improve only with practice and
experience. It's crucial for the testers
to cultivate the habit of writing good bug reports and they should also enforce
their fellow testers to do the same.
I highly recommend that every organisation should standardize
the way of bug reporting. This keeps consistency in bug reports and also helps
the developers to analyze the bugs in one glance.
Below is a example for
standardized bug report template:
Summary: iOS - Compose – Consistent – Crash – The app crashes
upon tapping 'compose' button.
Test environment:
Product: Demoapp
Build Version: 1.0#39
Devices: iPhone
6
OS Version: 8.1
Severity: Critical
Description:Consistently, in inbox, if the user taps on 'compose' button on the navigation bar then the app crashes.
Expected Result:The compose screen should open upon tapping the
‘compose button’.
Actual Results: The app crashes upon tapping on the ‘compose button’.
Steps to Reproduce:
1. Login to the Demoapp.
2. Wait for the 'Inbox' screen to load.
3. Tap on 'compose' button and observe that the app
crashes.
Workaround: User can compose a mail by choosing 'compose' option from the red bug icon at bottom of the screen.
Note:
Screen orientation: Portrait Network: Airtel 4G
Logs:
ContactViewController.m line 599__57-[ContactViewController
configureCell:forRowAtIndexPath:]_block_invoke
I highly recommend that every organisation should standardize
the way of bug reporting. This keeps consistency in bug reports and also helps
the developers to analyze the bugs in one glance.
Below is a example for
standardized bug report template:
Summary: iOS - Compose – Consistent – Crash – The app crashes
upon tapping 'compose' button.
Test environment: Product: Demoapp Build Version: 1.0#39 Devices: iPhone 6 OS Version: 8.1 Severity: Critical Description:Consistently, in inbox, if the user taps on 'compose' button on the navigation bar then the app crashes. Expected Result:The compose screen should open upon tapping the ‘compose button’. Actual Results: The app crashes upon tapping on the ‘compose button’. Steps to Reproduce: 1. Login to the Demoapp. 2. Wait for the 'Inbox' screen to load. 3. Tap on 'compose' button and observe that the app crashes. Workaround: User can compose a mail by choosing 'compose' option from the red bug icon at bottom of the screen. Note: Screen orientation: Portrait Network: Airtel 4G Logs: ContactViewController.m line 599__57-[ContactViewController configureCell:forRowAtIndexPath:]_block_invoke |
