How to Write a Good Bug Report? Tips and Tricks

Why a good Bug Report?

If your Bug report is effective, then its chances of getting fixed are higher. So fixing a bug depends upon how effectively you report it. Reporting a bug is nothing but a skill and in this tutorial, we will explain how to achieve this skill.

“The point of writing a problem report (bug report) is to get bugs fixed” – By Cem Kaner. If a tester is not reporting a bug correctly, then the programmer will most likely reject this bug stating it as irreproducible.

This can hurt the tester’s morals and sometimes the ego too. (I suggest not keeping any type of ego. ego’s like “I have reported the bug correctly”, “I can reproduce it”, “Why has he/she rejected the bug?”, “It’s not my fault” etc.,).

How To Write A Good Bug Report1

Qualities of a Good Software Bug Report

Anyone can write a Bug report. But not everyone can write an effective Bug report. You should be able to distinguish between an average bug report and a good bug report.

How to distinguish between a good and bad Bug Report? It’s very simple, apply the following characteristics and techniques to report a bug.

Characteristics and Techniques

#1) Having a clearly specified Bug Number:  Always assign a unique number to each bug report. This, in turn, will help you identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report a bug.

Note the number and a brief description of each bug that you reported.

#2) Reproducible: If your bug is not reproducible, then it will never get fixed.

You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing steps. The bug which is described Step by step is easy to reproduce and fix.

#3) Be Specific: Do not write an essay about the problem.

Be Specific and to the point. Try to summarize the problem in minimum words yet in an effective way. Do not combine multiple problems even if they seem to be similar. Write different reports for each problem.

Effective Bug Reporting

Bug reporting is an important aspect of Software Testing. Effective Bug reports communicate well with the development team to avoid confusion or miscommunication.

A good Bug report should be clear and concise without any missing key points. Any lack of clarity leads to misunderstanding and slows down the development process as well.  Defect writing and reporting is one of the most important but neglected areas in the testing life cycle.

Good writing is very important for filing a bug. The most important point that a tester should keep in mind is not to use a commanding tone in the report. This breaks morale and creates an unhealthy work relationship. Use a suggestive tone.

Don’t assume that the developer has made a mistake and hence you can use harsh words. Before reporting, it is equally important to check if the same bug has been reported or not.

A duplicate bug is a burden in the testing cycle. Check out the whole list of known bugs. At times, the developers may be aware of the issue and ignore it for future releases. Tools like Bugzilla, which automatically searches for duplicate bugs, can also be used. However, it is best to manually search for any duplicate bug.

The important information that a bug report must communicate is “How?” and “Where?” The report should clearly answer exactly how the test was performed and where the defect occurred. The reader should easily reproduce the bug and find out where the bug is.

Keep in mind that the objective of writing a Bug report is to enable the developer to visualize the problem. He/She should clearly understand the defect from the Bug report. Remember to provide all the relevant information that the developer is seeking.

Also, bear in mind that a bug report would be preserved for future use and should be well-written with the required information. Use meaningful sentences and simple words to describe your bugs. Don’t use confusing statements that waste the time of the reviewer.

Report each bug as a separate issue. In case of multiple issues in a single Bug report, you can’t close it unless all the issues are resolved.

Hence, it is best to split the issues into separate bugs. This ensures that each bug can be handled separately. A well-written bug report helps a developer to reproduce the bug at their terminal. This will help them diagnose the issue as well.

How To Report A Bug?

Use the following simple Bug report template:

This is a simple Bug report format. It may vary depending on the Bug report tool that you are using. If you are writing a bug report manually then some fields need to be mentioned specifically like the Bug number – which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug?

Version: The product version, if any.

Component: These are the major sub-modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system: Mention all the operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, and Mac OS. Also, mention the different OS versions like Windows NT, Windows 2000, Windows XP, etc, if applicable.

Priority: When should a bug be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with the highest priority” and P5 as ” Fix when time permits”.

Severity: This describes the impact of the bug.

Types of Severity:

  • Blocker: No further testing work can be done.
  • Critical: Application crash, Loss of data.
  • Major: Major loss of function.
  • Minor: Minor loss of function.
  • Trivial: Some UI enhancements.
  • Enhancement: Request for a new feature or some enhancement in the existing one.

Status: When you are logging the bug into any bug tracking system then by default the bug status will be ‘New’.
Later on, the bug goes through various stages like Fixed, Verified, Reopened, Won’t Fix, etc.

=> Click here to read more about the detailed Bug Life Cycle.

Assign To: If you know which developer is responsible for that particular module in which the bug occurred, then you can specify the email address of that developer. Else keep it blank as this will assign the bug to the module owner, if not the Manager will assign the bug to the developer. Possibly add the manager’s email address to the CC list.

