Before creating visual tests, scripts, and other Silk Test Workbench assets to build application testing solutions, it is a good practice to plan a testing strategy.
It is not necessary to include all the parts of a specific test solution in a single visual test or script and is not usually beneficial to do so.
Typically, the most efficient testing approach is a modular approach. Think of your application testing in terms of distinct series of transaction units.
For example, testing an online ordering system might include the following distinct transaction units:
Log on to the online system
Create a customer profile
Place orders
Log off the online system
If one test is created to handle all of these distinct units and there are ten different scenarios that use this test, you would need to record ten different tests to handle the scenarios. If any change occurs to the application, for example if an extra field is added to the logon window, ten different tests would require a change to accommodate data input to the new field.
Rather than creating one visual test or script that tests all of these transaction units, and then recreating it ten times for each scenario, it may be more beneficial to create separate tests as test "modules" that handle each one of these transaction units. If a separate test is created for each of the separate transaction units and reused for each of the test scenarios, then only the test that handles the logon transaction unit would require change.
When you run the driver script, it calls and runs each script in succession.
With a modular approach, you can create one additional test to test stock validation, then update the driver script to call it in its appropriate sequence. The following example shows a driver script that runs separate scripts to test the online ordering system.
Workbench.RunScript ("OnlineLogOn_Script")
Workbench.RunScript ("CreateProfile_Script")
Workbench.RunScript ("ValidateStock_Script")
Workbench.RunScript ("PlaceOrders_Script")
Workbench.RunScript ("OnlineLogOff_Script")
Implementing a modular testing strategy in this manner also makes it easier to facilitate changes in the test flow.
For example, if an additional transaction unit is required to test the online ordering system such as validating stock prior to placing orders, you need to change ten tests to handle stock validation for the ten different test scenarios.
This modular approach enhances reusability but does not necessarily accommodate different test "scenarios", where a testing strategy involves repeating a sequence of transaction units multiple times, using different data each time a transaction is run. ActiveData enables you to use external data sources to enhance the reusability of modular test scripts in application testing.
Functions can also be called from driver scripts to test solutions that can be reused in different application tests.