A test conductor is assigned responsibility for the preparation,
execution, and analysis of a set of test cases. The conductor schedules
the people, the computer time, physical facilities, and any other
resources required for these test cases. Before beginning a test, the
conductor assures that all participants and observers are on hand and
that they have all required materials, such as scripts, checklists, and
predicted outputs.
After completing a test or series of tests, the conductor calls
together the participants to analyze the results. Sometimes they
complete analysis and assess success or failure immediately. In other
cases, outputs are require study and the conductor sets up another
analysis meeting. Whatever the case, the conductor is responsible for
declaring a test a success or failure and reporting the result to
management. A simple form should document the results. It included the
test case identification number, the test date, and the result. If the
result was unqualified and the test conductor follows up to be sure
programmers are assigned to correct them. The test conductor also takes
the lead in deciding what further testing must be done after programmers
make fixes. After a repair there are several testing options from which
to choose.
- The fix may involve a documentation change only, so that no
retesting need be done.
- The change may require a major overhaul in one or more program
modules because the Problem Specification was misinterpreted.
Sometimes, consultation with the customer will enable you to
negotiate around making a change.
- An analysis, design, or coding change may be required that affects
portion of the system already tested. You should assume that all
changes have that effect. Now the test conductor, with the
programmers’ help, decides how much regression testing is
necessary. Regression testing means retesting previously finished
portions of the system to insure that a late change does not ripple
back through the system causing new problems. Regression-test
decisions are tough to make. Simple changes have a way of churning
up the very bowels of the system. Always lean toward more regression
testing than the programmers advise.
- Descriptive documentation may be in error. These descriptions must
agree exactly with the programs and with the Design Specifications.
Insist that every module submitted for system test be cleanly
compiled- no patches or undocumented "stub" programs
allowed.
When a system or subsystem has passed cleanly through the final
system test, lock the programs and their documentation in the library to
await acceptance demonstration.
|
