How to raise a good defect? and attribute of good defect document:
Welcome to ThoughtCoders Software Testing training blog. In this article, we will explore best practices for defect reporting. Being a Quality Analyst, it’s our day to day responsibility to execute test cases and report all the unexpected behavior of Application to Developer.
This article will help you to understand what is defect, how to report good defects and few tips to write awesome defect report.
What is Defect?
We can say that software is having a defect if the software is failing to perform what is supposed to perform. Basically, Actual outcome does not match with the Expected outcome then defect occurs.
Generally, defect found in Application because of below reasons:
- Developer less coding experience in programming languages causes more defect in Application. It has been seen that application developed by fresher’s or less experienced professional have more defect.
- Defect may occur due to lack of proper communication of the requirements between client and developer.
- Sometimes due to time crunch application can’t tested completely. Because of this, application has more defects.
What happens if Bug is not correctly reported?
If a bug is not reported correctly then there is the chance of Bug rejection by Dev Team with comment –“irreproducible”, “Not an issue”, “Check Again”, “Need more information” etc which can hurt QA team performance and delay in getting fixes. And lot of to and fro happens and which kill precious time of all the parties so it will be highly recommended to report bug correctly.
Best Practices for Bug Reporting:
Anyone can write bug report but everyone can’t report effective bug. You should be able to understand the difference between average and good defect report. Here is the characteristic of good report which help you to identify good and bad report.
Below are few important points that are needed to be kept in mind while raising a good defect:
- Report Bug on Defect Tool: Once tester finds a defect then he should create a defect ticket on any defect tracking tool-JIRA, Bugzilla. Bug reporting tools provides field to specify the all information like release number, module, defect id, bug status, assignee, description, impact. So bug tracking tool must used for bug reporting. We should not share bug on Chat or email because sometimes it’s interested parties (manager, Developer) or bug status etc not mentioned in email so this is not recommended.
- Write Good Description: Description is important part of Bug. In description field we must have to mention the details of scenario. Primarily, it should contain scenario, what you want to do and what are the steps, what expect and how actual it’s working; test data should be mentioned in Description area.
A detailed description of bug. Use following fields for description field:
Reproduce steps: Clearly mention the steps to reproduce the Bug.
Expected result: How application should behave on above mentioned steps.
Actual result: What is the actual result on running above steps i.e. the bug behavior.
These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.
- Mention Priority and Severity: Tester must set correct priority and severity for the defects found. Severity means the negative impact on the quality of the software.
Severity is also denoted as:
S1 = Critical, S2 = Major, S3 = Minor
Priority means urgency of fixing a defect.
Priority is categorized into the following levels:
a) Urgent: Must be fixed immediately / in the next build.
b) High: Must be fixed in any of the upcoming builds but should be included in the release.
c) Medium: May be fixed after the release / in the next release.
d) Low: May or may not be fixed at all.
- Steps to Reproduce: Steps to reproduce for the particular defect should be mentioned so that developer can understand it easily.
- Mention Actual and Expected Result: Tester must mention the actual outcome along with the expected outcome on the tracking tool. Mixed description creates confusion and there will be the chances of misunderstood.
- Defect screenshots/Video: If required, screenshot as well as recording should also be attached so that it will be easier for a developer to replicate at his end.
- Test Data: Test Data is used by developer to replicate issue and fix issues quickly and also it’s required while retesting. So Tester must mention the test data/credentials used while finding a defect.
– Mention user details for which defect occur
– Specific URL or location of Web Page
– Database Queries to verify data in DB
– Application Version (Build Version)
– Error log Data
- Test Environment: Test Environment must be mentioned in defect document. This is required to reproduce issue during fixes so you must have to mention.
- Assignee: While creating a defect ticket, tester must assign it to developer with specific name else it would be assigned to a random person. Unassigned defect and assigned to random person mostly ignored.
Pic1: Sample HPQC New Defect Fields
Apart from above points, here are the tips which make you awesome in bug reporting:
1) Report the problem immediately: If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
2) Reproduce the bug multiple times before writing bug report: Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug and in this scenarios record video and mention video link in Defect document.
3) Test the same bug occurrence on other similar module: Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.
4) Write a good bug summary: Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory and email.
Sample Bug summary -<ProjectName> -Module Issue details
5) Read bug report before hitting Submit button: Read all sentences, wording, steps used in 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) Use Polite language: It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.
At the end, we would conclude that defect report should be highly readable, descriptive and should have clear test steps, test data, expected result, actual result, application version, Sprint Cycle, test environment, bug snapshot and error log should be mentioned correctly.
Hope above article help you in creating best defect reporting document. To learn more about testing technologies, automation and DEVOPS refer our blog section. Feel free to reach out to us on firstname.lastname@example.org for any additional information.
This article is contributed by Soumya Sinha (LinkedIn Profile). She is working as Quality analyst with leading mobile application development Company.