How to write an Action-Based Testing (ABT) Test Module
Test Module Template
The template shows the systematic construct of a Test Module. Following the template is an example of a complete Test Module and the step-by-step sequence of ABT test development.
Each Test Module is given a descriptive name to make it easy to identify what the tests in the module cover.
There are four sections to a Test Module: Objectives, Initial, Test Case and Final.
The OBJECTIVES section lists every objective associated with the module’s test cases and defines the scope of the test module. Objectives allow readers to understand why test cases are designed the way they are, and give an auditor a quick insight into the correctness and completeness of a test.
The INITIAL section contains the action lines required for initialization of the test. For example, actions for launching the application under test would be written here. This avoids repetitive steps when initialization is required for multiple test cases in the module.
The TEST CASE section is where test cases are created. Each test case has a representative number, accompanied by title and one or more test objective lines. The title and objective explain the test case purpose.
The FINAL section is for any cleanup operation upon test completion, such as closing the application under test.
Completed Test Module Example
The test module starts with a listing of the objectives that the tests in this module need to meet.
InitialThe initial section contains sign-in data and some variables for reservation dates.
The "pick date" action assigns a date a given numbers of days from now, to a variable. (In TestArchitect variables are preceded with "#", to indicate an expression).
Test Case 1User creates a reservation at the restaurant “Evvia”, whereupon the application is expected to respond with a confirmation email. Verification is done by sampling the confirmation a customer will receive. This illustrates the flexibility of actions to express the intention of a tester.
Test Case 2This test case makes changes to the reservation created in Test Case 1: first, the party size is changed, then the reservation date & time. In each case we check for a confirmation email.
Test Case 3Again, the reservation is amended, this time with multiple details changed.
Test Case 4Tests that a reservation can be cancelled.
FinalSigns out and closes the browser.
Creating an ABT Test Module
Following are guidelines for creating Test Modules and Test Cases.
Structure
ABT tests are typically "business" or "interaction” tests. Business tests will be like those in the Restaurant Reservations example. The details of how to reserve a table are contained in the actions.
Interaction tests verify the more detailed interactions with the UI (or API) of an application. Activities could be "enter user name", "enter password", "click log in button", etc.. It’s important to make sure business functionality is not the focus of interaction tests, and that no interaction steps are used in a business test.
Defining Test Objectives
Test objectives are the break-down of the scope of test module. They should focus on what to test— not how to test. A test objective should be clear, descriptive and distinct. An objective can be described using "cause and effect" format.
Test Case authoring
Test case authoring is done in a structured manner with actions. Details that are needed to execute the test (like which menu item to choose to open a dialog box) should not be visible unless they are important to the scope of that test module. All the details to execute the test should be contained in the selected actions.
Test Case 1 (below) is a business test case that uses two actions—"make reservation" and "check confirmation email". It can be deduced that the action "make reservation" reserves a table at the specified restaurant with details such as party size, date and time. The other action "check confirmation email" checks whether the email sent to the user contains the expected content. All the steps (and complexity), to make a reservation or check the email content, are abstracted in those two actions.
(Note: "#" is an operator in ABT Language to retrieve value of the following variable)
Structure and Syntax
Tests typically consist of actions specifying activity and verification. Often the verifications will follow the activity, but they can also be mixed. It is customary to start the names of verification actions with the word "check".
Lines 24 and 27 are action lines (or actions) in the test case.
Use a verb followed by an object to name an action. The name of an action & its argument should be descriptive and associated with AUT's GUI or business process.
Arguments are the input values needed to do the desired operation in action. An argument can be defined to have a default value, and thus be optional, but some arguments are absolutely not optional. Only input the arguments that matter for the particular context of the test.
Action Definition
At some point actions have to be defined and created. The action definition provides the details required for the activity and verification . In this example, the action "make reservation" also calls other actions ("search restaurant" and "set reservation details") that would each have their own action definitions with details.
(Note: "#" is an operator in ABT Language to retrieve value of the following variable)
Find out how organizations
like yours are using TestArchitect
Test Automation Resources
Ebook
White Paper
