VBM - Vision Based Methodology™

Activity 9: Constructing the System

Testing, Testing, Testing

Keys to a successful testing experience:

• The ability must exist to directly enter, manipulate, and view information on the chosen database in order to set up the various required test conditions.
• The ability must exist to rapidly be able to create, view and edit sequential batch files for the same reasons as above.
• During the construction and testing phase, security limitations within the testing environments should not be a deterrent to continual progress.
• Individual programmer test data as well as shared, common database information should be coordinated and logically separated (using numeric ranges, etc.) where possible.

Even utilizing today's most contemporary methodologies, three levels of testing are still traditionally followed during system construction:

Unit Testing

This test is typically performed by the individual programmer upon completion of coding (usually after the final code walk-thru and sign-off). A unit test plan is prepared which includes all possible program scenarios. This "checklist" is then utilized to create the test data cases, to sequence the order of the testing, and to record the completion of each successful test. This stage of testing is critical! The more rigorous and complete the testing is here, the smoother and more rapid the testing will be in the upcoming stages. It is imperative that each programmer is made accountable for the quality of his or her program, and in addition, each must be responsible for "proving" program excellence through unit testing.

Equally important is the level of discipline the coding team leader maintains in verifying the test results. This "program sign-off" should consist of a check for completeness of test conditions, full situational coverage, adequately varied data values, and successful results.

String/Integration Testing

Once a series of programs or modules which must eventually work or communicate with each other have been coded and unit tested, performance of an initial "string" test is in order. Both the on-line (window) modules and the batch (processing) modules or programs should be included in the scope of the testing at this point. This "stringing" together of the programs or modules for execution as a unit, tends to be a somewhat informal process directed at finding any communication or parameter passing problems which may not yet have been detected.

Also, since different programmers may have worked on each program or module, or different analysts may have worked on separate action diagrams (for code generation), the possibility exists that problems such as input/output field formatting, switch/indicator setting, or expected status updating may not be consistent across modules. Ferreting out all of these coding errors now, before a formal system test is performed, will save both time and frustration in the later testing stages.

Again, discipline on the part of the coding team leader at this stage is vital. The mission during string testing is both the detection as well as the correction of programming/code generation problems. Adequate data must be created to demonstrate that proper field formatting, accurate parameter passing, and correct event triggering is occurring. A "sign-off" should not be given until the entirety of the connected/integrated modules or programs are working as a smooth, seamless, and error free unit.

System Testing

This is a formal test of the system in its entirety. Planning for System Testing is the primary determinate of the final delivered system quality. It can mean the difference between conducting a complete application "scrubbing" or a lame courtesy check of the system operation. People seldom remember when you get something to them late, but they always remember when you get it to them wrong.