Modularizing Scenario steps for better maintainability

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 before a Scenario can be finalized and submitted, it can only include a series of Actions as statements.

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.

Further examples on Action boundaries

Here are a couple of useful considerations when deciding the boundaries of Actions.

Clicking on a button or a link on a page that results in a new page loading can often serve as a suitable boundary for an Action. However, this is merely a guideline and may not always be the most optimal approach. There may be cases where a click operation only leads to an inline expansion of the page without significantly updating the application's state, which would be an exception to this guideline.

On the other hand, sometimes when deciding on an Action boundary, you may choose to modularize for a better logic organization rather than just a consideration of business process semantics (Scenario level step requirement).

For instance, let's say you have an Action to search for a flight on a travel website. From a Scenario perspective, a meaningful Action could be "Search for a flight," which requires multiple parameters like origin, destination, travel dates, and so on. However, if this Action logic involves a significant amount of logic statements that could be broken down into modular blocks, it might be beneficial to create Actions such as "Populate Origin and Destination" and "Populate Travel Dates" etc, and call these Actions internally in the "Search for a flight" Action. These actions could be disabled at the scenario level to avoid confusion when creating a business process. So, when building Scenario, user would just be exposed to "Search for a flight" as a step.

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.