This is a guest post by Hans Lumadjeng. Hans is an expert on chain testing in the Netherlands where the emphasis of his approach lies in the mitigating of business risks.

In past decades our clients were confronted with the ‘spin-off’ of System Integrations (SI) in different areas where a lot of information (data) was transported through different systems or platforms. One of the main reason to implement SI projects was the business’ needs to acquire reliable information which is provided by different (units of the) organizations. The keywords are uniqueness, consistency and fastness. Along with the development of these processes we ‘stumbled’ across the coexistence between ‘build’ and ‘test’ activities.  System integration test that focused on the test of the working of different parts of a system as a whole (see e.g.  IEEE 829 or ANSI), was considered insufficient. There are not one, but more main systems that are being linked.  Chain testing was introduced in the last decade to deal with the complexity of software testing where the systems are maintained by different organizations. That’s why Chain Testing is sometimes also called “System Integration Test in the Large”.  From the historical perspective it could therefore be understood why the word ‘test’ or ‘testing’ is used as chain testing is much associated with software testing.

With the growing maturity of the testing processes we also see that the (deterministic) ‘ICT approach’ for chain testing was OK but not sufficient to deal with the (newly introduced) risks that come along with linking of business processes. Where the product risk analysis (PRA) technique was introduced to identify business risks to be able to apply the correct test strategy, one realizes that cost versus benefit of testing (coverage) plays an important role in this approach. Unfortunately; this approach, which is derived from risk analysis, is usually not backed up by (statistical) data. Therefore the equation R = ∑ p(i) Li (R=total risks, Li=Lost or Impact and p(i)= chance for the corresponding Lost of Impact) could only be applied to explain the methods.  On the other hand we are faced with the extra complexity that not only ICT systems are linked, but also the (non ICT) business procedures. The ‘classical’ role of a test manager that is responsible for the whole (software) testing processes during the development phase of a system is being questioned. The dimension of business processes and risks are added to the total ‘test’ scope.  It introduces new interesting discussions about the role and responsibility of a test manager, test director or test architect; e.g. who is responsible to conduct a PRA session. ‘The businesses‘, said one. ‘But “the business” is a container for (key) users, process owner, line managers etc. and they do not know nothing about testing’, said the other.

Not pretending to have the final answer…Capgemini has put its vision and its practical approach toward the issues and complexity of Chain Testing into a book that was published in 2008. A new revised version of this book will be published in May this year (2011).