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
1.3 Definitions, Acronyms, and Abbreviations
Provide only the ones that are going to be helpful in understanding this document.
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.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,
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
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
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
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
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
5.5.2 Unresolved Incidents
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".
Vicki Almstrum's CS373 V&V Plan, V&V Results Outlines, UT Austin, Spring 2002
Last modified: Wed March 27 2002