Defect Management

The way in which defects are handled is arguably equally as important as running the tests themselves.

The basic process of defect management is described below and should be followed whenever there is a test phase being undertaken.

Step 1: Defect observed

• Tester observes a difference between the expected result defined in the test and the actual result demonstrated by the system.
  
• Tester needs to ensure the requirements have not changed. If they have then this means the test is factually incorrect and requires to be updated. No defect required if this is the case.
  
• Tester also needs to check if the defect has been previously reported by another tester or if the development team is aware of this. No defect required if this is the case however the existing defect requires to be updated explaining there is a further test that is now being affected.

Step 2: Defect logged

• If the actual result has not already been reported and is not connected to requirements change i.e. the system is doing something it shouldn’t be or vice versa, then a defect needs to be logged using the agreed defect management tracking system.
  
• The defect should be prioritized based on its impact which can be classified as High, Medium or Low.

Step 3: Defect assigned for triage

• Developer reviews the defect and investigates the Root Cause.
  
• Developer details Root Cause in the defect and if applicable releases the fix.

Step 4: Defect assigned for re-test

The Defect is now assigned back to the tester to re-test. The same test that failed during Step 1 of this process would be executed again. The tester would then either:

• Close the defect after successfully re-testing, ensuring comments are added stating the test was successful. The test status would now also be updated to state: Passed
  
• Re-assign the defect back to the development team for further investigation if the re-test was not successful. The test status would continue to have the status of: Failed