V&V Plan & Results Outline

The Verification and Validation Plan (V&V Plan or VVP) and Results (VVR) sections given in this outline are guidelines to the contents of your V&V Plan and Results. Include at least these sections. Your team may have good reasons for wanting to deviate from this proposed outline. In this case, you should motivate any deviations to me. If a section is not applicable in your case, do not delete it; instead, give the topic heading and write "Not applicable".

V&V Plan Recommended Content

The following outline is a reasonable organization for the Verification and Validation Plan and Results.

If you have to make choices about how you spend your time developing this document, you should
abbreviate section 2 (don't eliminate it!) and make section 3 complete and extensive.  This does not
mean that you should not put an emphasis on component testing.  Component testing is a vital part
of software development.  It just means that if you run out of time developing this document,
you may abbreviate section 2.

1.  Introduction and Overview

    1.1  Purpose of this Document
           Description of the main objectives of the V&V Plan & Results.

    1.2  Scope of the Development Project
           This summarizes the project and product in order to resituate the reader in your project's goals
           and objectives.

    1.3  Definitions, Acronyms, and Abbreviations
           Provide only the ones that are going to be helpful in understanding this document.

    1.4  References
           At a minimum, the SRS and SDS documents should be in the reference list.  Use proper and
           complete reference notation.

    1.5  Overview of Document
           A short description of how the rest of the V&V Plan & Results is organized and what can be
           found in the rest of the document.  This is *not* simply a table of contents.  Motivate and
           briefly describe the various parts.

Note:  Sections 2, 3 and 4 are the heart of the V&V Plan, that describe
what needs to be tested and how it will be tested.

2.  Component test plans and procedures (for individual software components)

    For each component in the SDS, give the following:
    2.1 .. 2.X Component Test Case Description

    Use test case groups, in which a number (1 or more) of logically associated test cases are grouped
    together. Each test case group for each component should be described in a separately numbered
    subsection (e.g. 2.1.1, 2.1.2, 2.1.3, 2.1.4). Such a numbering system will greatly ease the task of
    referring to the various tests.

    For each test case group, give the following information:

3.  Functional and System Test Plans and Procedures (for the software product as a whole)

    3.1 Traceability from SRS to SDS
          Include a summary of all functional and other requirements of the system.

    3.2  Functional and System Test Strategy Overview
           Include a description of the overall integration approach: Bottom-up, Top-down, Big-bang,
           Sandwich, hybrid.

    3.3 .. 3.X  System Test Case Descriptions
           No longer associated with SDS components, but system, functional and other requirements.
           Break into logical test case groups as in sections 2.1 .. 2.X, with each test case group its own
           numbered subsection (eg., 3.2.1, 3.2.2, ...)

4.  Acceptance test and preparation for delivery

    4.1  Procedure by which the software product will be acceptance tested

    4.2  Specific acceptance criteria

    4.3  Scenario by which the software product will be installed

Note:  Section 5 is the V&V Results, that describe what
was tested and the outcome of the results.

5.  V&V Results

    5.1 Summary of Results
          Assess the overall success of the V&V activities.  Be specific about types of problems that
          were encountered and how they were resolved.  This section is an "executive summary".
          Ensure that you really discuss what has happened thus far in the V&V process.  You may
          also summarize the work that remains (if any).

    5.2 Summary of Incidents and Solutions
          An incident occurs each time the actual output of a test case does not match the expected
          output.  In this section, summarize the incidents, the date on which they were discovered,
          and their resolution.

    5.3 Results from Testing

        5.3.1 Summary from Component Testing
                 Use a logical format (such as a table or list) to discuss the outcome of the component
                 testing.  This section should describe the component, the test case identifier, where and
                 when the testing was done, who was responsible for each test, how long it took, what
                 went poorly with each test, the problems revealed, and any work that could not be
                 completed.  If a component required rework after a test, there should be another entry
                 in the table/list for the retest of the component after problems were fixed.

        5.3.2 Summary from System Testing
                 The content of this section should cover the same issues as described in section 5.3.1.

    5.4 Outcome of Acceptance Test and Delivery
          This section should be directly related to what your team wrote about the acceptance
          test in section 4.  Explain what acceptance test you actually conducted, what worked
          as planned, and what you were unable to execute as described in section 4.

    5.5 Evaluation of the Process

        5.5.1 Evaluation of Test Cases
                 Based on the experiences your team had in using these test cases, what should have been
                 done differently?  What worked well?  Are their test cases you should have included but
                 did not?  What did you add as the process went on?  Which test cases turned out to be
                 somewhat unnecessary?

        5.5.2 Unresolved Incidents (known problems)
                 Document any known problems with the project at time of project completion.  Hopefully,
                 this section will consist of the words "No known unresolved incidents at this time".

Primary References used in preparing this outline:

Vicki Almstrum's CS373 V&V Plan, V&V Results Outlines, UT Austin, Spring 2002

http://www.cs.utexas.edu/users/almstrum/cs373/current/doc-stds/VVP-outline.html http://www.cs.utexas.edu/users/almstrum/cs373/current/doc-stds/VVR-info.html

Last modified: Wed March 27 2002