|
When the going gets tough, testing gets squeezed.
The purpose of testing varies between each phase but it is basically to check
that the application conforms according to the Functional
Spec. - you DO have one don't you - and there are no bugs in it.
There is never a good time to call a stop to testing. You always face the
reality that if there are bugs in the application then either the test team or
the user will find them.
If the test team find them they will get upset but you will at least be able to
fix the bugs reasonably quickly. However, if the users find them you as a team
will look bad and fixing the bugs will be very expensive and require release
management.
The areas here cover the basic aspects of testing, starting with the testing
that developers should do, through to the testing that the users should do.
There is over-lap between these sections in the real world.
If you do it poorly the results can be expensive. NASA recently crashed
a probe into Mars because one supplier was working in Imperial rather than
Metric units. This sort of error should have been picked up before the
probe left Earth. I suspect NASA relied too heavily on Unit testing.
If you over-do testing the application ships late and the users complain
about your inability to deliver.
Somewhere in the middle is the fuzzy ground of 'good enough to ship'.
|