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.
Now that you understand the basics of modular testing, you are ready to create a second test and add it to the test you created in the previous lessons.