How to Conduct Your Own Software Validation

Your software validation needs to be conducted within the context of your overall quality system. The procedures you have in place to govern software testing, network security, document control, and other quality assurance activities will guide your software validation process. This article is intended to provide information for planning the actual software validation procedure, and does not address other related processes which are also necessary for validation. Your validation plan should work in harmony with your system as a whole.

Your software validation begins with the creation of a Software Validation Plan. This plan will outline the schedule of activities that you will carry out during your validation, and provide you with an easy way of tracking the completion of each step. It will specify the required documentation, and identify responsible individuals.

Minimum requirements for your Software Validation Plan

1. Scope: The plan should describe the scope of the validation (what specifically will be tested).
2. Limitations: The plan should describe any limitations of the validation.
3. Risks: The plan should describe the risk level, or level of concern, of the software, according to FDA guidelines or other applicable regulations.
4. Responsibility: The plan should designate the person responsible for conducting each activity.
5. Timeline: The plan should include a timeline of scheduled activities.
6. Defect Handling: The plan should describe the method of recording and tracking bugs and issues.
7. Change Control: The plan should describe the change control process used for the software.
8. Test Types: The plan should describe the types of testing included, such as unit testing, functional system testing, and regression testing. It should also describe what is being tested, such as requirements testing, or testing under normal use.
9. Test Methods: The plan should describe the testing methods, whether they are manual or automated, and the method of recording results.
10. Test Environments: The plan should list the environments the product will be tested in. These should reflect the typical user environments.
11. Acceptance Criteria: The plan should describe the criteria to be met before the product will be approved. It should describe the handling of any outstanding issues.
12. Test Documentation Requirements: The plan should include a description of the test result documentation required.
13. Review Requirements: The plan should describe the review requirements, including when each review will occur, and who will participate in the review. It should also outline what will be covered in each review.
14. Required Approvals: The plan should specify the approval signatures needed to complete the validation.
15. Checklist: The plan should include a master checklist to be filled out during the validation. The checklist should include each step to be completed and list all documents that will be generated during the validation. The due date should be listed next to each item, and the name of the person responsibe. Space should be provided to fill in the actual completion date for each item.

Once you have completed your validation plan, you will use the checklist to guide you through the rest of the process. At a minimum, you will need the following documentation for your validation:

• Software Requirements Specification
• Software Design Specification
• Software Test Specification (also called Installation and Operation Qualification)
• Software Test Results
• Requirements Traceability Matrix
• Software Validation Report

The Software Validation Report should reflect the Software Validation Plan. It should cover the same items, describing how each one was completed. In addition, the Software Validation Report should include:

All of these documents should be processed through your document control system and retained for the amount of time required by your company or governing body.