Defect Management Process

Author: Matthew Cunliffe

Date: 30th March 2012

Version 1.0

http://www.euro-point.co.uk

Contents

1. Document Control	3

1.1 Document History	3

2. INTRODUCTION	4

2.1 Document Purpose	4

2.2 Scope	4

3. Defects	5

3.1 Defect Management	5

3.2 Defect Creation	5

3.3 Defect Verification and Prioritisation	5

3.4 Defect Assignment	6

3.5 Defect Confirmation	6

3.6 Defect Resolution	6

3.7 Resolution Verification	6

3.8 Defect Closure	6

3.9 Defect Status Lifecycle	6

3.10 Defect Evidence	6

3.11 Defect Progress	6

4. Appendices	6

4.1 Appendix A - Defect Creation in Quality Centre	6

4.2 Appendix B – Defect Status’	6

Document Control

Document History

Date	Version	Details	Author
30/03/2012	1.01	Final Version	Matthew Cunliffe

INTRODUCTION

Software testing is the process used to help identify the correctness, completeness, security and quality of developed software.

A defect is the formal logging of any fault or error which has resulted in a deviation from the expected results of formal or informal testing. This can include, but is not limited to, faults identified in the functional operation of the software, deviation from technical or functional documentation, deviation from requirements, environmental issues, test data issues, test script issues, and faults identified in the functional or technical documentation.

Document Purpose

The purpose of this document is to define the process flow, controls and resources that will be employed for defect management within the Programme. This document should be used by anyone who needs to understand, participate, or support this Defect Management process.

Scope

This process will govern all defects identified by the team responsible for QA testing of the Project as well as any specification faults identified by the development or test teams. This process will also be used to support defects identified during and any other test phase, including Unit, User Acceptance, Operational Acceptance and Third Party Supplier testing. The process should be adopted by all teams and parties raising, managing and updating defects.

The process must be followed to ensure defects are managed efficiently and directed to the appropriate teams for early resolution. The following areas are within scope of this document:

Defect creation

Defect Verification

Defect Prioritisation

Defect Assignment

Defect Confirmation

Defect Resolution

Defect Closure

Defect Tracking Tool

Defect Reporting

Defects

Defect Management

This section explains in further details the guidelines for the management and progression of defects and how to raise a defect.

The Defect Management process and lifecycle will follow a specific flow aiming to give exact statuses of defects, assigning the correct priority and severity, ensuring the defect is with the correct team and individual and to provide minimal uncertainty for progressing them.

{HP Quality Centre (QC) will be the application used to log and manage all defects and will also allow us to produce the desired reporting statistics.}

All defects will be given a unique reference number which is used as the main reference point for the defect.

Defect Creation

A defect is created where there a discrepancy between expected results and actual results.

The person executing the test will open a new defect with a status of ‘New’ and an Item Type of “Defect” with a brief description, provide information regarding the operating conditions that were in place when the defect occurred, where in the application process 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.

Appendix A documents the defect creation process in Quality Centre.

Defect Verification and Prioritisation

Once a defect is created, the development lead for the Product to which the defect is assigned 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:

Technical Priority – The impact a problem is having on the testing team being able to continue testing that specific area of the application.

Business Severity – The impact a problem would have on the Customer or the Business if it were put into a Live environment.

The table below lists the classification types that apply to Technical Priority.

Classification	Impact
1-Very High	This problem is preventing any further testing of this area of the application from taking place
2-High	This problem is not preventing testing completely; however, some areas of the application are affected and therefore cannot be tested.
3-Medium	Impact of this problem is having a minor effect on testing, perhaps preventing one or two test scripts from being completed.
4-Low	Impact of this problem is having no effect on testing but may be a cosmetic issue that could be fixed at a later date.

Once a problem has been identified during a testing phase, it will be raised with the Business and discussed. If appropriate the Business will agree a Business Severity for the problem, log it as an issue and progress.

The table below lists the classification types that will apply to Business Severity.

Classification	Description
01-Very High	Faults causing a severe operational impact for which no acceptable workaround is available thus making use of a Deliverable or all items of Software in a Live environment impractical. A fault with an otherwise lesser classification may be categorised at this level if, in conjunction with other resolved faults, it meets this definition.
02- High	Faults causing an operational impact but which do not prevent use of a Deliverable or an item of software in a Live environment or do have an acceptable workaround.
03-Medium	Faults causing minimal to no operational impact.
04-Low	Cosmetic or documentation only faults.

