defect management process

DEFECT MANAGEMENT

Process DefinitionVersion DRAFT, 06/25/2004

Revision HistoryVersion Date Updated By Modifications

Defect Management Process Definition p 2 of 9Version DRAFT 06/07/2004

Table of Contents

Executive Summary.......................................................................................................4Process Control................................................................................................................4

Process Objectives...........................................................................................................4Key Performance Indicators............................................................................................4Process Owners................................................................................................................4

Process...............................................................................................................................5Inputs...............................................................................................................................5High-Level Process Flow................................................................................................5

Defect Creation................................................................................................................5Defect Verification............................................................................................................5Defect Prioritization..........................................................................................................6Defect Assignment............................................................................................................6Defect Confirmation..........................................................................................................7Defect Resolution.............................................................................................................7Resolution Verification......................................................................................................7Defect Closure.................................................................................................................7

Lifecycle of a Defect......................................................Error! Bookmark not defined.Outputs.............................................................................................................................7

Process Enablers..............................................................................................................8Resources.........................................................................................................................8

Rational ClearQuest..........................................................................................................8Performance and Exception Reports.....................................................................................8Escalation Process............................................................................................................8

Roles & Responsibilities..................................................................................................8Business Owner................................................................................................................8QA Test Execution............................................................................................................8QA Defect Coordinator......................................................................................................8Development Liaison.........................................................................................................9Developers......................................................................................................................9


Executive SummaryThe purpose of this document is to define the process flow, controls and resources that will be employed for QA Defect Management within the Telescope Project. This document should be used by anyone who needs to understand, participate, or support this Defect Management process.

This process will govern all defects identified by the team responsible for Quality Assurance testing of the Project Telescope solution. This process will also be used to support defects identified during both informal and formal user acceptance testing.

Process Control

Process Objectives

Efficient management and resolution of defects across all development teams Enable efficient communication Visibility to software quality Clear business ownership of priorities and risk

Key Performance Indicators

1. Mean time to defect resolution – defined as total days elapsed from defect open to defect close divided by total number of closed defects. This metric is an indicator of how fast defects are being resolved.

2. Open defect aging – defined as total days elapsed from defect open to current date divided by total number of open defects. This metric is an indicator of the size of the backlog of defects and thus the outstanding quality issues.

3. Unresolved high priority defects – defined as total number of high priority open defects. This metric is one indicator of the unmitigated business risk associated with the solution.

4. Total unresolved defects – defined as total number of open defects. This metric is another indicator of the unmitigated business risk associated with the solution.

5. % of reassigned defects – defined as the total number of times a defect has been reassigned from one resolution group to another divided by the total number of assigned defects. This metric is an indicator of how well defects are being assigned.

6. % of defects closed as “not a defect” – defined as total number of defects closed as “not a defect” divided by total number of closed defects. This is an indicator of the quality of the requirements definition and QA’s ability to understand the requirements.

Process Owners

This process will be owned by Chris Solomon, as the QA lead for Project Telescope. Chris will be responsible for addressing any issues with the design and execution of the process.


Process

Inputs

This process is initiated through identification of a discrepancy between expected results and actual results during execution of testing.

High-Level Process Flow

Defect Creation

A defect is created by QA whenever a discrepancy between expected results and actual results are encountered. The person executing the test will open a new defect with a brief description, provide information regarding the operating conditions that were in place when the defect occurred, where in the application flow the defect was found, what test script was being executed, the expected and actual results, and any additional information that may be of assistance in the resolution of the defect.

Defect Verification

Once a defect is created, the defect coordinator performs an initial analysis of the situation to verify that the defect is valid, that the problem has not already been identified and logged as another defect, and assigns a severity code to the defect. The severity code provides an indication of the impact that the defect has to the operation of the solution. The following severity codes will be employed:


Severity Code 1: HighA severity code of 1 will be assigned for the following scenarios:Website or test environment is down, core functionality is not working, failed Business Scenario tests, failed platform and software compatibility tests, missing pages, wrong calculations, prevents user from executing a functionality, etc.

Severity Code 2: MediumA severity code of 2 will be assigned for the following scenarios:Incorrect Navigation and Links test cases, GUI-specific test cases, missing edit rules, missing errors and messages including invalid conditions, unreadable text areas due to scrolling or window size, etc.

Severity Code 3: LowA severity code of 3 will be assigned for the following scenarios:Content-specific test cases such as spelling and grammar, alignment and justification errors, etc.

Defect Prioritization

The business owner of the solution will review all open defects that have not been prioritized, determine the urgency of resolution for a defect, and assign a priority code to the defect. The following priority codes will be employed:

