Metrics for Strategic QA

by RentTesters on June 22, 2011

Strategic QA helps organizations track faults across the software development lifecycle, providing QA managers with the insight necessary to predict fault levels, testing budgets and,
more importantly, allows them to focus process improvement budgets in an efficient way with provable benefits. Strategic QA not only helps organizations become more competitive, it also reaffirms the value of the QA manager in the project team and the organization.

#SQASolutionShare on FacebookShare on Google+Share on LinkedInTweet about this on TwitterEmail this to someone


student September 19, 2008 at 5:25 pm

One of the metrics to use is to capture the number of defects found in each phase of SDLC


• Requirements analysis
• Design
• Implementation / Coding
• Unit Testing
• Integration testing
• System testing
• Customer usage (maintenance)

PMP September 19, 2008 at 5:27 pm

I would also recommend to capture the number of defects that were carried over to a next phase

qageek September 19, 2008 at 5:31 pm

By capturing fault data on projects, organizations can estimate Fault Density (FD) – the number of faults present in a work product per size, where size is defined accordingly for each phase. Requirements and Design Fault Density may be expressed by Faults per Page, while Coding Fault Density may be measured by Faults per Line of Code (LOC) or by Faults per Function Point.

qageek September 19, 2008 at 5:44 pm

Build a table from a historic projects and capture the data to predict the next similar project F.E.

Size Historic # of changes (number of pages divide by number of issues)
Predicted issue rate = number of (pages or lines of code) * historic ratio
%of issues resolved in this phase historically
% of issues carried over to the next phase historically

six sigma September 19, 2008 at 5:48 pm

You also need to capture the development phase in which the error was found and, and upon resolution, also indicate the phase in which the error could have been

six sigma September 19, 2008 at 5:53 pm

Information to be collected for each error or defect should include:
• Fault description
• Category
• The phase in which the fault was found (Requirements, Design, Code, Unit Testing, Integration Testing, System Testing, Customer, not classified)
• How the fault was found (peer review, visual inspection, design model simulation…)
• The phase in which the fault was introduced (Requirements, Design, Code, not classified, Prior release, 3rd party)
• The phase in which the fault should have been detected
• The cost of the fault

Previous post:

Next post: