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: 1. Configure the SUT to specific state (Fixture). 2. Create stimulation. Some type of action that changes the idle flow. 3. 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:
My website : http://testingking.weebly.com

[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 1 2 3 4 5 6 Object server.web server.web server.web server.db server.web server.db Action(method) addUser addUser showUsersCheckExist checkExistInUserDb removeUser checkNotExistInUserDb Parameters userName = 'Guy' userName = 'Michael' userName = 'Guy' userName = 'Guy' userName = 'Michael' userName = 'Michael'

My website : http://testingking.weebly.com

My website : http://testingking.weebly.com