Software Test Description (STD)

Document Number: [nn]

Date: Day, Month Day, Year

[Project Name]

[Author 1]

[Author 2 – if none, leave blank line]

[Author 3 – if none, leave blank line]

[Author 4 – if none, leave blank line]

Professor [Name]

Software Engineering Department

Monmouth University

West Long Branch, NJ 07764-1898

Page 1 of10

Software Test Description (STD)

[Project Name]

Table of Contents

1Scope

1.1Identification

1.2System Overview

1.3Document Overview

2References

3Test Preparations

3.1Project Name Test Preparations

3.1.1Hardware Preparation

3.1.2Software Preparation

3.1.3Prerequisite Conditions

3.1.4Test Inputs

3.1.5Expected Test Results

3.1.6Criteria for Evaluating Results

3.1.7Test Procedure

3.1.8Assumptions and Constraints

4Test Descriptions

4.1Project Name Test Name

4.1.1Test Description

4.1.2Test Procedure Location

4.1.3Requirements Addressed

5Requirements Traceability

6Notes

7Test Procedures

7.1Test Procedure for [Project Name Test Name]

1

Software Test Description (STD)

[Project Name]

1Scope

1.1Identification

[This paragraph shall contain the manufacturer’s name, model number, and any other identifying information for the computer system to which this COM applies.]

[Example: This document will be identified as the [Project Name] Software Test Description (STD), Version 1, Release 0: [Project Name]-STD.]

1.2System Overview

[This paragraph shall briefly state the purpose of the computer system to which this STD applies.]

Include this sentence. [Refer to the [Project Name] Software Requirements Specification (SRS) for a more detailed description of the system.]

1.3Document Overview

[This paragraph shall summarize the purpose and contents of this manual and shall describe any security or privacy considerations associated with its use.]

[Example: This Software Test Description (STD) document describes the procedures to be followed during the testing phase of the [Project Name]Project. It is written in accordance with the [Project Name]-STP (Software Test Plan) and the [Project Name]-SRS (Software Requirements Specification).

This STD is organized as follows:

  1. Section 1 - Scope. Identifies and describes the system and software to which this document applies, and the objectives to be satisfied by the proposed system as outlined in this section.
  2. Section 2 - Referenced Documents. Provides a list of documents used in the preparation of this STD.
  3. Section 3 - Test Preparations. Specifies the hardware and software requirements. It also discusses test preparations, procedures, and expected results.
  4. Section 4 - Test Descriptions. This section provides general information about the test descriptions, procedures, and requirements as outlined in the SRS.
  5. Section 5 - Requirements Traceability. This section provides traceability from each requirement in the SRS to the test that validates the requirement.
  6. Section 6 - Notes. Provides a glossary of terms used in this document.
  7. Section 7 - Test Procedures. Provides test procedure templates for conducting the tests.]

  8. [1] / J. Smith and J. Smith, "Software Requirements Document," 2013.

3Test Preparations

3.1Project Name Test Preparations

[This paragraph shall describe the preparations necessary to ensure a valid test environment.]

[Example: The following subparagraphs identify the preparations necessary for all [Project Name] testing covered in this document.]

3.1.1Hardware Preparation

[This paragraph shall describe what environment is needed in order to test this application.]

[Example: Below are the minimum hardware requirements for the client (and/or server) software.

Client Hardware:

List all necessary hardware for this project.]

3.1.2Software Preparation

[This paragraph describes the software preparation necessary for the project to succeed.]

[Example: All testing must be made from a Single Image WorkStation (SIW) with the following software configuration and capabilities:

List all necessary software for this project.]

3.1.3Prerequisite Conditions

