System testing was once left until everything else had been done. At that time,
all the programs and data were brought together and everyone held their breath
to see if the conglomeration actually worked. After a while, it started dawning
on mangers that the only process that actually works well when performed this
way is the staging of a demolition derby.
Just as we go through design and programming by getting a little part right
and then adding to that little part, system testing should start early and be
cumulative. Both the system being tested and the breadth and depth of the test
criteria should expand as modules finish unit testing and are brought into the
mainstream.
You should start system testing once the first skeletal subsystem is ready to
stand on its own. I mentioned my approach of starting with the Log-In and
Security Check functions for a system. Once these are working to the
satisfaction of the programmers, move them into system testing. Once they pass
their tests, they become Version 0.0 of the final system. From that point, it’s
simply a matter of adding enough functionality to get to Version 0.1 and so
forth. The tests you developed for Version 0.0 should work just as well with
Version 0.1 and you can keep building on this base.
The collection of tests that you accumulate makes it easy to perform what’s
called "regression testing", where you test the newest version of the
system to ensure that the functions that worked in previous versions still work.
If your customer is participating in the system test process, a regular program
of regression testing will help convince the customer that the project is moving
steadily forward.
|
