The Economics of Software Quality (Frank Feng's Library) by Capers Jones & Olivier Bonsignour

Author:Capers Jones & Olivier Bonsignour
Language: eng
Format: epub
Publisher: Addison-Wesley Professional
Published: 2012-06-15T16:00:00+00:00

Table 5.1 will probably be controversial for several reasons. One of the reasons for controversy is the fairly low level of defect removal efficiency for many kinds of testing listed—there are, of course, ranges above and below the data shown in Table 5.1.

Another reason for controversy is that Table 5.1 is not complete, and at least ten other kinds of testing are occasionally used (the authors lack data for these additional forms of testing).

A third reason is that testing nomenclature varies from company to company and also changes over time. For example, the term system test as used in Table 5.1 was originally defined by IBM in the 1970s as the final internal test stage for large systems after all components had been tested separately and the final system integration had taken place. Normally, “systems” were fairly large and ranged between 10,000 and 100,000 function points in size. In today’s world the system test can mean the last internal test stage regardless of whether the application is a true multicomponent system larger than 10,000 function points or merely a small stand-alone program fewer than 100 function points in size.

More recently the Agile methods have started to use unit test in a fashion that differs from older uses. In older paradigms unit testing came after coding, but in Agile test-driven development (TDD), the test case comes before the code.

It is an interesting question that if test-driven development had existed in 1985, would it have prevented the Y2K problem from occurring? The most probable answer is that TDD would not have eliminated Y2K if the embedded users insisted on a two-digit date format. TDD does not eliminate toxic user requirements, which can still find their way into code if users insist on doing something harmful.

Some additional forms of testing not shown in Table 5.1 were pointed out by Rex Black, a testing consultant and author: accessibility testing, interoperability testing, sociability testing, data migration testing, and data quality testing. The last two forms of testing dealing with data are important, but there is no available size metric for data volumes, so it is not possible to show numbers of data defects in a normalized form. (The industry needs a “data point” metric similar to function points for software.)

As stated previously, Table 5.1 assumes a nominal size of 10,000 function points or 500,000 logical code statements in a language such as Java. Test defect removal efficiency goes down as application size goes up, as does test coverage. Table 5.1 is intended to show only approximate results derived from a number of companies, but results can and do vary widely.

The columns of Table 5.1 have the following meanings:

The column labeled Assignment Scope in Function Points refers to the approximate number of function points that will normally be tested by one person—either a professional tester or a software developer. The ranges in assignment scopes are about 25% in either direction from the nominal values presented.

The column labeled Test Cases per Function Point shows the average values from among the authors’ clients.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.