Scribd
Upload
633 views

TestPLan Template

This lightweight test automation template provides a standardized structure for functional tests with an emphasis on automation. The template defines key elements like the system under test, separating test configuration from execution, and using an object-action-parameters structure for test steps. It includes sections for the test name and purpose, setup, fixture, recovery strategy, test matrix, parameters, and a table to describe the test steps in terms of object, action, and parameters.

Uploaded by

veereshkumarg
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
633 views

TestPLan Template

This lightweight test automation template provides a standardized structure for functional tests with an emphasis on automation. The template defines key elements like the system under test, separating test configuration from execution, and using an object-action-parameters structure for test steps. It includes sections for the test name and purpose, setup, fixture, recovery strategy, test matrix, parameters, and a table to describe the test steps in terms of object, action, and parameters.

Uploaded by

veereshkumarg
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

Lightweight Automation Test Plan Template

Submitted by guy.arieli on Tue, 10/07/2008 - 01:15

Abstract

This post has been written in order to explain the lightweight template for functional tests
document that is the base for the automation process. Test architects can use this
template to better integrate with automation experts.

This template is not focused on generic test plan issues (like the document versions) on
automation specific issues.

Principles and terms

1. Definition of the SUT (System Under Test). The components that are part of the
system under test including the unique elements of the testing environment.
2. Separate test and test configuration (Fixture). Usually tests have 3 parts:
a. Configure the SUT to specific state (Fixture).
b. Create stimulation. Some type of action that changes the idle flow.
c. Analyze the system behavior.
3. In state-full environment the first part contains most of the test logic. Separating it
from the test itself is a huge advantage. It enables sharing of fixture between
tests. It makes the test focused and simple. It shortens the execution time and it
can support test failure recovery models.
4. Object, Action, Parameters.

Most of the tests plan templates contain table structure in order to describe the test flow.
The table usually includes columns like: step index, step name, step description and
expected results. The described structure is usually too open to be a good base for test
automation.

5. Matrix. The degrees of freedom that can be used in the test execution.
6. Parameters. Test/Step parameters.

Template

Test name:

[The name of the test]

Purpose:

[The purpose of the test in a few sentences]


Discussion:

[A paragraph describe the issue in stake]

Setup:

[Description of the setup to be used. The station that should be used and there
description. Usually a setup will be common to a group of tests. So a link to deferent
document that describes the setup can be used]

Fixture:

[Description of the Fixture that is the base for this test. The process of building the Fixture
as well as the process of tearing it down. Usually a fixture will be common to a group of
tests. So a link to different documents that describe the Fixture can be used]

Recovery:

[Description of the recovery mechanism in the case of test failure. For example: if the test
fails then run it again and only if the second test fail consider this test as failure. If it fails
to tear down the fixture to it root ...]

Matrix:

[The degrees of freedom the test can be executed. For example: this test should be
executed both using Internet Explorer and Firefox other option can be Chrome ...]

General Parameters:

[Parameters that should be exposed to the user (the person that will execute the test)].

Steps:

ID Object Action(method) Parameters


1 server.web addUser userName = 'Guy'
2 server.web addUser userName = 'Michael'
3 server.web showUsersCheckExist userName = 'Guy'
4 server.db checkExistInUserDb userName = 'Guy'
5 server.web removeUser userName = 'Michael'
6 server.db checkNotExistInUserDb userName = 'Michael'

Guy Arieli

AQUA Software

You might also like