An important part of the inspection process is the use of a checklist to examine the program for common errors. The checklist is largely language independent as most of the errors can occur with any programming language.
Is a variable referenced whose value is unset or uninitialized? This is probably the most frequent programming error; it occurs in a wide variety of circumstances.
For all array references, is each subscript value within the defined bounds of the corresponding dimension?
For all array references, does each subscript have an integer value? This is not necessarily an error in all languages, but it is a dangerous practice.
For all references through pointer or reference variables, is the referenced storage currently allocated? This is known as the “dangling reference” problem. It occurs in situations where the lifetime of a pointer is greater than the lifetime of the referenced storage.
Are there any explicit or implicit addressing problems if, on the machine being used, the units of storage allocation are smaller than the units of storage addressability?
If a data structure is referenced in multiple procedures or subroutines, is the structure defined identically in each procedure?
When indexing into a string, are the limits of the string exceeded?
Have all variables been explicitly declared? A failure to do so is not necessarily an error, but it is a common source of trouble.
If all attributes of a variable are not explicitly stated in the declaration, are the defaults well understood?
Where a variable is initialized in a declarative statement, is it properly initialized?
Is each variable assigned the correct length, type, and storage class?
Is the initialization of a variable consistent with its storage type?
Are there any computations using variables having inconsistent (e.g. Nonarithmetic) data types?
Are there any mixed mode computations?
Are there any computations using variables having the same data type but different lengths?
Is the target variable of an assignment smaller than the right-hand expression?
Is an overflow or underflow exception possible during the computation of an expression? That is, the end result may appear to have a valid value, but an intermediate result might be too big or too small for the machine’s data representations.
Is it possible for the divisor in a division operation to be zero?
Where applicable, can the value of a variable go outside its meaningful range?
Are there any invalid uses of integer arithmetic, particularly division? For example, if I is an integer variable, whether the expression 2*I/2 is equal to I depends on whether I has an odd or an even value and whether the multiplication or division is performed first.
If the program contains a multi way branch (e.g. a computed GO TO in Fortran), can the index variable ever exceed the number of branch possibilities? For example, in the Fortran statement,
Will I always have the value 1,2, or 3?
Will every loop eventually terminate? Devise an informal proof or argument showing that each loop will terminate
Will the program, module, or subroutine eventually terminate?
Is it possible that, because of the conditions upon entry, a loop will never execute? If so, does this represent an oversight? For instance, for loops headed by the following statements:
DO I=X TO Z
What happens if NOTFOUND is initially false or if X is greater than Z?
Are there any non-exhaustive decisions? For instance, if an input parameter’s expected values are 1,2, or 3, does the logic assume that it must be 3 if it is not 1 or 2? If so, is the assumption valid?
Does the number of parameters received by this module equal the number of arguments sent by each of the calling modules? Also, is the order correct?
Do the attributes (e.g. type and size) of each parameter match the attributes of each corresponding argument?
Does the number of arguments transmitted by this module to another module equal the number of parameters expected by that module?
Do the attributes of each argument transmitted to another module match the attributes of the corresponding parameter in that module?
If built-in functions are invoked, are the number, attributes, and order of the arguments correct?
Does the subroutine alter a parameter that is intended to be only an input value?
If files are explicitly declared, are their attributes correct?
Are the attributes on the OPEN statement correct?
Is the size of the I/O area in storage equal to the record size?
Have all files been opened before use?
Are end-of-file conditions detected and handled correctly?
Are there spelling or grammatical errors in any text that is printed or displayed by the program?
TEST CASE DESIGN
TEST CASE DESIGN TWO
DESIGN OF TEST CASES PART THREE
TEST CASE DESIGN PART THREE
TEST CASE DESIGN PART FOUR
TEST CASE DESIGN PART FIVE
TEST CASE DESIGN PART SIX
TEST CASE DESIGN PART SEVEN
TEST CASE DESIGN PART EIGHT
TEST CASE DESIGN PART NINE
REVIEWS AND APPROVAL OF TEST CASES
WRITING SOFTWARE TEST CASES PART ONE
WRITING SOFTWARE TEST CASES PART TWO
WRITING SOFTWARE TEST CASES PART THREE
WRITING SOFTWARE TEST CASES PART FOUR