What should constitute an Action?

In ACCELQ, an Action represents a modular block of automation logic used as a step within a business process Scenario, performed in a specific Context (or page). Designing Actions with the correct granularity is crucial for maximizing reusability, minimizing maintenance efforts, and ensuring a business-focused orientation for Scenarios.

Follow these guidelines to achieve well-designed Actions:

Embrace Business Semantics

An Action should encapsulate the logic required for a meaningful step in a business process. Avoid breaking down Actions into granular steps that are not of significant business value.

For instance, "Login to QBank" is an Action, while "Enter username" or "Enter Password" are not, as they are just statements in achieving the Login process.

Context (or Page) as a Natural Boundary

When determining the appropriate granularity of an Action, consider using the application page (Context) as a guiding boundary. In most cases, an Action's scope should be limited to a single page. Avoid spanning Action logic that goes across multiple pages unless specific circumstances require it.

For example, an Action named "Populate Funds Transfer Info and Verify Confirmation" is not an ideal encapsulation, as it involves logic on two different pages. Instead, split it into two distinct Actions: "Populate Funds Transfer Info" and "Verify Funds Transfer Confirmation". This approach ensures that each Action remains focused and aligned with the corresponding page, promoting modularity and ease of maintenance.

Foster independence

Avoid combining multiple independent functions into a single Action. Separate distinct tasks even if they belong to a single Context.

For example, if a Scenario requires verifying recent activity and current balances on the Account Summary Page, create two separate Actions: "Verify Recent Activity" and "Verify Current Balances”.

By separating distinct tasks into individual Actions, you increase code reusability and simplify maintenance, making it easier to update specific functionalities without affecting others.

Logic unbound by its size or complexity

Do not let the extent of logic dictate Action boundaries. An Action could have a large number of statements or very few statements in it.

Simple functions like navigation may involve just one or two statements (e.g., hover, click) but should be considered independent Actions if they lead to switching the user to another page. This approach ensures a modular and flexible automation structure.

Leverage effective parameterization

Make the most of parameterization to eliminate redundant Actions. Instead of creating duplicate Actions for various input data combinations, utilize parameters to customize the Action's behavior dynamically.

Thoughtful Naming Strategy

Name Actions in a way that reflects their purpose throughout the entire application. Choose descriptive names, avoiding ambiguous or technical terms. Emphasize "what" the Action accomplishes over "how" it accomplishes it. Use action verbs for clear representation.

Harness Sub-Actions for Maintainability

Employ sub-actions when necessary for technical maintainability. Sub-actions, called internally by main Actions, can improve code organization and reusability without affecting the Scenario perspective.

By adhering to these guidelines, you ensure that Actions in ACCELQ are meaningful, reusability-oriented, and aligned with business processes. Well-designed Actions enhance the effectiveness and maintainability of your automation efforts, contributing to a successful testing process.