Software validation is often considered to be overwhelming for some organizations. With all the requirements and guidance specified in the standards and regulations, it appears to be a monumental task. However, it is not as complex as some may think. This tangled web can be simplified so that it is more easily understood and not just meet regulatory requirements but serve as a useful business tool as well.
While very few software systems are developed in house anymore, many of the systems used are configurable to meet your business needs. The regulations state, that these configured systems must be validated for their intended use. Depending on the risk and complexity of the software, different levels of validation rigor should be performed.
Step 1: Create the Validation Plan
The first step in the validation process is to create a validation plan (VP) that identifies who, what, and where. The plan usually consists of a description of the system, environment specifications, assumptions, limitations, testing criteria, acceptance criteria, identification of the validation team including the responsibilities of each individual, required procedures, and required documentation.
Step 2: Define System Requirements
The next step is defining the system requirements (SRS) defining what you expect the system to do. These can be broken down into two categories – infrastructure requirements and functional requirements. Infrastructure requirements include the identification of personnel resources needed and the facility and equipment needed for the task. Functional requirements include things such as the performance requirements, security requirements, system and user interfaces, and the operating environment needed. A system risk analysis is also necessary. This analysis evaluates the functional requirements and identifies any gaps. The gaps are then analyzed to determine and mitigate any risks.
In the real world, companies often purchase systems using business requirements which may be different than functional requirements. So while it’s a good idea to define all your requirements (business and functional) it’s not uncommon for validation to be performed on a system after purchase and during installation. Regardless, once you have your functional requirements defined and the system installed in a test/validation environment, the next phase is to verify requirements with testing.
Step 3: Create the Validation Protocol & Test Specifications
The testing phase begins with the development of a test plan (VP-Validation Protocol) and test cases (Test Specifications). The test plan describes the objectives, scope, approach, risks, resources, and schedule of the software test. It documents the strategy that will be used to verify and ensure that a product or system meets its requirements.
The test cases identify inputs, actions, or events and expected responses to determine if a feature of an application is performing as necessary. Since it is impossible to test every possible input-output combination, and companies strive to minimize the costs associated with testing, the goal is to identify as many defects as possible with as little testing as possible. Therefore, test cases must be written so that they have a high likelihood of uncovering as many errors as possible with as few test cases as necessary. A requirements traceability matrix should also be developed during this phase to trace the requirements to their test case and throughout the remaining steps of the software validation activities.
Step 4: Testing
The actual testing is then ready to be initiated. Black box testing (testing that ignores the internal code of the system or component and focuses on the inputs and outputs of the software) is used for validation of commercial off the shelf systems since you don’t own the code. Tests are executed based on the test plan and test cases. Any errors, defects, deviations, and failures are identified and recorded, and are dispositioned in a final report.
Step 5: Develop/Revise Procedures & Final Report
Once testing is completed, procedures for system use and administration must be developed/revised. Then, prior to the system being released for use, a final validation report is produced, reviewed, and approved. The Final Report or Validation Report (VR) typically serves as a validation wrap up. Approval of this report is the final release for a system to go into production. The report should include elements such as the where system support can be found, user training, how the system security will be addressed, and backup and recovery plans. The Final Report may also include the test report which discusses the success of testing and dispositions any anomalies which may have occurred during testing.
In summary, there is no secret code for validating your software. When it is broken down into simple, practical steps, validation can be performed fairly easily. And in the end, not only will you comply with the regulations, but your productivity will increase because your systems have been validated and are working properly.
