-
Notifications
You must be signed in to change notification settings - Fork 29
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a basic verification and validation plan
Most of this was taken from a document Reece gave me! Thank you! Issue #95
- Loading branch information
1 parent
1725db2
commit c6bdd96
Showing
1 changed file
with
72 additions
and
0 deletions.
There are no files selected for viewing
72 changes: 72 additions & 0 deletions
72
rdm/init_files/documents/verification_and_validation_plan.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
--- | ||
id: VVP-001 | ||
revision: 1 | ||
title: Verification and Validation Plan | ||
--- | ||
|
||
# Purpose | ||
|
||
This document describes the plan regarding how {{ device.name }} will be verified and validated. | ||
|
||
[[FDA-CPSSCMD:v-and-v]] | ||
|
||
# Definitions | ||
|
||
**Verification** means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. In other words, "Did we build the thing right?" | ||
|
||
**Validation** means establishing by objective evidence that device specifications conform with user needs and intended uses. In other words, "Did we build the right thing?" | ||
|
||
An **end-to-end test** examines the functionality of an software system through its standard user interface without peering into its internal structures or workings. | ||
|
||
A **unit test** examines an individual software unit that typically cannot be broken down any further. | ||
|
||
An **integration test** examines multiple software units for defects in the interfaces and interactions between them. | ||
|
||
An **automated test** is any test that can be run without human input. A **manual test** is any test that requires a human to perform some or all of the test steps. | ||
|
||
A **software item** is any identifiable part of a computer program. | ||
|
||
A **software system** is an integrated collection of software items organized to accomplish a specific function or set of functions. | ||
|
||
A **software unit** is a software item that is not subdivided into other software items. | ||
|
||
**Regression testing** is the process of re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. | ||
|
||
# Verification Activities | ||
|
||
Software verification begins with the code reviews and adherence to software standards defined in the Software Plan. The outputs of these activities are recorded in the Revision Level History. | ||
|
||
Software verification continues by running all automated tests on a continuous basis during the development process to detect any regressions. Automated tests are automatically run against each proposed software revision before the revision is accepted, a process known as Continuous Integration, or CI. Manual tests are run as needed during development and then for the Software Test Record for a release. | ||
|
||
Tests are written, modified, and reviewed during the Unit Implementation and Testing activity and are reviewed for completeness as part of the Release activity. Both activities are described in the Software Plan. | ||
|
||
A detailed list of verification tests, the testing environment, and their results are found in the Software Test Record. The Software Test Record is created as part of the Integration and System Testing activity described in the Software Plan. | ||
|
||
The types of tests used to verify {{ device.name }} are described below: | ||
|
||
## Unit Tests | ||
|
||
TODO: Describe how and when unit test shall be written | ||
|
||
## Integration Tests | ||
|
||
TODO: Describe how and when integration tests shall be written | ||
|
||
## Automated End-to-End Tests | ||
|
||
TODO: Describe how and when automated end-to-end tests shall be written | ||
|
||
## Manual End-to-End Tests | ||
|
||
TODO: Describe how and when manual end-to-end tests shall be written | ||
|
||
# Validation Activities | ||
|
||
System-level validation of {{ device.name }} is covered by human factors and clinical testing. Thus, it will not be covered in | ||
this software-specific documentation. | ||
|
||
TODO: Reference the appropriate documents | ||
|
||
# Pass / Fail Criteria | ||
|
||
TODO: Describe the pass / fail criteria that will be used here. |