Once you record your logic in a Scenario, it is important to modularize the flow for better maintainability. ACCELQ follows the Test Asset approach, which involves breaking down the Scenario flow into modular components for easier management and maintenance over time. These components are called Actions, and any statements that are not part of Actions cannot be included in a Scenario.
An Action forms a "Step" in a Scenario and can include a set of statements.
Creating Action from Selected Statements
In the Scenario Workbench, you can simply select a sequence of statements, right-click and choose "Create New Action and Replace". A step-by-step wizard guides you through the process to build a well-designed Action.
Read through the rest of this article to understand how to best structure your Action.
Deciding what forms an Action
In the Scenario Workbench, you select a sequence of statements and choose to create an Action. It is important to understand the optimal boundaries for breaking down the statements into Actions. The objective is to create the best possible business-process view for your test automation while ensuring long-term maintenance.
A well-defined Action:
- Represents a business-level component, accomplishing a meaningful unit-step in the overall test scenario.
- Is performed on just one page (Context), and does not cut across multiple pages.
Example Action | Recommended? | Notes |
Login to QBank | Yes | A well-defined step in a business flow. |
Navigate to Account Summary | Yes | Even though it may just involve clicking a link on a page, this activity has a proper business semantic. |
Enter user name | No | This is just a low-level logic of how you perform login, and not a meaningful business function. |
Login and verify funds transfer | No | The granularity of Action should be a unit step. Not a flow that cuts across multiple pages. |
Naming an Action
An Action must be named meaningfully to reflect the business step it is automating. Do not hesitate to use spaces or longer names to clearly suggest what the Action is supposed to accomplish.
Action is best named as an action verb in English. For example, "Navigate to Account Summary Page" is a better choice than "Navigating to Account Summary Page".
Origin and Destination Contexts
An Action is performed on a given application page, which is referred to as the Origin Context. And once an Action is performed, it leads the application to another page, which is referred to as the Destination Context.
Name the pages (or Contexts) meaningfully to reflect the application functionality. These names are just for reference, and not related to the application's implementation detail. Maintain a consistent convention for naming the Contexts, so that it is easy for your team members to understand.
Here again, use spaces and longer names if required to clarify.
Deciding on parameterization
Parameterization is central to achieving effective reusability of Actions. An Action may need to be exercised with different variations of inputs when you use it in Scenarios.
Note: Optimal parameterization promotes data-driven capability. At the same time, not every input for an Action is probably worth parameterizing. Overly parameterized Action makes it difficult to maintain.
More about Action parameterization and best practices in this article.
Outputting information from an Action
In the statements you selected to create an Action, there may be information you are extracting or reading from the application. Check if this information is of value for other steps in the Scenario (Business Process), and mark those as Action Outputs.
For example, this highlighted statement extracts the total balance from the screen and returns it as the Output from Action so that other Steps in a Scenario can make use.
Ensuring consistency of selected statements
In order to strictly manage the business process semantics and avoid deviation from the principles of modularity, ACCELQ enforces certain requirements on the consistency of statements selected for Action creation.
If the selected statements include Action calls (rather than just independent statements), the following rules must be satisfied:
- The Destination Context of all the Actions that are part of selected statements must be "unspecified" or "current context".
- The Origin Context of all the Actions that are part of selected statements must be either "All Contexts" or the Actions must be Init Actions.
Here is an article about the concept of Action Applicability.
Comments
0 comments
Please sign in to leave a comment.