From: Verification and Validation Plan

Draft

Applications Unit Test Plan

1 Introduction

Unit tests verify that the software subsystems and components work correctly in isolation, and as specified in the detailed design. THe most common tests performed during unit testing are:

  • White-box Tests
  • Black-box Tests
  • Performance Tests

1 Test Plan

1.1 Introduction

This document describes the Validation tests and procedures used, and the reports generated in order to ensure that individual components interact according to specification.

1.2 Test items

  • List the items to be tested.

1.3 Features to be tested

  • Identify the features to be tested.

1.4 Approach

  • Specify major activities, methods and tools to be used to test designated groups of features.

1.5 Item pass/fail criteria

  • Define the criteria for pass or failing a test case

1.6 Suspension Criteria and Resumption Requirements

  • Specify criteria used to suspend all or part of testing activities.
  • Specify testing activities tht must be repeated when testing is resumed.

1.7 Test deliverables

  • List the items that must be delivered before testing starts.
  • List the items that must be delivered when testing ends.

1.8 Testing tasks

  • Describe the tasks needed to prepare for and carry out the tests.

1.9 Environmental needs

  • Describe the test environment setup.

1.10 Responsibilities

  • Identify groups responsible for managing, designing, preparing, executing, witnessing, and checking tests.

1.11 Schedule

  • Identify test milestones in software project software schedule and all item delivery events.

1.12 Risks and Contingencies

  • Identify high risk assumptions of the test plans and contingency plans for each.

1.13 Approvals

  • Identify names and titles of all persons who must approve the plan.

2. Test Designs ( for each test design...)

This section describes the general scenario of a test. I.e. the test might describe the overall scheme for black box testing of a single module; or it might describe the scheme for black box and white box testing; or the scenario for regression testing. The test will be realized in the following section on "Test Case Specification".

2.n.1 <Test Design identifier> (actual id)

  • Describe the test design

2.n.2 Features to be tested

  • Identify test items and describe features and combinations of features to be tested.

2.n.3 Approach Refinements

  • Describe package assembly sequence
  • Describe paths through package logic
  • Describe types of tests (white-box, black-box, regression testing, etc)
  • Provide method of analyzing tests results
  • Identify test support tools required.

2.n.4 Test Case Identification

  • List and describe the test cases associated with the test design.

2.n.5 Feature Pass/Fail Criteria

  • Specify criteria to be used to decide if feature passed or failed.

3 Test Case Specifications (for each test case...)

3.n.1 <Test case identifier> (actual identifier )

  • Describe the test case

3.n.2 Test items

  • List the items (i.e. packages) to be tested.

3.n.3 Input specifications

  • Describe the input for the test case.

3.n.4 Output specifications

  • Describe the output required from the test case.

3.n.5 Environmental needs

  • Describe the test environment.
    • hardware
    • software
    • wetware

4 Test Procedures (for each test procedure...)

4.n.1 <Test procedure identifier> (actual identifier)

  • Reference the related test design.

4.n.2 Purpose

  • Describe the purpose of the procedure.
  • List the test cases this procedure executes.

4.n.3 Special Requirements

  • Identify any special requirements for the test execution

4.n.4 Procedure steps

4.n.4.1 Log

  • Describe special methods or format for logging test execution results, incidents observed, and other pertinent events.

4.n.4.2 Set Up

  • Describe sequence of actions to prepare for execution of procedure.

4.n.4.3 Start

  • Describe actions necessary to begin execution of procedure.

4.n.4.4 Proceed

  • Describe actions necessary during the execution of the procedure.

4.n.4.5 Measure

  • Describe how the test measurements are made.

4.n.4.6 Shut down

  • Describe actions necessary to suspend testing when interrupt is forced by unscheduled events.

4.n.4.7 Restart

  • Identify any procedural restart points and describe actions necessary to restart the procedure at each of these points.

4.n.4.8 Stop

  • Describe actions necessary to bring the execution to an orderly halt.

4.n.4.9 Wrap-up

  • Describe the actions to terminate testing.

4.n.4.10 Contingencies

  • Describe actions to deal with anomalous events that may occur during execution.

5 Template Test Reports (for each execution of a test procedure)

Unit testing execution will be an automated step in the Build process. The results of the unit testing step will be reported to the Build process initiator (and possibly to the Applications SQA representative). Subsequently, the following information needs to be included in the Test Wrap-up Report. An appropriate form based on the contents of this section should be fabricated and included in Appendix A.

5.1 <Test report identifier> (actual identifier)

  • Describe report

5.2 Description

  • List the items being tested.

5.3 Activity and event entries

5.3.1 Execution Description

  • Identify the test procedure.

5.3.2 Procedure Results

  • Record visually observable results (error messages, aborts, )
  • Record location of output and result of test, i.e. refer to the archive directory (DMS/release/<relPackage>/<unitTests>) maintained according to the CM Plan.

5.3.3 Environmental Information

  • Record an environmental conditions specific for entry, particularly deviations from the normal.

ALTERNATE: Template Test Plan (IEEE 829 format)

  • Test Plan Identifier (based on LSST Configuration Management Naming Standard) * References (e.g.)
    • Development and Test Process Policies and Standards
    • Design Documents
    • System Requirements specifications
    • Project plan
  • Introduction
  • Items to be Tested
  • Software Risk Issues (e.g.)
    • new functionality
    • significant API change
    • etc
  • Features to be tested
  • Features not to be tested
  • Testing Strategy
    • top-down, bootom-up, functional groupings, etc
  • Item Pass/Fail Criteria
  • Entry & Exit Criteria
  • Suspension Criteria & Resumption Requirements
  • Test Deliverables
  • Environmental Needs
    • hardware and software requirements
  • Responsibilities
    • test plan author
    • test jockey
    • approval judge
  • Planning Risks and Contingencies
  • Glossary