Understand the scripting entities: types of scenarios, components, and sections that can make your scripts easy to organize, build, edit and organize in ScenarioBuilder.
Action: An Action is a step in a scenario that represents a single event (such as a mouse click or an application launch). Actions are located in a pane on the left side of the ScenarioBuilder window and can be added to scenarios by double-clicking or dragging into the Scenario Window.
Scenario/Script: *The terms “Script” and “Scenario” are interchangeable!*
A scenario is an XML file created with ScenarioBuilder. A scenario contains Actions that emulate the activity of a user interacting with an application.
Scenarios can be tagged as one of 3 types: tagging helps you group and find scenarios quickly.
- Global Scenario - For sets of actions that you will use often (in more than one script) take advantage of Global Scenarios. These are independent scripts that you can call into any scenario in your project. Examples are Logging in and Logging out. A Global Scenario is created just like any other script. To call a Global Script into another script, add the Play Script action and select the Global Script in the Script Name property.
- Process Scenario- This lists actions for one process.
- Flow Scenario- This includes several processes.
Component: A Component is a user-defined shell within a scenario that contains a single Action or a series of Actions for each screen. Think of Components as containers for Actions related to a specific task in the overall process. Breaking up scenarios into Components makes for easier scenario maintenance, and can be helpful in conceptualizing a scenario design.
If you have a long script, we recommend dividing it into components. For example, if you had an end to end test for processing purchase orders you could create components for each screen in the process:
Search for a Vendor
Add a Purchase Order
If your end-to-end purchase order script is 210 steps, it can become very hard to work with. If you group the actions into components, it becomes much easier to manage.
Components live in one script. (If they are shared by other scripts then that set of actions would be better as a Global Script)
Each component can have its own On-Failure
Each component can have its own parameters (CSV file) assigned to it.
To create a component, double-click Define Component. A new tab appears in your script. Add the needed steps or cut them from the parent script and paste them into the component. Then in your main script add an Execute Component action.
Transaction: A Transaction is a section of a scenario that is marked for the purpose of measuring the response time of that section. For example, you can define a Transaction to be "login to CRM" where the beginning of the Transaction is defined when the CRM application is launched, and the end of the Transaction is defined when the CRM interface finishes loading on the screen. Many Actions may occur within a Transaction (such as finding the executable to launch the application, launching the executable, waiting for the login screen, typing in the login name and password, waiting for the application to load completely, etc.).
OnFailure: The “OnFailure” section of a scenario determines what Action(s) to take when a scenario or Component fails. For example, if your application crashes during a test, “OnFailure” actions could shut down and restart the application and attempt to resume the scenario where the crash occurred.
Response Time: Response time is the amount of time taken to execute a Scenario, Component, Transaction or step within a scenario. The system calculates the response time from taking the end point of your Scenario or Transaction and subtracting it from the beginning point of your respective Scenario or Transaction respectively.
A Scenario Section allows you to group a few common actions together in a script. You can call on these Sections into other scripts at any time.
Sections simplify updates with scripts when the application has a redesigned look and feel (changes with color changes or menu style changes).
Common Example: Most applications have some form of navigation (menu, tabs, buttons, etc.). Interacting with this navigation is done in every script created for this application. Rather than putting in the steps to navigate the application in each script, create one navigation script. Then name the steps to get to each menu item as a separate Scenario Section (created by adding a name in the Scenario Section property).
In your scripts, when you need to navigate to a menu item, instead of adding the actions and taking images to do that, just add the Play Script Section action to your script and point it to the Scenario Section that has those steps.
This setup becomes VERY beneficial should a major change be made in the navigation of the application such as rebranding or changing the color scheme. Now you only have to update the images and steps in the sections in your navigation script for the changes to be made in all your scripts.
Read more on how to manage Scenario Sections here
You will find these tools make scripting much easier. Don’t worry if you don’t think of all possibilities up front. You can always go back and create Global scripts or Components if you are in the middle of scripting and notice that these steps will be used more often. Simply copy the actions and paste them into a newly created Global script or component.
If you need any assistance with your scripting strategy, contact Automai support.