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-
- Defect Id: A unique number or name.
- Defect Description: Summary of defect.
- Build Version Id: Parent build version number.
- Feature: Module / Functionality
- Testcase name and Description: Failed testcase name with description
- Reproducible: (Yes / No)
- If yes, attach test procedure.
- If No, attach snapshots and strong reasons
- Severity: High / Medium / Low
- Priority: P1/P2/P3
- Status: New / Reopen (after 3 times write new programs)
- Reported by: Name of the test engineer
- Reported on: Date of Submission
- Suggested fix: optional
- Assign to: Name of PM/Developer/Lead
- Fixed by: PM or Team Lead or Developer
- Resolved by: Name of the Developer
- Resolved on: Date of solving
- Resolution type:
- Approved by: Signature of the PM
Defect Age: The time gap between resolved on and reported on.
Fig: Large Scale Organizations
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:
There are 12 resolution types such as
- Duplicate: Rejected due to defect like same as previous reported defect.
- Enhancement: Rejected due to defect related to future requirement of the customer.
- H/w Limitation: Raised due to limitations of hardware (Rejected)
- S/w Limitation: Rejected due to limitation of s/w technology.
- Functions as design: Rejected due to coding is correct with respect to design documents.
- Not Applicable: Rejected due to lack of correctness in defect.
- No plan to fix it: Postponed part timely (Not accepted and rejected)
- Need for More Information: Developers want more information to fix. (Not accepted and rejected)
- Not Reproducible: Developer want more information due to the problem is not reproducible. (Not accepted and rejected)
- User misunderstanding: (Both argues you are thinking wrong) (Extra negotiation between tester and developer)
- Fixed: Opened a bug to resolve (Accepted)
- 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