Defect Assignment

The individual raising the defect ensures that Assigned To and Responsible team fields are updated.

The defect can be assigned to one of the following groups:

Test Team

Development

Release Manager

Third Party (Choose from the available list)

If none of the above applies then the defect must be assigned to an individual.

Defect Confirmation

Once a defect is assigned to a development team, the development lead for the Product reviews the defect information, confirms that the defect has been assigned to the correct development team and that the defect is valid. If the development lead does not agree with the creation, assignment, or prioritisation of the defect they may dispute the defect and work with the person who raised the defect, business owner, and other development teams to resolve the dispute.

Defect Resolution

A defect can be resolved in the following ways:

Where there is a configuration issue with the system under test, the configuration is corrected and the defect report updated to reflect what was done to resolve the issue.

Where a defect is identified as a fault with the system under test, the defect is scheduled as part of a release by Release Management. The defect(s) are assigned to the Test Team once the patch is deployed into the test environment for testing and verification. The Test team will retest the defect and any test scenarios against which the defect was raised, and identify version of software and the environment in which the defect was retested. For example:

“This defect was successfully passed using <patch release> on <environment>. The defect can be closed.”

Resolution details must be added to all defects as a comment: this will indicate what has been done to fix the defect.

Any other comments regarding the defect must be added to the defect within Quality Centre to provide an audit trail. Examples of such comments are: rejection reasons; comments on failure and success of retests; emails relating to discussions of the defect; and reasons for upgrading or downgrading the severity or priority.

Resolution Verification

The test lead will review the defects that have been identified as “ready for retest”, identify the set of test scripts that should be run to verify that the defect has been resolved and assign the defects to the appropriate test analyst for retest.

Defect Closure

Upon verification that a defect has been resolved, the defect can be closed by the test analyst. A test analyst can close defects where a retest has taken place and passed.

Defect Status Lifecycle

There are a number of defect statuses that are used to describe the exact progression of the defect through its lifecycle. Appendix B explains each status, what statuses it can be changed from and to, and which teams have authority to change the status.

The typical defect lifecycle is as follows:

The defect is raised by the test analyst and is set to New. This is then assigned to the development lead for the appropriate Product who will assign it to the relevant development team member for analysis.

When the investigation of the defect takes place by the relevant development team member, the status is set to Investigating.

After analysis and where a resolution has been identified, the status is set to Fixing by the development team member.

Once the resolution has been carried out to solve the defect this is then set to Fixed by the development team member and the defect assigned to the development lead for the Product.

The development lead for the Product will identify in which release of the Product the defect will be delivered and assigns the defect to the Release Manager. When a defect has been deployed into the test environment the status is changed by the Release Manager to Awaiting Retest and is assigned to the test lead for the Product.

The test lead for the Product will then assign the defect to the relevant test analyst for retest.

When the defect is being retested, it is set to Retesting by the test analyst.

If the retest is successful, the test analyst will set the defect to Closed.

If the retest is unsuccessful, the test analyst will set the defect to Retested – Failed and reassign it back to the development lead for the Product.

Where a defect is set to Investigating or Retested – Failed and the investigation deems it is not to a defect, then the state is set to Rejected by the development lead and is assigned back to the test lead for the Product with a response to state why the defect is rejected

The test lead then either passes the defect to the relevant test analyst to confirm the rejection or retains the defect.

If the rejection reason is valid then the defect is set to Closed by the test lead or the relevant test analyst.

If the rejection reason is invalid following discussion, the defect is set back to Retested – Failed by the test lead or test analyst and assigned back to the development lead for the Product.

A defect is assigned a status of Blocked only where the Test Team are unable to retest a defect due to other impacts, e.g, the test environment is down. However the defect must be updated to reflect the reason.

The status of Awaiting Further Information is set by either the Test Team or Development Team when further details are required from any teams or individuals and a comment added detailing the information required.

If a defect has been identified as a Change Request then the status is set accordingly by the test lead for the Product.

The status of Deferred is used by the test lead for the Product if a defect fix is planned to be released in a subsequent phase or is on hold for any other reason.

