What is a Defect Report?
A defect report is a document that describes a defect, including its severity, priority, and steps to replicate the problem.
A defect report's primary purpose is to help the developers quickly reproduce and fix the fault.
It is an effective way of communicating and tracking the defect throughout its life cycle.
What does a Bug Report Contain?
Let's take a look at a few basic things a defect report includes
- ID
- Every defect is assigned a unique identification number. If you use a bug tracking tool, this will be auto-assigned.
- Project
- The defect's project.
- Module
- The module in which the defect was detected.
- Steps
- Detailed instructions to replicate the defect.
- Status
- The defect's current stage its defect life cycle.
- Severity
- The defect severity.
- Priority
- The defect priority.
- Reported Date
- The date when the tester detected the defect.
- Fix Date
- The date on which the developers fixed the defect.
- Close Date
- The date on which the developer fixed the defect, and the issue was marked as closed.
- Reported By
- The person who reported the defect.
- Assigned To
- The person who is currently responsible for the defect.
- Reported Version
- The software version in which this defect exists.
- Fixed Version
- The software version in which this defect was fixed.
- Attachments
- A set of screenshots or videos that provide additional information on the defect.A
How to write great bug report in five easy steps
Bugs are often stressful and time-consuming. A substandard bug report makes it even more difficult. The good news, however, is that writing a good defect report is easy. Just follow these five uncomplicated guidelines:
Be thorough. Be accurate.
It is frustrating when you see missing or incorrect fields in the bug report. If you are using a bug tracking tool, make the fields mandatory, add validations and remove unnecessary options.
Write a clear title.
Write a title that clearly states the defect in one line. In our bug tracker, we have often seen multiple bugs with the same title: "Error on the project dashboard." The problem with such a description is that it does not describe the defect at all. It is better to write a title that effectively summarizes the issue. For example:
- Incorrect invoice total on the project dashboard.
- Project dashboard incorrectly displays chart in Chrome browser.
- Resizing the project dashboard results in a javascript error.
Be specific.
Bugs descriptions are often general, but in reality, they are not. They are usually very specific. The result is that even after following the steps, the developer cannot replicate the problem; neither can the person who reported it. An opportunity to fix a defect is lost.
Let's take a real-world example from one of our bug reports.
The tester wrote the following steps:
- Log in as a user.
- Click on the user's photo. Click on Profile.
- Change the language.
- Submit.
The developer responded that he couldn't reproduce the problem. The tester couldn't either and spent a lot of time replicating it again.
The problem happened when users switched their language from French to Arabic. The tester, however, thought it happened whenever users changed their interface language. It would have been better if the tester was specific about the facts and wrote something like:
- Login as Peter Parker (Include: login url/username/password)
- Click on the user's photo. Click on Profile.
- Change the language to Arabic.
- Submit
Be concise.
Stick to the point and avoid unnecessary details. It is frustrating when developers have to spend time separating the signal and the noise. Testers, wanting to help, often overthink and include things that are unrelated to the problem. Just be specific in reporting the facts, and you should be fine.
Attach screenshots and videos.
A picture speaks a thousand words they say. A great screenshot or video enables you to be specific without being verbose. Thankfully, many tools are now available that allow you to capture screenshots and videos conveniently.