Learn How to Set-up Test Scripts to Save Time and Money

 For testing any type of diagram can be used as a basis for the creation of the test script. I will demonstrate how in my series on “UML and Testing”. Best suited for testing are the diagrams in which the process flow is defined. In this article we will use the example of a decision diagram and a cause-effect diagram. Process flow diagrams can be defined on a high abstraction level. These high level diagrams can be detailed. The diagrams can be built up in a modular way. Specifications for high risks product/process parts will be detailed more than for other parts. After the diagrams are finished and approved we almost have an approved test script. For manual testing the test scripts are derived from the process flow diagrams. All you need to do is put in the text for the requirements represented by the blocks in the diagram. Time saver number 1. Experienced testers could do without the written test script, for them the diagrams are enough. Time saver number 2.

When the process flows are created properly and the test scripts are derived from those diagrams, then all the functionality is defined in the same test scripts. The difference between the various tests is that each time something else in the path fails. Everything has to be tested true and false. Not only do you want to know if the process runs correctly, you also want to know if something goes wrong the correct error messages are presented etc. If you put all parts of the test script together you actually have one script in which all requirements are integrated. So you can define one end-to-end test with everything in it - at any depth you want. A True-False table could help create the different tests in which all the True-False variations that you want to test are defined. Logic and data can be kept separate. This is explained in detail in the book “Q-Course Quality & Organization”.

The results of clever modeling is that the tests can easily be automated. In the automated scripts you use the same modular structure as you do in the hand scripts based on the process models. The modular way that you set-up the test scripts will now pay off. The only difference between the different tests is that each time other requirements are set to False or True, and the data is different in each test. True/False and data can be defined in automated script using parameters. So if you create one “mother script” which you can use for all tests. Automation is supposed to be effective if you repeat a test at least 5 times. Suddenly automating test scripts can be very effective… because of the structured way you modeled the requirements. Time saver number 3. Because of the modular structure plus the separate logic and data, the scripts for both manual and automated testing can be easily maintained.