Effective ‘Bug’ reporting procedure
Effective bug report leads to a higher rate of resolving defects.
Writing a good defect or bug report goes a long way in identifying and resolving the problems quickly. In here, I list the elements that are normally included in a bug report.
- Defect Identifier, ID
- Summary
- Description
- Severity & priority
- Date & Time
- Version & build the software under test
- Reported by
- Related requirements
- Attachments/ Evidence
Defect Identifier, ID
The identifier is very important in being able to refer to the defect in the reports. If a defect reporting tool is used to log defects, the ID is normally a program generated a unique number which increments per defect log.
Summary
What is the problem? A bug summary should provide a quick snapshot of what exactly the issue is. It has to be precise.
Try to find the right words to describe the summary that would give the information directly. Generic statements like “not working properly”, “not working as expected” etc., must be avoided.
Where is the problem? If it’s a website, copy and paste the URL. If it’s not, give the name of the screen you are on.
Description
A bug should always be written in a clear, concise and precise manner so that it gives an exact location of the bug in the extensive/exhaustive software map. I reiterate that this not only improves the quality of software but also reduces the cost of testing and developing the software to a great extent.
Severity & Priority
Each and every defect must be having an appropriate value of Severity and Priority. Severity decides the impact of the defect on the application & Priority gives information on how quickly the defect should be fixed. Developers will focus on resolving defects having the Highest Priority and severity first.
Date and Time
The date and time that the defect occurred or reported is also essential. This is normally useful when you want to search for defects that were identified for a particular release of software or from when the testing phase started.
Version and Build of the Software Under Test
During the software testing life cycle, your project goes through different servers: Dev Server, QA Server, Pre-Production, Live, etc. So whenever you are reporting any defect, mentioning this information is must :
– On which Build version you are doing testing and Defect is reported
– On which Server issue is found, resolved and closed.
Reported by
Again, this is important, because if we may need to refer to the person who raised the defect, we have to know who to contact.
Related requirement
Essentially, all features of a software application can be traced to respective requirements. Hence, when a failure is observed, we can see what requirements have been impacted. This can help in reducing duplicate defect reports in that if we can identify the source requirement, then if another defect is logged with the same requirement number, we may not need to report it again, if the defects are of similar nature.
Attachments / Evidence
If you can see the problem, capture the moment. There is nothing better than being able to see the problem by ourselves. And if there are already annotations in it, you will have nailed it!
Spread love to developers:
If you find something wrong — no matter how alarming it seems, stop what you’re doing, take a step back and write a decent bug report.
As easy as firing up the email and document the incident with love. Don’t just call up or send a one-liner message.
