Defect Reporting – How to raise a good defect? and attribute of good defect document:
Dreporting. Software Testing is an important part of Software Development Life Cycle. It not only ensures correct functionality even ensure complete development of Application. It build client’s confidence in Application and reduce chances of unexpected bug in Application on Production. During testing, QA found some unexpected functionality or which is not working correctly as per requirement. Unexpected behavior may be bug or sometimes will convert into required change. So it’s quite important to report bug with right information, with sufficient evidences, steps and test data so Developer/Business Analyst will recreate/understand and fix it.
Defect/Bug:
We can say that the Application is having a defect (or Bug) if the Application is failing to perform what is to perform. Basically, actual outcome does not match with the expected outcome then defect occurs.
There may be several reasons for occurrence of defects likewise:
- It may occur due to poor coding experience.
- Lack of proper communication of the requirements between client and developer.
- Time crunch and unit testing is not performed.
- Lack of Domain Knowledge
Why Good Bug/Defect Reporting is important:
Bug Report is a detailed document that gives the description of Bug and all the associated information. A good Defect report helps developer to understand issue what is the problem, how to re produce it, on which platform, severity, and priority etc. Good defect reporting helps developer to fix quickly. If defect report is not good then the developer may ignore your issue or delay which impact business deliveries.
“Good Defect Report helps you get quick fix from Developer”
How to raise a Good Defect/Bug:
Good Defect report must be clear, concise and provides all test data which need to reproduce issue.
Good defects have following components
i. Defect Summary
Brief Summary of Defects which gives highly level idea of defect. Generally defect summary is the Subject of Bug Email Notification.
Sample Summary:
[Travel | Mobile] – Payment failing for UAE Travel Policie
ii. Test Data
Test Data is very important part of Bug reproduce, retest and analysis. Mostly bug hit for specific data so we need specify the test data.
Sample Test Data:
Traveler Details:
Name: Jack
DOB- 15 Aug 1947
MALE
Salary: 95000
Policy purchased for: DUBAI
iii. Environment Details
QA must have to specify whether bug is coming on Developer Environment or Staging or Production environment.
iv. Environment: DEVBuild Version
Testing commenced when new code is deployed on test Server. Each code is identified by Build Version. Sometimes issues come on specific build so we need to mention Build version in Defect Document.
v. Platforms
We must have to mention platform name in defect report.
vi. Platform
Windows 10, Chrome 95, Iphone 7, Safari
vii. Severity
Severity represents complexity of Bug. Right Severity is very important and it should do after impact analysis. Severity is generally represented by following status:
S1 = Critical, S2 = Major, S3 = Minor
viii. Priority
Priority means urgency of fixing a defect. It is categorize 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.
ix. Result
Unexpected behavior is bug and it must be written clearly in Result Section. Actual and Expected Result. Sample Result:
Expected Result: On Travel portal user unable to make payment. Getting 404 errors.
Actual Result: User should able to make payment and should get invoice after payment.
x. Status
New Defect must be in “New” state or open state and as per Bug Life Cycle.x. Label: We use label to categories issues on specific feature or type of issues.
For an insurance portal label can be
TRAVEL, TRAVEL MOBILE, HEALTH, HEALTH MOBILE
xi. Epic
Epic is usually a collections of user stories which we target for particular duration of time.
Sample Epic Name: Insurance Portal Mobile LaunchProject:
Project is usually new Application which added in Organization. Sample Project Name : “Insurance on Demand (IOD)”
Repeatability
We need to identify whether Bug is sporadic or always persist. If bug is intermittent then we need to specify else developer may reject it.
Above points makes your defect report awesome and it will help developer to recreate issue and fix as soon as possible. We can expect writing good defect report from functional tester (Quality Analyst) and also it’s one reason of appreciation and awards.
Thanks for reading this article. Hope this article helps you in creating good defect report which will be very easy for developers, business analysts and project stack holder. If you have any questions then feel free to write us on info@thoughtcoders.com or call us on +919555902032.
To learn more about testing, automation tools (Cypress, Selenium, RestAssured etc) and QA tools explore ThoughtCoders blogs section. You may also Contact Us for QA Services, QA Automation, Software Testing, Performance Testing, Interview and Job Support Software Trainings, Automation Testing Trainings and technical consultations.
For more updates on defect reporting, join us on Facebook, LinkedIn, Twitter and Instagram!
