Defect Reporting: The Next Steps

When a software anomaly is identified, it’s imperative that the defect report is written using best practices guidelines to ensure the report is intelligible, the issue is able to be recreated, and expected behavior and environmental parameters are communicated.

The drawback to these types of guidelines is that the best practices only pertain to the initial writing of the defect but are deficient in standards to help identify the tasks required for the tester to close the defect.

When a defect is fixed by the developer and moved into a “Retest” or “Resolved” state, the defect may remain there for a long time while waiting for a tester to verify and close it, even for the smallest of fixes. Numerous factors can contribute to this time duration:

• Verifying the defect fix requires more than just executing the steps that were originally outlined in the defect report
• Regression testing and periphery (“drive-around”) testing are needed to ensure that the fix didn’t break anything else
• Additional test data is required
• Customer-specific environments, settings, and configurations need to be exercised to ensure the fix applies to these parameters
• The fix could be blocked by another defect
• Task-switching based on the priorities at that time require you to stop what you’re doing so that you can move onto a higher priority issue
• Continuous testing in DevOps requires repeated testing of the same issue

All of these factors can appear as inactivity on the part of the tester, when really that’s not the case.

This so-called “inactivity” usually becomes apparent during the daily standup meeting. The ScrumMaster will continue to perceive stagnation on the part of the tester if all that’s apparent is the state of “Retest” or “Resolved.”

The solution is to add within the defect’s comments a “Next Steps” section that identifies the work remaining and the person responsible for completing it. Here's an example:

Next Steps:

1. Create regression test scenarios (Richard) - Done Monday 2019-12-16
2. Deploy fix to test environment (Saanvi) - Done Tuesday 2019-12-17
3. Verify fix (Richard)
4. Execute regression test scenarios (Richard)
5. Execute performance tests (Arjun)
6. Deploy fix to pre-production environment (Saanvi)
7. Verify fix (Richard)
8. Execute regression test scenarios (Richard)
9. Execute performance tests (Arjun)
10. Close (Richard)

Tuesday December 17 2019 10:22am ET

The “Next Steps” section is dynamic. When tasks are completed, you mark them as done with the date it was completed. If additional steps are needed, then you add them. If a step is unnecessary, you remove it.

A “Next Steps” section returns the following value:

• The ScrumMaster won’t need to seek out the defect assignee in order to determine the progress and planned activity of the test effort
• The person who wrote and started the testing may not necessarily be the person to complete the testing, so they have the ability to easily delegate the defect responsibility to someone else while allowing them to know exactly what work is remaining
• When task-switching among numerous defect reports, it allows you to remember where you had left off
• It facilitates estimating time until completion
• The team can critique your test approach, filling gaps and removing unnecessary tasks
• Other team members are notified when they are expected to contribute to the verification of the defect fix
• It serves as a historical record of the effort undertaken

Enhance your defect reporting by making a “Next Steps” section part of your best practices.

• Login or Join to add your comment