Skip to main content

How to write a good bug report

How-to-write-good-bug-report

Defect Reporting and Tracking:  Put the Reporter’s Name on the bug. If there are questions we need to know who originated this report.  Specify the Build or Version number of the code being worked on. Is this the shipping version or a build done in-house for testing and development? Some bugs may only occur in the shipping version; if this is the case, the version number is a crucial piece of information.  Specify the Feature or Specification or part of the code. This facilitates assigning the bug to a developer assigned to that part of the product.  Include a Brief Description of what the problem is. For example, “Fatal error when printing landscape.” is a good description; short and to the point.  List Details including how to duplicate the bug and any other relevant data or clues about the bug. Start with how the computer and software is setup. List each and every step (don’t leave any out) to produce the bug. Sometimes a minor detail can make all the difference in duplicating or not duplicating a bug. For example, using the keyboard versus using the mouse may product very different results when duplicating a bug.  If the status isn’t ‘Submitted’ by default, change it to Submitted. This is a flag to the bug verifier that a new bug has been created and needs to be verified and assigned.

During comprehensive test execution, test engineers are reporting defects to development team as below format-

  1. Defect Id: A unique number or name.
  2. Defect Description: Summary of defect.
  3. Build Version Id: Parent build version number.
  4. Feature: Module / Functionality
  5. Testcase name and Description: Failed testcase name with description
  6. Reproducible: (Yes / No)
  7. If yes, attach test procedure.
  8. If No, attach snapshots and strong reasons
  9. Severity: High / Medium / Low
  10. Priority: P1/P2/P3
  11. Status: New / Reopen (after 3 times write new programs)
  12. Reported by: Name of the test engineer
  13. Reported on: Date of Submission
  14. Suggested fix: optional
  15. Assign to: Name of PM/Developer/Lead
  16. Fixed by: PM or Team Lead or Developer
  17. Resolved by: Name of the Developer
  18. Resolved on: Date of solving
  19. Resolution type:
  20. Approved by: Signature of the PM

Jira_Bug Reporting

 Defect Age: The time gap between resolved on and reported on.

Defect Submission: 

bug Reporting_ LargeScaleOrganizations

Fig: Large Scale Organizations 

Defect Submission:

bug Reporting_Small ScaleOrganizations

Fig: Small Scale Organizations.

 

Nowadays all the companies following Test management tools and agile methodology, so Defect is directly assigning to developer, In case Test Engineer doesn’t know the Developer, The defect will be assigned to Lead or Manager.

Bug Life Cycle:

Bug-Life-Cycle-1_1

 

There are 12 resolution types such as

  1. Duplicate: Rejected due to defect like same as previous reported defect.
  2. Enhancement: Rejected due to defect related to future requirement of the customer.
  3. H/w Limitation: Raised due to limitations of hardware (Rejected)
  4. S/w Limitation: Rejected due to limitation of s/w technology.
  5. Functions as design: Rejected due to coding is correct with respect to design documents.
  6. Not Applicable: Rejected due to lack of correctness in defect.
  7. No plan to fix it: Postponed part timely (Not accepted and rejected)
  8. Need for More Information: Developers want more information to fix. (Not accepted and rejected)
  9. Not Reproducible: Developer want more information due to the problem is not reproducible. (Not accepted and rejected)
  10. User misunderstanding: (Both argues you are thinking wrong) (Extra negotiation between tester and developer)
  11. Fixed: Opened a bug to resolve (Accepted)
  12. Fixed Indirectly: Differed to resolve (Accepted) 

Types of Bugs:

UI bugs: (Low severity)

Spelling mistake: High Priority

Wrong alignment: Low Priority 

Input Domain bugs: (Medium severity)

Object not taking Expected values: High Priority

Object taking Unexpected values: Low Priority 

Error Handling bugs: (Medium severity)

Error message is not coming: High Priority

Error message is coming but not understandable: Low Priority 

Calculation bugs: (High severity)

Intermediate Results Failure: High Priority

Final outputs are Wrong: Low Priority 

Service Levels bugs: (High severity)

Deadlock: High Priority

Improper order of Services: Low Priority 

Load condition bugs: (High severity)

Memory leakage under load: High Priority

Doesn’t allows customer expected load: Low Priority 

Hardware bugs: (High severity)

Printer not connecting: High Priority

Invalid printout: Low Priority 

Boundary Related Bugs: (Medium Severity) 

Id control bugs: (Medium severity) Wrong version no, Logo 

Version Control bugs: (Medium severity) Difference between two consecutive versions 

Source bugs: (Medium severity) Mismatch in help documents