Tips to write a quality bug report

Tips to write a quality bug report

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.

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.

Bug Categories

Bugs can be categories as different types :

  • Crash
  • Freeze/Hangs
  • Functional
  • Backend/DB
  • Performance
  • Compatibility
  • Usability
  • Design
  • UI
  • Typographical/text errors

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.

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. 

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:

Below is a sample Bug report:

Summary

Compose – Consistent – Crash – The app crashes upon tapping 'compose' button.

Test environment

Product:  Demoapp          Build Version: 1.0#39

Device: 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’.

Workaround

User can compose a mail by choosing 'compose' option from the red bug icon at bottom of the screen.

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.

Note

Screen orientation: Portrait

Network: Airtel 4G  

Logs

ContactViewController.m line 599                                                                               57-[ContactViewController configureCell:forRowAtIndexPath:]_block_invoke

 

 

Claude Martinet

President at Pass NetZero | Carbon Capture Innovation

8y

In the case you found this pages, and is thinking about report a bug to Linked-in, you should know that they don't give money award. Even for big security issues. Visit my profil to see the post I made after informing Linked-in : Claude Martinet - 李徳

Prashant Hegde

Engineering Manager(QA) at MoEngage Inc | Software Testing Leader | International Speaker | Avid Blogger

9y

Priyaranjan Mohapatra: Thank you. I am glad that you came up with the point regarding priority. The tester is not the ideal person to assign the priority of the bug. The priority should ideally be set by the project manager or the stakeholders. A bug triage meeting is conducted in the presence of the costumer representatives and the priorities of the open bugs are decided.

Priyaranjan Mohapatra

Test Lead | PSM1 (Professional Scrum Master) Certified

9y

The Article is good. Just i would like to include one point to the above and that is priority. A Priority has to be set for the defect.

Like
Reply
NARAYANAN PALANI 👁️🗨️

Platform Engineering Lead | AWS ,Azure ,Google Cloud Certified Architect | Cloud Solutions Expert | Driving Innovation in Retail, Commercial & Investment Banking | CI/CD | DevOps | Cloud Transformation

10y

good article

Like
Reply

To view or add a comment, sign in

More articles by Prashant Hegde

  • IS TEST AUTOMATION A SILVER BULLET?

    QA plays a crucial part in product quality and product delivery. In agile development methodologies like scrum, QA…

    16 Comments
  • ARE YOU STILL USING OLD-SCHOOL BUG LOGGING PROCESS?

    REPORTING BUGS CAN BE REALLY PAINFUL! A good bug report is the one that describes the problem well enough that anyone…

    8 Comments
  • Mindmap: A killer way to increase your test coverage.

    What is a mindmap? A mindmap is a diagram used to visually organize information. It can be called as a visual thinking…

    32 Comments
  • 7 Myths of Software Testing

    Myth 1: It is the QA team’s mistake that the defect was missed. Reality: Whenever a defect is missed the QA are assured…

    7 Comments
  • Pair testing: Fight bugs together!

    In rapid development processes like agile methodology its important to identify and prevent the bugs in earlier stages…

Insights from the community

Others also viewed

Explore topics