[This paragraph itemizes all of the conditions that must exist for the project to succeed.

[Example: All of the following prerequisite conditions must be met for the test procedures to be executed:

  1. All testing must be made by a user with the following capabilities:
  • List access and proficiencies needed. ]

3.1.4Test Inputs

[This paragraph describes how the test input was created. All automated processes implemented to create the test data must be identified.]

[Example: The test inputs are created from a batch process that creates a data base file. All input fields are listed in the test procedures.]

3.1.5Expected Test Results

[This paragraph lists expected test results. If the results are typical a standard statement may be inserted.]

[Example: The expected results are listed in each test procedure.]

3.1.6Criteria for Evaluating Results

[This paragraph describes the criteria that will be used to evaluate test results.]

[Example: The actual results obtained from each step of the test procedures must match the expected results for the step to pass. All of the test steps in the test procedure must pass for the test to be considered successful.]

3.1.7Test Procedure

[This paragraph describes the specific test procedures that the project will follow.]

[Example: Each of the test procedures is to be executed starting at step 1, and continuing to the next sequential step, until all the steps have been completed.

The steps in each test procedure indicate the actions to be executed by the tester. Some of the actions are enclosed in brackets [{} ] and provide descriptions of entries to be made, such as: [{Type in the URL location}], or describe keystrokes [{Press the enter key}], etc.

Each step of the test procedure has a column labeled ‘Expected Results’ which describes the expected results for each test step. After the test step has been executed, the actual results are to be compared to the expected results as follows:

  • If the results match, then the column labeled Pass/Fail is marked with Pass. (Note: An actual result for a particular step can be an error condition; as long as the expected results for that step describe the error condition the step is marked Pass.)
  • If the results do not match, the column labeled Pass/Fail is marked with Fail and the “Actual Results” column is to be filled in with the actual results.

Even if a step fails, the tester should attempt to continue to execute the rest of the steps in the procedure, for analysis purposes.]

3.1.8Assumptions and Constraints

[This paragraph describes that assumptions (maximum time for the system to respond) and the constraints (software or hardware constraints). ]

[Example: The tester should expect to receive a response from the [Project Name] system within a specified period of time, although this may be extended due to network traffic or communications failures outside of the control of the [Project Name] system.]

4Test Descriptions

4.1Project Name Test Name

4.1.1Test Description

This section describes the [Project Name Test Name].

[Example: The objective of this test is to verify that [enter what needs to be verified].

4.1.2Test Procedure Location

[This paragraph describes where the procedures are located in this document.]

[Example: This test procedure is listed in Section [X.x].]

4.1.3Requirements Addressed

[This paragraph describes the requirements addressed by this test.

[Example: This series of tests addresses [Project Name]-SRS requirement [Project Name]-01.]

[Repeat section 4 for each test description.]

5Requirements Traceability

[This paragraph describes how each requirement is traced to each test.

[Example: Each test description listed in Section 4 contains a “Requirements Addressed” subsection. The subsection identifies the Software Item requirement that is addressed in the software item’s Software Requirements Specification (SRS) and is in the form of: “This series of tests addresses [Project Name] SRS requirement [Project Name]-##, where ## is the requirement number”.]

6Notes

[This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document.]

7Test Procedures

[This section contains the test procedures for the following requirements:

1. [Project Name] Test Name[Project Name]-01.

2. [Project Name] Test Name [Project Name]-02.]

7.1Test Procedure for [Project Name Test Name]

[This is a sample test log.]

Step # / User Action / Expected Results / Actual Results / Pass/Fail
/ Connect to [Project Name] URL location. / The [Project Name] Login Screen is displayed.
/ Enter a valid login ID and password. / The [Project Name] Menu is displayed.
  1. .
/ Select “Display Schedule”. / Drop-down list box displays.
/ Select desired semester / Student’s schedule is displayed.
/ Select Print option / Student’s schedule is printed.
6. / Select “Home” to return to Student Menu. / System displays Student Menu.
7. / Select “Exit” to leave [Project Name]. / Exit [Project Name].
8. / Repeat steps 2 through 4, student is not registered. / Student receives an error message stating: Trying to find semester in course enrollment. Information is not available.

1