Test Module Template

How to write an Action-Based Testing (ABT) Test Module
Test Modules are containers for tests of user stories or software requirements. Every test module has a clear and well-differentiated scope from every other test module to avoid redundant activities and checks. This makes tests less fragile and easier to maintain. Giving each Test Module a descriptive name makes it easy to identify what the tests in the module cover.

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.

The Test Module template and example is available for download.
Download

Completed Test Module Example

The Test Module example below is for a test of a restaurant reservation application. It follows the user story "As a registered user, I want to be able to reserve, change and cancel a restaurant reservation".
Objectives

The test module starts with a listing of the objectives that the tests in this module need to meet.

Initial

The 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 1

User 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 2

This 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 3

Again, the reservation is amended, this time with multiple details changed.

Test Case 4

Tests that a reservation can be cancelled.

Final

Signs out and closes the browser.

Completed Test Module Template

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 Module Template Objectives

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.

Test Case Authoring Module Template

(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".

Test Module Template Structure

Lines 24 and 27 are action lines (or actions) in the test case.

Test Module Template Syntax

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.

Test Module Template Action Definition

(Note: "#" is an operator in ABT Language to retrieve value of the following variable)

Discover how organizations
like yours are using TestArchitect
Kratos Partners with LogiGear to Implement Continuous Testing to Reduce Testing Cycle from 6 Weeks to 24 Hours
Centrify Leverages Testing Platform to Achieve an 80% Automation Rate
Innovative Interface Inc., Uses TestArchitect to Reduce Regression Test Execution Time by 94%
Copyright © 2022 LogiGear Corporation. All rights reserved. LogiGear is a registered trademark, and Action Based Testing and TestArchitect are trademarks of LogiGear Corporation. All other trademarks contained herein are the property of their respective owners.

LOGIGEAR CORPORATION

1730 S. Amphlett Blvd. Suite 200, San Mateo, CA 94402

Tel +1(800) 322-0333