Chapter 4: Testing

Overview

The goals of testing are to find defects and verify that the software meets its requirements as perceived by the user. It is unfortunate that, in many cases, the testing program is actually aimed at showing that the software, as produced, runs as it is written. That is, the tests are aimed at showing that the software does not fail, rather than that it fulfills its requirements. This is far short of the real goal of a sound testing program. Testing that is not based on challenging requirements compliance is generally a waste of time.

It has been shown that the cost of finding and correcting a defect goes up dramatically with the length of time the defect is present. This is especially true in the case of design and requirements defects. When a test program merely shows that the software runs, the design and requirements defects are going to come up in the acceptance and operation phases of the SLC. The user or customer is going to discover that the system received is not the system desired or expected. The software will have to go back through large portions of the SDLC, and the costs will be significant.

Two alternatives are to accept the system as is and live with it or to modify it while it is being used. These, too, are expensive situations. The final alternatives are to throw it out and start over or just abandon the whole project altogether. None of these alternatives is especially attractive. The answer seems to be to generate a testing program that will exercise the software against its requirements in such a way as to uncover as many defects as possible as soon as possible in the SDLC.

The types of testing covered here are unit, module, integration, user or acceptance, and regression. These tests follow the natural progression of the SLC and lead from one into the next. As the testing progresses, the emphasis shifts slightly from the pure defect search to a more sophisticated demonstration of the requirements. Early testing intends to exercise as many of the software paths as is practical in order to find mistakes in coding, errors in design, and so on. As the SDLC matures, there is less opportunity to exercise all paths of the software, so the concentration is on integrating the modules and subsystems into the whole, and exercising the growing entity against the requirements. The basic goal of finding defects remains, but there is reliance on the earlier testing for the finer, internal details of each module. Later testing deals with the system itself and its interfaces with the outside, as defined in the requirements.

It must be remembered that all testing is designed to challenge the software implementation of the approved requirements. In straightforward data processing applications, this is a straightforward task. In applications such as client-server, GUIs, or distributed processing, the approach becomes much more sophisticated. The underlying rule remains requirements-based testing. The quality control practitioner must be well versed in the types of applications being tested. To expect a practitioner with specific experience in testing traditional accounting systems to step in and immediately be successful at testing a distributed processing, embedded, real-time software system is asking too much. The quality assurance practitioner will recognize this as a training requirement and recommend that the tester be given the proper training before he or she is given the new testing task.

The testing program begins in the requirements phase and, effectively, never ends. Regression tests continue for as long as changes and enhancements are being made to the system. Figure 4.1 depicts this concept. Planning for such a long-lived effort must also begin in the requirements phase and be updated at each milestone step along the way. The planning will include not only the tests to be run, but also the resources needed, including people, hardware, support software, schedule, and so on.

click to expand
Figure 4.1: SLC testing.



Practical Guide to Software Quality Management
Practical Guide to Software Quality Management (Artech House Computing Library)
ISBN: 1580535275
EAN: 2147483647
Year: 2002
Pages: 137
Authors: John W. Horch

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net