The Majority of the programming community worked under the assumptions that programs are written solely for machine execution and are not intended to be read by people. The only way to test a program is by executing it on a machine. Weinberg built a convincing strategy that why programs should be read by people, and indicated this could be an effective error detection process.
Experience has shown that “human testing” techniques are quite effective in finding errors, so much so that one or more of these should be employed in every programming project. The method discussed in this Chapter are intended to be applied between the time that the program is coded and the time that computer based testing begins. We discuss this based on two ways:
- It is generally recognized that the earlier that error are found, the lower are the costs or correcting the errors and the higher is the probability of correcting the errors correctly.
- Programmers seem to experience a psychological change when computer-based testing commences.
Inspections and Walkthroughs
Code inspections and walkthroughs are the two primary “human testing” methods. It involve the reading or visual inspection of a program by a team of people. Both methods involve some preparatory work by the participants. Normally it is done through meeting and it is typically known as “meeting of the minds”, a conference held by the participants. The objective of the meeting is to find errors, but not to find solutions to the errors (i.e. to test but not to debug).
What is the process involved in inspection and walkthroughs?
The process is performed by a group of people (three or four), only one of whom is the author of the program. Hence the program is essentially being tested by people other than the author, which is in consonance with the testing principle stating that an individual is usually ineffective in testing his or her own program.
Inspection and walkthroughs are far more effective compare to desk checking (the process of aprogrammer reading his/her own program before testing it) because people other than the program’s author are involved in the process. These processes also appear to result in lower debugging (error correction) costs, since, when they find an error, the precise nature of the error is usually located. Also, they expose a batch or errors, thus allowing the errors to be corrected later enmasse. Computer based testing, on the other hand, normally exposes only a symptom of the error and errors are usually detected and corrected one by one.
Some Observations:
Experience with these methods has found them to be effective e in finding from 30% to 70% of the logic design and coding errors in typical programs. They are not, however, effective in detecting “high-level” design errors, such as errors made in the requirements analysis process.
Human processes find only the “easy” errors (those that would be trivial to find with computer-based testing) and the difficult, obscure, or tricky errors can only be found by computer-based testing.
Inspections/walkthroughs and computer-based testing are complementary; error-detection efficiency will suffer if one or the other is not present.
These processes are invaluable for testing modifications to programs. Because modifying an existing program is a more error-prone process(in terms of errors per statement written) than writing a new program.
24.3
RELATED POST
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
No comments:
Post a Comment