EIGHT BASIC PRINCIPLES OF TESTING

Following are eight basic principles of testing:

1. Define the expected output or result.

2. Don't test your own programs.

3. Inspect the results of each test completely.

4. Include test cases for invalid or unexpected conditions.

5. Test the program to see if it does what it is not supposed to do as well as what it is supposed to do.

6. Avoid disposable test cases unless the program itself is disposable.

7. Do not plan tests assuming that no errors will be found.

8. The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module.

Let's look at each of these points.

1) DEFINE THE EXPECTED OUTPUT OR RESULT

More often that not, the tester approaches a test case without a set of predefined and expected results. The danger in this lies in the tendency of the eye to see what it wants to see. Without knowing the expected result, erroneous output can easily be overlooked. This problem can be avoided by carefully pre-defining all expected results for each of the test cases. Sounds obvious? 

2) DON'T TEST YOUR OWN PROGRAMS

Programming is a constructive activity. To suddenly reverse constructive thinking and begin the destructive process of testing is a difficult task. The publishing business has been applying this idea for years. Writers do not edit their own material for the simple reason that the work is "their baby" and editing out pieces of their work can be a very depressing job.

The attitudinal l problem is not the only consideration for this principle. System errors can be caused by an incomplete or faulty understanding of the original design specifications; it is likely that the programmer would carry these misunderstandings into the test phase.

3) INSPECT THE RESULTS OF EACH TEST COMPLETELY

As obvious as it sounds, this simple principle is often overlooked. In many test cases, an after-the-fact review of earlier test results shows that errors were present but overlooked because no one took the time to study the results.

4) INCLUDE TEST CASES FOR INVALID OR UNEXPECTED CONDITIONS

Programs already in production often cause errors when used in some new or novel fashion. This stems from the natural tendency to concentrate on valid and expected input conditions during a testing cycle. When we use invalid or unexpected input conditions, the likelihood of boosting the error detection rate is significantly increased.

5) TEST THE PROGRAM TO SEE IF IT DOES WHAT IT IS NOT SUPPOSED TO DO AS WELL AS WHAT IT IS SUPPOSED TO DO

It's not enough to check if the test produced the expected output. New systems, and especially new modifications, often produce unintended side effects such as unwanted disk files or destroyed records. A thorough examination of data structures, reports, and other output can often show that a program is doing what is not supposed to do and therefore still contains errors.

6) AVOID DISPOSABLE TEST CASES UNLESS THE PROGRAM ITSELF IS DISPOSABLE

Test cases should be documented so they can be reproduced. With a non-structured approach to testing, test cases are often created on the fly. The tester sits at a terminal, generates test input, and submits them to the program. The test data simply disappears when the test is complete.

Reproducible test cases become important later when a program is revised, due to the discovery of bugs or because the user requests new options. In such cases, the revised program can be put through the same extensive tests that were used for the original version. Without saved test cases, the temptation is strong to test only the logic handled by the modifications. This is unsatisfactory because changes, which fix one problem often, create a host of other apparently unrelated problems elsewhere in the system. As considerable time and effort are spent in creating meaningful tests, tests, which are not documented or cannot be duplicated, should be avoided. 

7) DO NOT PLAN TESTS ASSUMING THAT NO ERRORS WILL BE FOUND

Testing should be viewed as a process that locates errors and not that proves the program works correctly. The reasons for this were discussed earlier.

8) THE PROBABILITY OF LOCATING MORE ERRORS IN ANY ONE MODULE IS DIRECTLY PROPORTIONAL TO THE NUMBER OF ERRORS ALREADY FOUND IN THAT MODULE

At first glance, this may seem surprising. However, it has been shown that if certain modules or sections of code contain a high number of errors, subsequent testing will discover more errors in that particular section that in other sections.