Defect Management
During test execution, a tester will likely encounter testing issues, which can be defined as any of the following:
Regardless of the underlying cause, any issues found during testing should go through the following process:
Tester should first attempt to recreate the issue at least one additional time. Software is designed to always work the same way, regardless of how many times it is accessed. With this in mind, a true software defect should also occur every time as well [assuming the same pathing/steps and detail/test data are used]. By recreating the issue, a tester can rule out non-defects and also confirm the steps required to produce a true defect. This information should be part of the defect incident that is opened.
- A true "defect" or "bug" with the software; that is, a difference between the way the software functions and how it is supposed to function [deviation from the business software requirements].
- Any situation that creates a failure of the software or supporting systems: blue screen of death, computer crashes or reboots, a server or other internal system goes offline, etc..
- An unexpected result that is not a true defect; for example, tester errors such as incorrect test script design, improper running of a script, using bad test data, etc.; environment issues such as a test region not set up with correct software versions and configurations, system or interfaces not online/accessible; or other similar types of conditions.
Regardless of the underlying cause, any issues found during testing should go through the following process:
Tester should first attempt to recreate the issue at least one additional time. Software is designed to always work the same way, regardless of how many times it is accessed. With this in mind, a true software defect should also occur every time as well [assuming the same pathing/steps and detail/test data are used]. By recreating the issue, a tester can rule out non-defects and also confirm the steps required to produce a true defect. This information should be part of the defect incident that is opened.
When creating a defect incident, a tester should:
1. List all steps and test data required to reproduce the defect.
2. Assign a severity level based on the impact.
3. Follow reporting process to alert testing/project leads of critical
issues so they an immediately be addressed and monitored. Use a
spreadsheet to record and track the status of each defect.
1. List all steps and test data required to reproduce the defect.
2. Assign a severity level based on the impact.
3. Follow reporting process to alert testing/project leads of critical
issues so they an immediately be addressed and monitored. Use a
spreadsheet to record and track the status of each defect.
Once a defect is fixed:
1. Tester confirms what was fixed, to identify what needs to be retested, Talk to resolution team if
necessary.
2. Retest defect fix. Schedule and execute regression test(s) to confirm no new issues are introduced or discovered.
3. Testing continues until all test scripts have been completed and the rate of defects being discovered
drops below a rate or number than is acceptable to the testing or project team.
1. Tester confirms what was fixed, to identify what needs to be retested, Talk to resolution team if
necessary.
2. Retest defect fix. Schedule and execute regression test(s) to confirm no new issues are introduced or discovered.
3. Testing continues until all test scripts have been completed and the rate of defects being discovered
drops below a rate or number than is acceptable to the testing or project team.
"Testing can be used to show the presence of bugs, but never to show their absence!" - Edsger Dijkstra