Any defects that are raised against 3rd party systems will be set to 3rd Party by the test analyst when waiting for their analysis.

Defect Evidence

Providing evidence helps to identify the resolution to the defects raised. Evidence can be attached at the time of raising the defect or can be attached later in the cycle.

When raising a defect the following is included:

Evidence such as screenshots and error logs

A step by step description of the scenario that resulted in the defect

Where a scenario is retested, a screenshot of the scenarios must be attached in the instance where a test has failed.

Defect Progress

Outstanding defects may be discussed as part of daily defect management meetings where resolution cannot be achieved outside the meeting.

Appendices

Appendix A - Defect Creation in Quality Centre

When raising a defect in Quality Centre, a number of fields are mandatory. Without these fields being populated, the defect cannot be submitted. All mandatory field names are highlighted in red.

As much evidence as possible is attached at this stage. Below is a series of steps that explain how raised a defect or specification issue.

Login to Quality Centre.

Select the Defect module from the left hand menu.

Figure 1 - Defects Module

Click on the ‘New Defect’ link.

Attach snap shots Attach evidence

Figure 2 - Initial Defect Screen

Item Type

Figure 3 - Initial Specification Issue Screen

The field names highlighted in red are mandatory and must be populated.

All details are entered using the pre-determined values in the drop down lists; they will correspond to the phase, release and functionality so the appropriate options can be selected.

Item Type

This identifies whether the issue to be raised is a “Defect” or a “Change Request” or any other Type (such as “Specification Issue”) and should be identified as such.

Summary

This identifies the functional area for which the defect is being raised.

In the description section, details of the process carried out, expected and actual results are documented.

The defect description structure to be followed is:

Description (including steps to recreate the fault)

Expected Result

Actual result

Comments (including comments made by any contributor to the defect, including the fault resolution and fix details>

Once this is completed, click on the SUBMIT button. A number is assigned to the defect.

Clicking on the CLOSE button at any time closes the defect window.

Appendix B – Defect Status’

Defect Status	Meanings	Can Change From	Can Change To	Team allowed to set this status
Business Analyst Co-ordinator	Test Team	Development	Business Analyst	Project Manager
Awaiting Further Information	If further clarification is required from another party before continuing with resolution	Open New Fixing Updating Specification	With 3rd party Change Request Closed Fixing Updating Specification	√	√	√	√	√
Awaiting Retest	The defect fix has been released to system test environment.	Fixed Awaiting further information	Retesting Awaiting further information	√
Change Request	A Change Request is required.	New Investigating Awaiting further information Rejected	Closed	√	√	√	√
Closed	The fix has passed or the defect no longer exists. The defect was raised in error or further analysis dictates that it is not a defect.	Retesting New Rejected 3rd Party Awaiting Further Information Resolved	Reopen	√
Deferred	The defect is Deferred to a later release.	New Investigating Reopen	Investigating Fixing Closed	√	√	√
Fixed	A fix has been completed by development and ready for release.	Fixing	Awaiting retest	√
Fixing	Development teams agree that a fix is required for the defect and they are in the process of providing one.	Investigating 3rd Party Reopen	Fixed	√
Investigating	The defect is being investigated	New Deferred Awaiting Further Information 3rd Party	Rejected Fixing Change request Updating specification	√	√	√	√	√
New	The initial status when raised.	Investigating Awaiting further information Deferred 3rd Party Closed	√	√	√
Rejected	Development or the Business Analyst do not agree that the defect is valid.	Reopen Investigating New	Reopen Awaiting Retest Closed	√	√
Resolved	The specification has been updated by the Business Analyst	Updating Specification	Closed	√	√
Retested - Failed	If a defect fix has failed retest it will be set to Retested - Failed and assigned back to Defect Management	Rejected Closed Retesting	Rejected Fixing	√
Retested – Passed	The defect has passed and is assigned to Defect Management will then set it to Closed.	Retesting	Closed	√
Retesting	The defect is now being retested.	Awaiting Retest	Blocked Closed Reopen	√
Updating Specification	The specification is being updated by the Business Analyst	New Investigating Awaiting further information Rejected	Resolved	√	√
With 3rd party	A defect exists with 3rd party provider system and they have taken ownership to investigate or provide a solution	New Investigating Awaiting further information	Investigating Fixing Closed	√	√	√

End of Document