The Software Development Life Cycle - Software Testing: Testing Across the Entire Software Development Life Cycle - page 36

That is ok because there is plenty to test in the documentation of the fi rst three
phases. Documents are tested to verify they are correct, complete, accurate, use
good spelling, use good grammar, and are properly formatted. This kind of manual
testing is sometimes called “paper and pencil testing'' because computer execution
is not required. The more formally recognized term for this document testing is
static testing . As we have seen in Chapter 1, if the system requirements are not static
tested, then errors in the requirements will show up later as expensive program-
ming defects. The PDM demonstrates that there are documents written before the
requirements documents that can, in fact, cause the requirements documents to have
errors. This documentation dependency further underscores the importance of the
tested correctness of the earliest documents written.
Programmers do not normally refer to their code as “documentation,'' but in
fact it needs to be static tested like a document. If you have ever participated in code
inspections or code walk-throughs, these are some of the ways code is static tested
before it is executed for functional, structural, and performance verifi cation.
As the development progresses, other documents are produced that need to be
static tested as well. Examples of these later documents are End User Guides, Opera-
tor Guides, Training Manuals, and Installation Guides.
Once the development staff begins to write program code, additional kinds of
testing are needed as the code begins to work and are successively larger components
or modules of the application. Chapters 7-9 will provide a detailed treatment of the
code execution kinds of testing. The majority of this execution testing is considered
“active'' testing because the tests intentionally cause the code to behave in certain
expected ways. Once the new system is installed, some kind of monitoring will prob-
ably be employed to verify the continued operation of the system as designed and
tested. This kind of testing is considered “passive'' testing because the tests do not
cause the code to behave in certain ways; rather, the tests only observe and report the
behavior of the system doing routine business.
The Installation phase of the PDM is the only phase in which no testing occurs.
This phase presents its own challenges to the development and production teams
but not the testing team. The testing team has already validated that the system
will successfully install and that the persons responsible for operating the system
can perform the install correctly. This installation verifi cation is accomplished in
the last steps in the Final construction phase. To understand this approach better,
place yourself in the role of the new system owner who must sign a document
saying that the new system is ready for installation in production. Remember that
production is the way your company sustains daily business on the computer. Put-
ting anything untried in production is playing Russian Roulette with your entire
business. Are you really going to agree that the new system is ready for installation
in production without seeing proof that the new system passed all Final construc-
tion tests? We hope not.
Table 2.1 is a summary of the above testing discussion by PDM phase with a
little additional detail in the code producing phases to set the stage for the Chapters
7-9 presentations.