URL: The page URL on which the bug occurred.

Summary: A brief summary of the bug, mostly within 60 words or below. Make sure your summary is reflecting on what the problem is and where it is.

Description: A detailed description of the bug.

Use the following fields for the description field:

  • Reproduce steps: Clearly, mention the steps to reproduce the bug.
  • Expected result: How the application should behave on the above-mentioned steps.
  • Actual result: What is the actual result of running the above steps i.e. the bug behavior?

These are the important steps in the bug report. You can also add “Report Type” as one more field which will describe the bug type.

Report Types include:

1) Coding error
2) Design error
3) New Suggestion
4) Documentation issue
5) Hardware problem

Important Features in Your Bug Report

Given below are the important features in the Bug report:

#1) Bug Number/id

A Bug number or an identification number (like swb001) makes bug reporting and the process of referring to bugs much easier. The developer can easily check if a particular bug has been fixed or not. It makes the whole testing and retesting process smoother and easier.

#2) Bug Title

Bug titles are read more often than any other part of the bug report. This should explain all about what comes with the bug. The Bug title should be suggestive enough that the reader can understand it. A clear bug title makes it easy to understand and the reader can know if the bug has been reported earlier or has been fixed.

#3) Priority

Based on the severity of the bug, a priority can be set for it. A bug can be a Blocker, Critical, Major, Minor, Trivial, or a suggestion. Bug priorities can be given from P1 to P5 so that the important ones are viewed first.

#4) Platform/Environment

OS and browser configuration is necessary for a clear bug report. It is the best way to communicate how the bug can be reproduced.

Without the exact platform or environment, the application may behave differently and the bug at the tester’s end may not replicate on the developer’s end. So it is best to clearly mention the environment in which the bug was detected.

#5) Description

Bug description helps the developer to understand the bug. It describes the problem encountered. A poor description will create confusion and waste the time of the developers as well as testers.

It is necessary to communicate clearly the effect of the description. It’s always helpful to use complete sentences. It is a good practice to describe each problem separately instead of crumbling them altogether. Don’t use terms like “I think” or “I believe”.

#6) Steps to Reproduce

A good Bug report should clearly mention the steps to reproduce. These steps should include actions that may cause the bug. Don’t make generic statements. Be specific on the steps to follow.

A good example of a well-written procedure is given below


  • Select product Abc01.
  • Click on Add to cart.
  • Click Remove to remove the product from the cart.

#7) Expected and Actual Result

A Bug description is incomplete without the Expected and Actual results. It is necessary to outline what the outcome of the test is and what the user should expect. The reader should know what the correct outcome of the test is. Clearly, mention what happened during the test and what the outcome was.

#8) Screenshot

A picture is worth a thousand words. Take a Screenshot of the instance of failure with proper captioning to highlight the defect. Highlight unexpected error messages with light red color. This draws attention to the required area.

Some Bonus Tips To Write A Good Bug Report

Given below are some additional tips on how to write a good Bug report:

#1) Report the problem immediately

 If you find any bugs while testing, then you do not need to wait to write a detailed bug report later. Instead, write a bug report immediately. This will ensure a good and reproducible Bug report. If you decide to write the Bug report later on then there is a higher chance to miss the important steps in your report.

#2) Reproduce the bug three times before writing a Bug report

Your bug should be reproducible. Make sure that your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time, then you can still file a bug mentioning the periodic nature of the bug.

#3) Test the same bug occurrence on other similar modules 

Sometimes the developer uses the same code for different similar modules. So there is a higher chance for the bug in one module to occur in other similar modules as well. You can even try to find the more severe version of the bug you found.

#4) Write a good bug summary

Bug summary will help the developers to quickly analyze the bug’s nature. A poor-quality report will unnecessarily increase development and testing time. Communicate well with your bug report summary. Keep in mind that the bug summary can be used as a reference to search for the bug in the bug inventory.

#5) Read the Bug report before hitting the Submit button

Read all the sentences, wordings, and steps that are used in the bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

#6) Do not use abusive language.

It’s nice that you did good work and found a bug but do not use this credit for criticizing the developer or attacking any individual.


There is no doubt that your bug report should be a high-quality document.

Focus on writing good bug reports and spend some time on this task because this is the main communication point between the tester, developer, and manager. Managers should create an awareness in their team that writing a good Bug report is the primary responsibility of any tester.

Your effort toward writing a good Bug report will not only save the resources of the company but also create a good relationship between you and the developers.

For better productivity write a better Bug report.

Are you an expert in writing a Bug report? Feel free to share your thoughts in the comments section below.

Recommended Reading

