Test chains vs. single test case – or why does test automation sing a different tune?
Test chains vs. single test case – or why does test automation sing a different tune?
Test coverage, a holy asset in quality assurance, has to be as high as possible in order to guarantee the quality of the existing systems to be tested in the best possible way. In our blog today we would like to illustrate why manual tests are not the best choice in times of test automation approaches.
Test chains or end-to-end test cases
Testers in manual testing field strive, utterly justified, to achieve a high test coverage throughout the test cycle the most efficient way. Usually this happens by concatenation of individual tests to test chains right up to complete end-to-end test scenarios.
In the course of manual testing the tester sets up a complete scenario based on the initial test data and tests his entire test chains, which span many transactions and modules, with this test data set.
In case an error is found over the course of the test, the tester can react accordingly and report a fault condition.
The problem is that in the course of this test chain, following steps can perhaps not be performed with the testing data of the previous test iterations because of the error found (e.g. due to a mistake an order was not created and now it is not possible to continue working with this order in the chain). The tester counteracts this problem by adapting the test data, either selecting an already existing order or through working around the problem within the order creation.
This linear execution of interrelated tests has justifiably evolved to be a favored manner of manual testing. The effort of searching for test data can be thus optimized.
Test chains in test automation
If the same approach is applied to test chains in test automation, you will then face the problem that in case of an error and in order to continue the remaining steps in the test chain, the automated tool will not simply search for an alternative solution like the manual tester but rather will issue an error message for the case.
If the error occurs in an early stage of the process, then you get an information to the quality and functionality of your system only up to the detected fault condition. The test case ends up at this point and you get no information of rest of the test case at all. This is absolutely not efficient and not up-to-date.
How does an alternative scenario look like?/ What is the option?
We neither want to decline the significance of test chains nor the importance of end-to-end tests. It is definitely essential to test the interaction of the individual system modules, the consistent process iteration, as well.
For test automation we recommend that you execute granular tests individually to get individual information for each object of verification, in order to test efficiently and gain high test coverage.
But what about the complexity of test data deployment?
Of course the individual test cases must not be sequentially constructed (only if they are merged to chains in suxxesso Test Pilots module system), but should be executable fully autonomously.
In order to guarantee this, each individual test case has to get its own test data. This could cause a severe increase of the effort for test data deployment, which based on the prior considerations is inevitable.
This is where the innovative approach of suxxesso Data Manager for test data deployment gets into the game: we teach our Data manager the requirements for test data for each particular test case only once. From this moment on the suxxesso Data Manager can provide us with live, accurate, appropriate and fresh test data for each selected test case and thus decrease the effort and complexity of test data deployment for the tester.
The best of both worlds
Therefore we can test individual tests as well as complex, subsequently constructed test chains without any effort for searching test data. This possibility is extremely valuable, especially in agile environment, since granular and detailed functionalities and end-to-end processes are both covered and thus the test coverage is maximized.
So try to react in the conception phase of your test automation strategy already to the diverse methods of verification possibilities, which are available to you in contrast to manual testing.
Are you now interested in our unique test data deployment by suxxesso Data Manager ? Then please contact us for a noncommittal talk!