Browse Prior Art Database

Test Cycle Time Reduction Complexity Ranking

IP.com Disclosure Number: IPCOM000117071D
Original Publication Date: 1995-Dec-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 8 page(s) / 228K

Publishing Venue

IBM

Related People

de Weaver, M: AUTHOR [+6]

Abstract

In analyzing the number of hours spent testing a given processor product, it is often difficult to determine how the time spent compares to other test efforts. Making a one to one comparison of the test hours is often misleading because of the different complexity associated with each machine. This disclosure will address this problem by assigning a complexity ranking for each processor product under test. This will allow the test hour results to be normalized across machines to determine whether the test process is shortening or lengthening. A by product of this work is to be able to estimate the number of hours required for a future test by examining the complexity ranking prior to the start of test.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 24% of the total text.

Test Cycle Time Reduction Complexity Ranking

      In analyzing the number of hours spent testing a given
processor product, it is often difficult to determine how the time
spent compares to other test efforts.  Making a one to one comparison
of the test hours is often misleading because of the different
complexity associated with each machine.  This disclosure will
address this problem by assigning a complexity ranking for each
processor product under test.  This will allow the test hour results
to be normalized across machines to determine whether the test
process is shortening or lengthening.  A by product of this work is
to be able to estimate the number of hours required for a future test
by examining the complexity ranking prior to the start of test.

      To be able to quantify complexity ranking, arbitrary bounds are
assigned.  The lower bound is set to 0 and the upper bound is set to
9.  All parameters are normalized to meet this criteria.

There are four categories being examined:
  1.  Size/Count of code.
  2.  Usability of test tools needed for test.
  3.  Experience of test personnel and proximity of test and
       development sites.
  4.  Phasing in of function during test cycle.

      The parameters for each category can be combined in various
ways to provide an estimate for complexity ranking.  As an example
this document will present a set of mathematical equations showing
how these parameters can be combined.

      The first three factors each have an equation associated with
them.  Each equation will result in a value from 0 to 9 (0 is least
complex, 9 is most complex) based on several criteria unique to that
factor.  The results from these three equations are combined as a
weighted average to provide the overall complexity ranking prior to
the start of the test cycle.  The last factor is used to checkpoint
the complexity of the project at the end of the test.  If function
was phased in during the text cycle then a factor of complexity will
be added to the initial complexity ranking to obtain the final
ranking.

Effect of Lines of Code

      To illustrate we will describe a set of parameters that can be
used to determine the test complexity for a processor product based
on the amount of code present.
  Component: Component is defined to be a section of code that makes
              up an independent unit.
  Function:  Function is defined to be a collection of components.
  Driver:    Collection of functions.
  KLOCS:     Lines of Code/1000.
  CC:        Component Complexity is an indicator of how many
different tasks a component performs.  A task is an action, with one
interface, where a component is involved.  If a component is
considered to be very complex a value of 1 is assigned otherwise a
value of 0 is assigned.  CC = 0 or 1.
  RCS:       Relative Component Size                    0 <= RCS <= 1
       ...