Test Procedure

Definition

A test procedure (TP) is a testing work product that documents how to manually execute a test suite of test cases.

Objectives

The typical objectives of the test procedures are to:

• Enable testers to manually execute test suites of test cases.

Benefits

The typical benefits of a test procedures include:

• It enables the testers to rerun manual tests that they did not create.

Contents

The typical contents of a test procedure include:

• Overview (test suite and list of test cases)
• For each test case:
  • How to set up the test preconditions (e.g., how to place objects, software components, and databases) into their correct pretest states)
  • How to perform the test steps (e.g., how to stimulate the item under test by sending it test messages or raising test exceptions to it)
  • How to determine and document the actual test postconditions (e.g., the return values, the exceptions thrown or handled, the messages sent, the post-test states of the object or component under test, the post-test state of the databases)
  • How to compare the actual and expected results from the test.
  • How to report the results of the associated test.
• Appendices:
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of a usability test screening questionnaire include:

• Producers:
  • The Software Development Team for unit tests and low-level software integration tests.
  • The Integration Team for high-level software integration tests and system integration tests.
  • The Independent Test Team for most system and launch tests.
  • The Security Team for security test.
  • The User Experience Team for usability tests:
• Evaluators:
  • The Test Inspection Team on a spot-check basis.
• Approvers for system and launch test procedures:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • The Software Development Team for unit tests and low-level software integration tests.
  • The Integration Team for high-level software integration tests and system integration tests.
  • The Independent Test Team for most system and launch tests.
  • The Security Team for security test.
  • The User Experience Team for usability tests:
• Users:
  • The Software Development Team uses test procedures to support unit and software integration testing.
  • The Independent Test Team uses test procedures to support manual system and launch testing.
  • The Security Team uses test procedures to support security testing.
  • The User Experience Team uses test procedures to support usability testing.

Phases

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Started
• Construction: Completed
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

A test procedure typically can be started if the following preconditions hold:

• The corresponding test suite of test cases has been identified.

Inputs

The typical inputs to a test procedure include:

• Work Products:
  • Project Test Plan
  • System Requirements Specification
• Stakeholders:
  • Tester

Guidelines

• Each test procedure is a living document that is developed incrementally and iteratively in parallel with other work products.
• Not every test suite requires a test procedure. Only develop test procedure documents for tests that require manual steps to execute.
• Do not develop test procedures for model testing.
• Because unit tests and most functional tests should be automated to support regression testing, few test procedures will be necessary for such tests.
• If the associated test suites and test cases are documented, the test procedure can reference these documents rather than redundantly repeat them. In this case, the test procedure only documents the manual steps.

Conventions

A test procedure is typically constrained by the following conventions:

• Content and Format Standard
• Template
• Inspection Checklist

Examples

• Example Test Procedure<</SPAN>