systems will require a similar degree of functional testing and will
suffer some of the same problems associated with testing,
documentation, consistency and so on. It is assumed here that the
obvious method of sudividing the problem into a number of individual
modules has been used. Each module is designed and tested in some way
separately before being integrated into a final system.
For test approaches, look at the IVM
Top 10 Principles of Testing.
Integration is not a big-bang approach: such an idea is stupid for
anything but the most trivial system. Design and testing follows the
standard V test process, and integration of modules in the whole
follows the V, with unit testing before the sub-integration, and
compliance testing afterwards.
Here we are concerned primarily with module or unit testing. Compliance
testing may be similar!
Test methods are covered in the IVM
Test Method Index.
The follow diagram indicates a typical flowchart of such testing
emanating from module specifications and any requisite software or
coding standards. Note that the prototype software/hardware does NOT end up copied into the module,
it may be rewritten or serve as an example, but nobody writing
production level code that requires and degree of reliability would
allow protoype/hacking code to enter a production module.
© Mission Technologies Ltd
2004. Reproduced with the permission of IVM.