Browse Prior Art Database

Software Defect Prediction with Complexity and Regression Matrix

IP.com Disclosure Number: IPCOM000031211D
Original Publication Date: 2004-Sep-17
Included in the Prior Art Database: 2004-Sep-17
Document File: 2 page(s) / 62K

Publishing Venue

IBM

Abstract

Defect estimation based on relative complexity factor and percentage of regression test cases for independent test phases.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Software Defect Prediction with Complexity and Regression Matrix

Disclosed is a technique used for planning the cost of testing software applications. Test cost estimates require not only an estimate of the number of test cases to be created and executed but, also the number of defects that will be uncovered during the test cycle.

When the test lead does not have information on the applications quality prior to test entry or its size (based on Function Points or Lines Of Code) then traditional defect prediction methods are not always possible. The 'CRDM' (Complexity Regression Defect Matrix) method is based on the complexity of the application and the portion of regression test cases to be executed during the test phase. Historical test projects have shown that test projects that are mostly regression testing will yield fewer defects that project's that are all new function. Furthermore, this method is flexible enough to allow adjustment by an informed test lead that has intimate knowledge of the application to be tested.

First, derive an estimate of the total number of test cases needed for the project. Next, determine what percentage of the total test cases to be executed will be regression tests.

Finally determine the relative complexity level of the application.

Low Complexity
* Simple PTFs effecting few areas of an existing application/service
* Minor modification of existing and well understood code modules, generally less than 10%.
* Only one development team and one development process
* Single programming language used for the project

High Complexity

* Code changes effecting many areas of the application/service
* A major upgrade or change to the application/service infrastructure or environment
* Project involves working with new vendor supplied code, unknown quality.
* Several development teams geographically dispersed.
* More than one development process
* Several programming languages and tools being used in development.
* Completely new service with no existing code base

Medium Complexity should be somewhere in-between those two levels and is based on the...