Entity Definition: Action

What is an Action

An Action is a meaningful test function defined in a Context. For example, when you are in the QBank Login Page (Context), you may have possible Actions such as:

• Login to QBank
• Initiate forgot password
• Verify footer links etc.

Actions need not just be limited to UI-based interactions or verifications.

For example, you may have an Action in Account Summary Page, Get current balance from database, which just retrieves the current balance for an account from the database.

Action is defined in a Context

QBank Login Page, Account Summary Page, etc. are considered “Owner” or “Origin” Contexts for respective Actions. An Action utilizes resources available from its owner Context.

Multiple Actions may be defined in a given Context and all such Actions share the resources such as Views, Elements, etc.

What does an Action contain?

Action contains the “logic” or “statements” to achieve the test function. For example,

• Login to QBank Action will have statements to enter a user name, enter the password and click on the sign-in button.
• Initiate forgot password may have a statement to click on the “Forgot Password” link.
• Verify footer links Action may have multiple statements to verify the footer links in the QBank Login Page.

Statements may include UI interactions, UI verifications, non-UI commands such as connecting to a database, reading an email, or other logic control statements. Logic forms the crux of an Action.

Destination Context

When an Action is performed which includes statements for UI interaction, the application state may change. Destination Context of an Action indicates which page/Context the application will be in, after the completion of this Action.

For example, Login to QBank may lead the application to the Account Summary Page.

There are multiple options available for specifying the “Destination Context” of an Action. You will learn more about destination contexts in a detailed topic.

Action is used in a Scenario

A Scenario, which represents the use case you are testing on your application is formed by combining a series of Actions. An Action becomes a “Step” in a Scenario.

An Action is “modular” in nature and “reusable” by definition.

A Scenario is made up of series of Actions and a given Action can be used in multiple Scenarios.

Granularity of an Action for Web/UI testing

When defining an Action, it is very important to decide on the right “granularity” of the Action. What is the “scope” of the Action going to be? Consider the following pointers:

• An Action should be meaningful from the functional and testing perspective.

“Login to QBank” is a good example of an Action

“Enter user name in Login screen” is not a great example.

The latter has no “functional” relevance. An Action, which becomes a “Step” in a Scenario should feel functionally meaningful and relevant.

• Scope of a function should be limited to a given page (Owner Context). An Action should not cross into multiple pages.

For example, “Initiate Forgot Password”, which just clicks “Forgot Password” link, is a good example of an Action. It does not seem “functionally complete”, but still the right granularity considering the page boundary. An Action’s scope should be limited to a page (Owner or Origin Context). Remember you achieve “complete” functionality flow in the Scenario where you combine multiple Actions together.

Action granularity is a very important component of achieving a modular and reusable automation design. Be sure to pay enough attention when defining Actions.

Name an Action appropriately

Action naming is also an extremely important part of a sound automation design. Follow these guidelines:

• Keep the Action name functional and meaningful. For example, “Verify funds transfer confirmation” is better than “Verify confirmation”. Prefer clarity, even if the name is verbose.
• Feel free to use spaces and other allowed special characters while naming an Action. Don’t be tempted to use underscore characters, upper-camel, or lower-camel formats. For example, “Login to QBank” is preferred over “loginToQBank” or “Login_To_QBank”.
• Action name should be an imperative or a command-verb tone. For example,
• Verify footer links – good
• Verifying footer links – bad
• Verification of footer links – bad

Someone reading the Scenario steps should be able to clearly understand the purpose of each Action and the overall flow without having to open up the Action and read the logic. Remember, you want to keep automation accessible to the whole team, not just the original author of the test.