In an earlier post I’ve told something about an end-to-end test. Now I wanted to give a further update.

Complex
End-to-end Testing is complex. It is a concatenation of multiple sub-processes within an organization. Your test is going through the complete business process. Maybe end-to-end tests are not just complex, but very complex. End-to-end testing is part of acceptance testing [2006, TMap NEXT] and form a test performed within the system integration test (SIT). But when do we actually perform and end-to-end test. Should we it as soon as possible during the acceptance tests, because then we are the fastest in the chain from design errors? Or is it better to perform the test when all components are thoroughly tested and the program in end-to-end chain are stable? Actually, both ideas are good. However, for each end-to-end test the best option should be considered. I deliberately say each end-to-end test and not project, more on that later!

Risks
Where projects speak of product risks, end-to-end testing speaks of chain risks. Within the chain risks the chances of failure of other (sub) processes should be considered over their own sub process, which can cause damage. An end-to-end test is often initiated from within a project because something has changed to a system within the chain. Sometimes other chains are involved in an end-to-end test, even other organizations. The chains of today are so complex that they no longer fit within the organization. Think of supplying lots of information.

The failure rate is therefore outside the own sub process. By using other stakeholders, which participate in the complete processes, in the end-to-end test the probability of failure can be determined. The damage is difficult to determine. Because the damage of the chain is only evident at the end. At the end of the business process it will be clear what the pain is.

Because the probability of failure and damage often doesn’t relate directly to the own sub process it is recommended not to place and end-to-end test outside the project, but in the line of the organization. The line can give a better consequence of errors in the chain and this is also the responsibility of the operation in the business. Often the consequences of failure within a sub process are not clear. For example, if 1 piece of the business has a lower test coverage retention it can have terrible consequences for the entire process. Everything is within the end-to-end test is extrapolated.

Specify
Once the test strategy for the chain is determined, it is time to specify test cases. For this we use the test cases from other test forms and other test levels. Thus, the recoverability of these previously developed test cases are important. But to convert these test cases into end-to-end test cases is more complex. A test case consists of an initial situation, an action and an expected result. This expected result is again the starting position (initial situation) of the next test case in the chain. Any additional information between the test cases should be processed to obtain a better test case.

An end-to-end test covers mainly the control of the dependencies within the business process. An end-to-end test starts with tying the beginning of the chain and ends only after the end of the chain. Pay attention! Testing is often unfortunately the drain of a project and end-to-end testing the drain of testing.

1. Software Testing Services Says:
   August 18th, 2010 at 09:41

   Software testing is bit complex thing to do though it is a mandatory part in the development cycle. You have explained the type end-to-end testing which is the most complex type to do in an organization.