System Integration

Dedicated to the dissemination of System Integration information

System Integration Testing

System Integration Testing (S.I.T.) is the testing of the sub-systems, as a whole, to ensure that they work as a system.

 

The testing should be driven by the requirement specification and the System Integration (S.I.) engineer’s knowledge of what the system should do.

 

No requirement specification can fully define a system, their will always be gaps in what the requirement specification states and what is expected of a system. 

 

As an extreme, the requirement specification will not state that the system should not burst into flames after an hour of operation but this is certainly a requirement, i.e. no one would be happy if the system burst into flames after an hour of operation.

 

This is where the experience of the S.I. engineer comes into play, as he/she carries out their work they need to keep their eyes open for any faults or problems.  The S.I. engineer needs to be aware that faults will be present that will only be found through informal testing, i.e. running the system and seeing what happens.

 

The S.I.T. should ensure that the system meets the requirements of the formal requirements specification document and also that any implied, or ‘common sense’ requirements are met.

 

S.I.T. should also take place in different environments, e.g. different temperatures.  This does not have to be anything fancy, e.g. fully fledged ‘environmental’ testing, but can be as little as turning the air flow down, or up, a little, turning the lab thermostat up or down a little, it is amazing how little changes in the environment can affect the performance of a system.

 

Broad view of what should be tested in System Integration

I have added a ‘cause and effect’ fishbone diagram of the situations, or environments, that affect system performance.  It is a bit big but that is the only way you would see the detail of the diagram.

Search this site or the web powered by FreeFind

Site search Web search