SUBSCRIBE TO MY CHANNEL

Five Test Automation Mistakes to Avoid - Must watch for testers!

How to be successful QA leader? - Future leaders, QA Leads and Managers

LATEST THINKING

Friday, March 20, 2015

HOW TO WRITE AN EFFICIENT BUG REPORT

12:13:00 AM Posted by Prashant Hegde 2 comments

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.

SeveritySeverity 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.

  • 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.

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. 
Annotate the bug and represent the area of the bug by encircling it. 
It's a good practice to attach a screenshot even if you are adding a video. Always rename the screenshot appropriately. Rename the image to the bug id or add the relevant name. The screenshot name should not be something like "q34dasef.jpg" Rename the image as "IB-432.jpg"(Bug id) or as "Alignment_issue_Settings"(describes the bug).

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. LogsThe 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:
SummaryiOS - 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 ResultsThe 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.


WorkaroundUser 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




2 comments:

Unknown said...

Hi,
I've read the post, it gave very brief explanation about preparing the bug report. I've an query regarding reproducing errors, It said that If the bug you encountered is not reproducible then it will never get fixed. Hence, we can detect the non-reproducible bugs and fix them can't we?

Prashant Hegde said...

"If the bug you encountered is not reproducible then it will never get fixed"

As a tester one should not only just find bugs but should be capable of reproducing the bug he has found. Your bug report must specify the exact steps that will lead developer to the bug. Your bug will get rejected if it cannot be replicated from the bug report you have written.

Sometimes bugs are inconsistent and are hard to replicate. If replicating a bug is difficult mention its occurrence(Consistent,Frequent,Occasional,etc) with your test environment and detailed steps.Try to recall if you had done something special to detect that bug.

Popular Posts

Total Pageviews