How to Write A Bug Report with Examples

What is Bug Report? Why do you need a good 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.

Your software development engineer can be made aware of all the defects and issues present in the software using this type of report. It also lets you figure out what’s wrong with a bug, so you can use the best method to fix it. It also helps you to save your time and money by helping you catch bugs and issues.

Why should you care about good bug explanations?

Good Bug Explanations

Here is the point that you need to consider for writing a good, detailed software bug report:

  • It acts as a guide to help avoid the same bug in future releases.
  • Save time for communication (e-mails, calls).
  • Less work for developers (they will do exactly what you want).
  • You will have less bottlenecks in the project; bugs will be fixed faster and more efficient way.

How to Write Bug Report (Bug Report Template)

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.


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


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


  1. Select product X1.
  2. Click on Add to cart.
  3. 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.

9) 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.

Tips for Bug Report Writing

Here are some important tips that you should remember while writing an effective bug report:

  • Be specific when creating bug reports. Make sure you don’t include any useless or irrelevant facts.
  • You must report the bug immediately as soon as it gets detected.
  • Prepare the report in detail to empower the developer to use the facts and the information to debug the issue.
  • You should test the same bug occurrence on other similar modules for validation.
  • Review the bug report at least once before submitting it.
  • You should ensure that the bug report contains the description of only one error.
  • Lastly, you should not be afraid to ask the Project Manager for help if you feel unclear about something.

Bug Reporting tools

The bug reporting process, performed manually, is now being performed with various bug reporting tools available in the market.

You can check our detailed review of the best bug reporting tool.

Common Problem and Solution while Writing a bug report:

Here are some common problems and their solutions while writing a bug report:

Bug Report Example Problem
When multiplying 2 by 3, the answer will be positive. Report the pattern, not an example.
The list will be ordered alphabetically when adding a new item to avoid this. Don’t only describe what’s wrong
For example:
To being, you will need to open your browser and type the site’s URL. You’ll find the first field, ‘username,’ misspelled.
Always direct to the point (Never tell the story!).
The client’s name in the report is misspelled. Priority: High, Severity: High Never mix priority and severity.
The tax calculation formula is INCORRECT !!?? Does not use CAPS, red letters, red circles, ‘!’,
I don’t think that the home page Ul design is good. Don’t use your judgment.
Example of unclear description: About our discussion today, please do the required action for this page. Make your description understandable for everyone.
The page background should be blue, orange, or green, or you can make it black or white.

This is not good as it is unclear what is needed from the web development and design team

Minimize the options
The tax calculation formula is sometimes not working as expected. The golden rule: Don’t use the word ‘Sometimes’.

Example of Bug Report

Here is a small example of a bug report:

[MY ACCOUNT] Underline is displayed when mouse overing on the Update button.

Description: We need to remove the underline when mouse overing on the Update button in My Account section.


Browser/OS: Chrome 25. OSX Yosemite 10.10.2

Steps to reproduce:

1. Go to

2. Login via login credentials

3. Navigate to My Account

4. Mouseover on the Update button

Actual result: there is an underline.

Expected Result: no underline.

Login Data: / mysecretpass12

Must avoid mistakes in bug report writing

Here are some important mistakes that you should avoid while writing a bug report:

  • Don’t write about your dissatisfaction, and never include your personal feelings.
  • It annoys people who want to focus on the task when you overload your post with many emoticons.
  • Never overload your post with exclamation points; it does not speed up the work.
  • Nobody wants to feel offended. It destroys motivation and slows the realization of the issue.