Priority Code 1: CriticalMust be fixed immediately before any code release or build. This code should be assigned if access to the application or site is restricted due to the defect, core functionality is not working, or if the website or test environment is down.

Priority Code 2: HighMust be fixed and resolved prior to the next code release or build. In addition, this code could be used if the problem is preventing the QA team from executing their test scripts.

Priority Code 3: MediumDoes not need to be resolved prior to the next code release or build and can be verified in later testing cycles. However, must be resolved and verified prior to release from QA testing into UAT or production.

Priority Code 4: LowCan be moved to the next iteration or project phase.

Note: If a defect is preventing the QA team from executing their testing, a priority code of 1 or Critical will be assigned by QA

Defect Assignment

The defect coordinator will further analyze the defect and determine which development group should be assigned responsibility for resolving the defect. The defect coordinator may engage the development team for assistance in determining ownership of the defect where it is unclear or requires deep technical knowledge.


Defect Confirmation

Once a defect is assigned to a development group, the development liaison reviews the defect information, confirms that the defect has been assigned to the correct development group and that the defect is valid. If the development liaison does not agree with the creation, assignment, or prioritization of the defect they may dispute the defect and work with the QA defect coordinator, business owner, and other development teams to resolve the dispute.

Defect Resolution

Understanding the development team workload and skill set, other changes being performed to the defective component, and current development schedules, the development liaison will assign the responsibility for resolving a defect to a developer. The developer will analyze, design, develop, and test any changes necessary to resolve the defect. Once the changes have been made, the development liaison will inform QA that the change is ready to be migrated to QA for testing and verification.

Resolution Verification

The QA Defect Coordinator will review the defects that have been identified as “ready for QA”, identify the set of test scripts that should be run to verify that the defect has been resolved and work with the environment control and test execution team to schedule the software migration and configuration as well as the verification test execution.

Defect Closure

Upon verification that a defect has been resolved, the QA test execution group can close the defect.

Outputs

The process is complete once the defect has been closed or deferred.

Resolving the discrepancy between the actual results and the expected results closes a defect. This can be accomplished through a change in the software, a modification or clarification of the requirements resulting in a change to the expected results, or the realization that a defect has already been identified.

A defect is deferred if the business owner, after reviewing the defect with QA and Development and assessing the associated risks, defers the resolution of a discrepancy.

Other outputs of this process include the process performance reports that should be used to monitor and continuously improve the process.


Roles & Responsibilities

Business Owner

The business owner is responsible for establishing and maintaining the priority of defects, clarifying business requirements, monitoring the overall risk profile of the solution, and making the go/no go decision.

QA Test Execution

The QA test execution group is responsible for executing the initial testing and any defect resolution verification testing within each testing iteration/phase. Including:

Setting up the test data required to execute the test scripts Execution of the test scripts whether manual or automated Identification of discrepancies between expected and actual results Verification of expected data updates Creation of defects and entry of supporting information in the defect management

tool Execution of test scripts to verify that the defect has been resolved Updating the defect management tool with the final resolution

QA Defect Coordinator

The QA defect coordinator is responsible for managing the lifecycle of a defect from initiation through closure. Including:

Verifying that a defect is valid and unique Assessing and assigning the severity of a defect Ensuring that a defect is prioritized and assigned to the correct owner Monitoring the resolution progress with the appropriate development group Managing any defect disputes to closure Coordinating the promotion of the software changes to resolve a defect into the

staging environment with the operations group and test execution team Working with the development group to understand the impact of the defect

resolution and defining the scope of the defect verification testing Scheduling the defect resolution verification testing with the test execution team Coordinating and facilitating the go/no go meetings at the end of an iteration Producing, analyzing, and publishing the defect management performance reports

Development Liaison

The development liaison is the person designated from each development group to coordinate the defect management process. Their responsibilities include:

Supporting the QA defect coordinator to ensure that defects are valid, unique and assigned to the appropriate development group for resolution

Coordinating defect resolution efforts with ongoing development to maintain a high level of responsiveness to defects while minimizing negative productivity impacts

Verifying that software changes by the development group have been in compliance with quality development practices and fully unit and integration tested


Working with the QA defect coordinator to assess the process impact of the software changes

Working with the QA defect coordinator and operations group to migrate the changes into the staging environment

Representing their respective development groups in defect disputes and go/no go discussions

Developers

The developers are responsible for: Investigating the defective software Designing the changes needed to address the defect Making the appropriate code changes Unit and integration testing the changes Applying quality development practices and procedures Working with the development liaison to get the changes migrated into the

staging environment and verified by the QA team.


defect management process

Documents