0% found this document useful (0 votes)
149 views18 pages

Defect Tracking and Management: Best Practices by Gabriel Rodriguez

Defects need to be recorded, monitored, reported and corrected. The primary goal is to prevent defects. The Defect Management process should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk. The following structure is recommended to report a defect: +Title: Type a brief description of the problem +Comments: Type any comments or notify to the developers of any screenshots (attachments)

Uploaded by

Srinivas Reddy G
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
149 views18 pages

Defect Tracking and Management: Best Practices by Gabriel Rodriguez

Defects need to be recorded, monitored, reported and corrected. The primary goal is to prevent defects. The Defect Management process should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk. The following structure is recommended to report a defect: +Title: Type a brief description of the problem +Comments: Type any comments or notify to the developers of any screenshots (attachments)

Uploaded by

Srinivas Reddy G
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Defect Tracking and

Management

Best Practices
By
Gabriel Rodriguez
Agenda

 Defect Management
 Defect Management Process
 Q&A
 Reference

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
 A major test objective is to identify defects. Once identified,
defects need to be recorded, monitored, reported and corrected.
 The primary goal is to prevent defects.
 The defect management process like the entire software
development process, should be risk driven, i.e., strategies,
priorities and resources should be based on an assessment of the
risk.
 Defect measurement should be integrated into the development
process and be used by the project team to improve the
development process
 Defect information should be used to improve the process
 Imperfect or flawed processes cause most defects.
Copyright 2006-2007. MSQAA Federation Chapter.
Defect Management
 A defect can be defined in one of two ways
– From the producer’s viewpoint
 A defect is a deviation from specifications, whether
missing, wrong, or extra
– From the Customer’s viewpoint
 A defect is anything that causes customer dissatisfaction,
whether in the requirements or not; this is know as ”fit for
use.”

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
 The following structure is recommended to report a defect:
– Title:
 Type the problem encountered in the application, the title needs to be
understandable
For Example:
You can use the following categories:
 Missing
 Inaccurate
 Incomplete
 Inconsistent
 Incorrect

 Example:
 Missing validation in “Project” field
 Incorrect spelling in “status” drop down list

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
 Description
– Type a brief description of the problem
 Repro Steps:
– Type all the steps to get to the problem, all steps must be
cleared
For example:
1.- Login to FIDO
2.- Click on Add Invoice
3.- Type !@#$%% in Project field
4.- Click on Save
Copyright 2006-2007. MSQAA Federation Chapter.
Defect Management
 Actual Results
– Type the actual results of the action
For example:
The following error message is displayed..
– Comments:
Type any comments or notify to the developers of any screenshots
(attachments)
For Example: This defect is reproducible in Project field. (see
attached file)
 Expected Results
– Type the expected results of the action.
For Example:
Data should be saved successfully.

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
 Test Environment
– Include details of the test environment

For Example:
Microsoft Windows 2003 Standard
Office 2003
 The following slide shows an example of a complete Defect
Report

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
 Consider the following caveats
– Most of the organizations have a Defect Tracking Tool to log
the defects found during Test Execution, one of the most
common tools in the market is Test Director of Mercury tools
– The budget in some organizations is limited to afford buying a
commercial tool, thus they prefer to create their own defect
tracking process
– A very simple way to track the defects of the application is
using a spreadsheet of Excel
 The following slide shows an example of a complete Defect
Report and a Defect Tracking Sheet in Excel
Copyright 2006-2007. MSQAA Federation Chapter.
Defect Management
Defect Report Example

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management
Defect Tracking Example

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management Process

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management Process
 The steps below describe a simple defect tracking process:
– Execute the test and compare the actual results to the
documented expected results.
– If a discrepancy exists, log the discrepancy with a status of
“open”. Supplementary documentation, such as screen prints
or program traces, should be attached if available.
– The test manager or tester should review the problem log with
the appropriate member of the development team to determine
if the discrepancy is truly a defect.

Copyright 2006-2007. MSQAA Federation Chapter.


Defect Management Process
– Assign the defect to a developer for correction.
– Once the defect is corrected, the developer will usually enter a
description of the fix applied and update the defect status to
“Fixed” or “Retest”.
– The defect is routed back to the test team for retesting.
– Additional regression testing is performed as needed based on
the severity and impact of the fix applied.
– If the retest result match the expected result, the defect status
is updated to “closed”. If the test results indicate that the defect
is still not fixed, the status is changed to “open” and sent back
to the developer.
Copyright 2006-2007. MSQAA Federation Chapter.
Q&A

 Any questions…

Copyright 2006-2007. MSQAA Federation Chapter.


Reference

 CSTE Study Guide 2002 by QAI


 CSTE Study Guide 2006 by QAI

Copyright 2006-2007. MSQAA Federation Chapter.


Thank you…

Copyright 2006-2007. MSQAA Federation Chapter.

You might also like