SW Test Plan

SOFTWARE TEST PLAN

for the

[PROJECT NAME]

Contract No. [Contract Number]

CDRL Sequence No. [CDRL Number]

[Day Month Year]

Prepared for:

[Contracting Agency Name]

[Address]

Code:  [Department Code]

Prepared by:

DISTRIBUTION STATEMENT [Distribution Statement Letter]

[Distribution Statement]

SOFTWARE TEST PLAN

for the

[PROJECT NAME]

Approved by:

Task Leader		Date
Engineering Director/Associate Director		Date
Quality Assurance		Date
Technical Director		Date
Program Manager		Date
[Other]		Date

Record of Revisions

Rev	Result of	Pages Affected	Approval/Date
1	ECR xxxx	Initial Release	DD MMM YYYY

Table of Contents

Section  
                                                                                                                                  Page

1. SCOPE............................................................................................................................................

1.1 Identification......................................................................................................................

1.2 System overview................................................................................................................

1.3 Document overview..........................................................................................................

1.4 Relationship to other plans.............................................................................................

2. REFERENCED DOCUMENTS.................................................................................................

3. SOFTWARE TEST ENVIRONMENT......................................................................................

3.x [Name of test site(s)]..........................................................................................................

3.x.1 Software items.....................................................................................................

3.x.2 Hardware and firmware items..........................................................................

3.x.3 Other materials....................................................................................................

3.x.4 Proprietary nature, acquirer's rights, and licensing......................................

3.x.5 Installation, testing, and control.......................................................................

3.x.6 Participating organizations...............................................................................

3.x.7 Personnel..............................................................................................................

3.x.8 Orientation plan..................................................................................................

3.x.9 Tests to be performed.........................................................................................

4. TEST IDENTIFICATION...........................................................................................................

4.1 General information.........................................................................................................

4.1.1 Test levels.............................................................................................................

4.1.2 Test classes...........................................................................................................

4.1.3 General test conditions.......................................................................................

4.1.4 Test progression..................................................................................................

4.1.5 Data recording, reduction, and analysis..........................................................

4.2 Planned tests......................................................................................................................

4.2.x (Item(s) to be tested)...........................................................................................

4.2.x.y (Project-unique identifier of a test)...............................................................

5. TEST SCHEDULES.....................................................................................................................

6. REQUIREMENTS TRACEABILITY........................................................................................

7. NOTES...........................................................................................................................................

8. APPENDICES...............................................................................................................................

List of Figures

Figure                                                                                                                                        Page

List of Tables

Table                                                                                                                                         Page

Software Verification and Validation

Definitions

Also known as software quality control.

Validation checks that the product design satisfies or fits the intended usage (high-level checking) — i.e., you built the right product. This is done through dynamic testing and other forms of review.

According to the Capability Maturity Model (CMMI-SW v1.1),

Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].

Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]

In other words, validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that ‘you built the right thing’. Verification ensures that ‘you built it right’. Validation confirms that the product, as provided, will fulfill its intended use.

From testing perspective:

  Fault - wrong or missing function in the code.

  Failure - the manifestation of a fault during execution.

Malfunction - according to its specification the system does not meet its specified functionality.

Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar:

§  Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s).

§  Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.

§  Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer's conceptual description and specifications.

Software Quality Control is the set of procedures used by organizations to ensure that a software product will meet its quality goals at the best value to the customer, and to continually improve the organization’s ability to produce software products in the future.

Software quality control refers to specified functional requirements as well as non-functional requirements such as supportability, performance and usability. It also refers to the ability for software to perform well in unforeseeable scenarios and to keep a relatively low defect rate.

These specified procedures and outlined requirements leads to the idea of Verification and Validation and software testing.

It is distinct from software quality assurance which includes audits of the quality management system against a standard. Whereas software quality control is a control of products, software quality assurance is a control of processes.

The Capability Maturity Model (CMM) is a service mark registered with the U.S. Patent and Trademark Office by Carnegie Mellon University (CMU) and refers to a development model that was created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. This became the foundation from which CMU created the Software Engineering Institute (SEI). Like any model, it is an abstraction of an existing system.

When it is applied to an existing organization's software development processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. This gave rise to a more general concept that is applied to business processes and to developing people.


V-Model: