DEFECT MANAGEMENT

Process Definition
Version DRAFT, 06/25/2004
Revision History
Version Date Updated By Modifications

Defect Management Process Definition p 2 of 9

Version DRAFT 06/07/2004
Table of Contents
Executive Summary.............................................................................................................4
Process Control....................................................................................................................4
Process Objectives...........................................................................................................4
Key Performance Indicators ...........................................................................................4
Process Owners................................................................................................................4
Process.................................................................................................................................5
Inputs................................................................................................................................5
High-Level Process Flow.................................................................................................5
Defect Creation............................................................................................................5
Defect Verification.......................................................................................................5
Defect Prioritization.....................................................................................................6
Defect Assignment.......................................................................................................6
Defect Confirmation....................................................................................................7
Defect Resolution.........................................................................................................7
Resolution Verification................................................................................................7
Defect Closure.............................................................................................................7
Outputs.............................................................................................................................7
Roles & Responsibilities..................................................................................................8
Business Owner...........................................................................................................8
QA Test Execution.......................................................................................................8
QA Defect Coordinator................................................................................................8
Development Liaison...................................................................................................8
Developers...................................................................................................................9

Defect Management Process Definition p 3 of 9

Version DRAFT 06/07/2004
Executive Summary
The 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.

Defect Management Process Definition p 4 of 9

Version DRAFT 06/07/2004
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

Telescope QA Testing Defect Management Process
High-level Workflow

Review open
Business

defects and
assign priority
QA Test Execution

Identify defect Setup test Close as

Execute tests Tests passed? Yes
No data “Resolved”

No

Verify defect
Verified as a Clear
QA Defect Management

and assign Yes Prioritized? Yes

new defect ownership?
severity

No Yes
Review Identify
Close as “Not a Assign Schedule Coordinate
defects targeted and
Defect” or link to No development testing within software
“ready for regression
existing defect ownership iteration cycle promotion
QA” scripts to run
Identify defect
ownership

Review Dispute
Development Liasion

defect defect Still a defect?

information

No No
Yes

Identify Assess Update defect

Confirm Defect Component Assign to
Yes defective Yes potential to “ready for
defect confirmed? owned by team developer
component conflicts QA”
Developers

Design Update Unit Develop Unit Test Defect resolved Merge Integration
Investigate Yes
Change Test Plan Change Change by developer Change Test Change

No

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:

Defect Management Process Definition p 5 of 9

Version DRAFT 06/07/2004
 Severity Code 1: High
A 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: Medium

A 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: Low

A 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: Critical

Must 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: High

Must 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: Medium

Does 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: Low

Can 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 Management Process Definition p 6 of 9

Version DRAFT 06/07/2004
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.

Defect Management Process Definition p 7 of 9

Version DRAFT 06/07/2004
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

Defect Management Process Definition p 8 of 9

Version DRAFT 06/07/2004
 • 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 Definition p 9 of 9

Version DRAFT 06/07/2004