People often ask why they need to have a Validation Plan if they already have a Test plan or vice versa…. Formal testing can be a complex and detailed activity and it does need a Test Plan of its own. There are, however, two other workflows to an auditable validation package and they need direction from an approved Plan as well. Thus there is a need for an overall package plan. (65)
As an auditor of regulated systems I have often seen confusion about the content and context for “Validation Plan” and “Test Plan” and frequently there will be only one document and not the two. The Test Plan is a management approved document written to describe the scope, resources, and approach to be taken for testing a computerized system. It will reference a Trace Matrix back to requirements and define a test case strategy for full coverage of approved requirements.
The Validation Plan has a broader context and is a management approved document that is written to describe all quality activities planned for assuring proper operation of a computerized system prior to its Go-Live and production use. A Validation Plan is like a project plan for the whole validation effort. It includes activities for the physical and logical management of the software application and associated platform infrastructure and user/work interface activities from requirements to SOPs and Work Instructions. Finally when the first two pieces are in place, it includes the Test Plan and its work.
In an auditable package, no Plan is finished until there is a Summary Report to describe the outcome of planned activities. The Test Plan has a Test Summary Report to discuss the test configuration, all testing results, problems found and their resolution, identification of individuals involved in testing roles, and a Trace Matrix to show coverage of requirements by specific tests. Testing documents without an approved Test Plan and an approved Test Summary Report are just a pile of paper and not worth any audit credit.
The Validation Plan has a Validation Summary Report that describes the individuals/roles responsible and final status of all the validation project tasks listed in the Plan. Any deviations from the Plan either as additions or deletions are also documented in the Report. The report is also expected to make a final Go-Live recommendation to the system sponsor based on the report findings. A validation effort that only has a testing focus with no Validation Plan and Validation Summary Report to cover the broader context misses two thirds of the audit credit. System installation, configuration management, disaster recovery, service level agreements, approved requirements, SOPs, WIs, user training, ongoing validation support, and controlled change – all are important to establish and maintain a validated system state and all are tasks under the Validation Plan.
Next Month: Historical Perspective on Computer Validation – FDA’s 1983 Blue Book
The questions that the Blue Book tells investigators to ask about computer hardware and software systems continue to be valid and are asked by inspectors and auditors today for systems operating in regulated environments. (3)