274 thoughts on “How to Write a Good Bug Report? Tips and Tricks”

  1. Hi All,

    This is Apurva, i am new in software testing.This article is really very useful. Plz some body mail me the complete testing process how it ia done practically as I only have theoritical knowledge.I am in urgent need of it. Thank u.
    My email addresss is:

  2. Hi , Im Ankit, can any one send me the names list of bugs generally found while testing a game? I know only a few names like graphical bugs, freeze bugs etc.,
    Plz mail me the list if u knw

  3. good article..
    can any 1 explains the difference b/w userinterface & functional testcases?

  4. Very help ful thanks for sharing…!!!!

  5. Really nice information posted which will fresher as well as experienced people to get to know well with bug reporting

  6. Can any one give me the examples of:
    1) high severity-low priority
    2)high severity-high priority
    3)low severity-high priority
    4)low severity-low priority

  7. Lot of testing learned @ ‘’; thanks Vijay….

    Also, I’m looking for a brief article on test scenario…

  8. I’ve subscribed for news letter, but need this post. Can you please mail this post to me?

  9. please can you mail me the bug report

  10. Whatever truly moved you to compose “How to write a good bug report?
    Tips and Tricks – Software Testing Help”? Igenuinely appreciated
    it! Thank you -Chassidy

  11. I personally blog as well and I am posting something very similar to this specific post, “How to write a good
    bug report? Tips and Tricks – Software Testing Help”.

    Would you care in case I actuallyutilise a number of your
    personal ideas? Thanks ,Muhammad

  12. Hi Vijay,
    This is sarvesh,i m Fresher. please help me,
    can you mail me personally to the a bug report to my mail id is
    thank you

  13. hi… frnds please help me send me……
    Can anyone send me effective bug Report, and Bug Report Template with some email id is
    I will be very thankfull to you.


  14. i also like your post so well please help me i want to get simple bug template for functional and regression test.


  15. The info is vry clear,effective and useful…..will someone send a sample bug report plz ?

  16. Hi…Plz send a sample bug report to the following mail id.


  17. Great article. One thing that I add to my defect write up is a severity justification if I’m giving the bug a Sev 1 or 2.

  18. Thanks ……for nice Experiment.

  19. Nice article, Thanks for posting this article. It is very useful for testers………….

  20. Thankyou so much. Get to know so much of knowledgeable stuff through your articles

  21. Nice one thanks.

    Jayashree Patil

  22. Thank you for very interesting and helpful article. can you please give us a link for the template of the Report bug? how it look like.

    Thank you, more power!

  23. hi friends,
    how to write a letter to manager when we got new bug?

    Thanks and Regards

  24. This is very helpful article

  25. hi all,

    this is really nice article……………thanks for


  26. Vijay,

    Let me know E-learning domain testing process.

  27. I really appreciate you! It was very useful, specific and very clear. Thanks a lot. wish you all the best

  28. hi this site helpfull to my self

  29. Rules and tips are very helpful.
    Thank you about your essay

  30. I read Bug Report Article it is very good.could u pls give an original bug report?

  31. We have one form in that we have around 4 fields and all fields have same should i report one bug or 4 different bugs for 4 fields

  32. it was very beneficial and also develop the knowledge.

  33. I really appreciate you! It was very useful, specific and very clear. Thanks a lot STH. wish you all the very best.

  34. in our company we are using using excel as bug report.In Bug Report(excel sheet)Is any need to maintain relationship with requirement specification document/test case document .

  35. Nice article ! Thanks for sharing ^^

  36. I am having 2 years of experience in manual testing. Now I want to go ahead with automation testing to enhance my career. I am thinking about 2 tools that are Selenium and QTP. Which tool should I learn between two to achieve more growth in my career?
    Expecting reply asap.

  37. Abhijit

    i have certified software testing
    course also. i have experience in Non TESTING Field. i want to switch over to testing field. i have theoretical knowledge but i need some real time testing knowledge.

    can u help me?

    can any sample testing projects for me, if u sending it
    will really literal help for me..

    Expecting your favorable reply.

    my id is


  38. Thank You ,Really Helpfull….

  39. Hi,
    Can anyone send me effective bug Report, and Bug Report Template with some email id is
    I will be very thankfull to you.

  40. This could have used an editor (and since I mentioned that I’ll likely make an error here…)
    I was looking for some information on writing effective, concise bugs, and in the second paragraph I see:
    “stating as irreproducible. This can hurt testers moral and some time ego also.” sigh. (morale and sometimes…)
    However, reading the rest of the paper, I see a good basic breakdown of writing a bug. Something to keep in mind is some people (especially QA professionals) might not have read past the second paragraph.
    Good material, just needs a bit of tweaking.

  41. Hi!
    Really nice information. It will help freshers as well as experienced people
    to get to know bug reporting well. All the tips you have provides are very


Leave a Comment