Defect Scenario

This scenario identifies the resources that are related to a defect.

Scenario

Here is the scenario without roles.

1. A build is deployed to a configured test machine (physical or virtual)

2. A test is executed

   • Test fails (continue)
   • Test passes (if verifying a defect, close it. Otherwise stop)
3. A defect is submitted (Change Request type=defect)

4. Defect is triaged

   • Fix defect (continue)
   • Don't fix it (stop)
5. A change set is delivered to fix the defect

6. The build executes.

   • Build passes (continue)
   • Build fails (stop)
7. The build ID captures the build status & identifies links to additional information about the build (location of the physical bits, the Bill Of Materials).
8. Team members are notified. (feeds, monitoring the build id etc)
   • The build ID is referenced along with the BOM to determine what changes are included in the build
   • Start at 1

Pre-conditions:

• The test configuration is defined. The test machine is 'configured' correctly.
• A build definition exists (build scripts, build machines, any automation to occur etc.)
• The scenario assumes this is a funded software development project with the scenario occuring in the context of the project.

Post-conditions

• Defect record is closed, contains history of what build it was 'found in' and what build it was 'fixed in'
• Test execution passes.
• Source code contains the fix.

Alternatives:

Defect found in production. Steps are very similar, however the triage process is likely to be different and identification of production resources are needed--- e.g. found in this application running on this configuration in production.

Defect found by user in the field. Again, similar, but the system will have less control over the deployment, configuration, machine resources. Likely defect is triaged to the 'next version' of the application.

Resources