Validated release of a health care product could be a challenge as its completely different from all the normal product releases that any firms do because I can say, there is just a feature verification for all normal software products and that’s just a feature check with normal unit testing and a QC verification without any actual proof and documentation for everything. Normal software verification ensures that the output of each phase of the software development process does what the corresponding input artifact specifies i.e Getting requirement => designing => development. But on the other hand when it comes to QA of a validated software product the game is completely different here. Validation is to ensure the business requirement is fulfilled through the product. Validation Ensures that the product completely matches and provides the best out of the intended use of stakeholders. For eg. The QC should thoroughly start the process from the login screen to every feature which includes minor things from the product such as dropdowns, number of items that should show in a drop-down to warning messages, all should have a test case, and a working proof of it before the validated release. This means if the application has thousand test cases then every test case has to be executed before the validated release with working proof and it is gonna get documented for the client which has a linkage with all the final documentation.
Here I’ll share with you the most indispensable documents needed for validation which has to be Signed by the product owner and leads.
Design Specification is a written description of a product, that a product designer writes in order to get overall guidance to the architecture of the project. This Document contains the purpose and scope of the product and its goal is to understand the detailed design of the system architecture. The architecture is divided into components and each component is further explained with working model sub-diagrams for better understanding.
This document also contains the Technology Inventory section, which lists all the major technologies leveraged in the system with their version and specifications. This also has the details regarding the security and backup or disaster recovery.
The requirement specification document contains the purpose, overview, functional requirements, and other requirements like the business rule, security requirements, etc. It also has to be electronically signed by the product owner and the Quality Lead. Mainly this has a requirement ID and a definition of how that should work as per requirement and every requirement will have an ID associated with it.
The purpose of this Test Plan (TP) is to define the overall testing approach, the required deliverables, and key decisions related to the testing approach and assumptions specific to the testing of the application.
This Test Plan will be evaluated at the beginning of each release/change control to determine if any updates are necessary. If no updates to the Test Plan are necessary, this will be noted in the Validation Summary Report (VSR).
Operational Qualification contains the latest executed test cases along with screenshots it should cover the entire modules of the application. It is the most essential process during the development of software products used by pharmaceutical companies. OQ can simply be defined as a series of tests that ensure that the entire software and its subsystems will operate within their specified limits consistently and dependably. The main contents of OQ are the test case ID, The test case description and the steps to perform it and after executing each test cases the actual result should be written according to the data using which we have performed the case and a screenshot of the actual data is required for proof. By any chance, if any defects occur then the case has to be further linked with a defect id and that defect id should be present in the defect tracker with defect description.
Installation Qualification where the installation steps of the software has to be mentioned which contains the hardware and software verification and the procedure or steps to install all the software with the required version number has to be done.
For example, if you are using Docker to install the software in production, it should contain the hardware requirements, the version of docker, and the process to install with configurations.
Requirement Traceability matrix
This Document mainly consists of two tables. One is the component-wise scope of operational qualification and its type. The other table is a Traceability Matrix containing the functional requirement description along with its requirement id from requirement specification and case id mapping from OQ and IQ specifying every requirement of the product from the requirement specification . RTM will provide a link between the requirement spec and test cases from the IQ and OQ. The main contents in this tablet are module, Requirement ID (From Requirement specification) functional requirement description, IQ test ID, Test Case ID Mapping.
Quality & Validation Plan
The purpose of this Quality & Validation Plan (QVP) is to define the overall validation approach, the required deliverables, key decisions related to the validation approach, and assumptions specific to the validation for the application.and It is designed and implemented per the validation process defined in this document, to provide a high degree of assurance that the system will consistently operate according to predefined requirements and specifications.
Validation Summary Reports
The purpose of this Validation Summary Document (VSR) is to summarize the overall results obtained during the execution of Installation/Operations Qualification (IQ/OQ) for the validation of the product. This summary report documents that the product performed in accordance with its intended use as indicated in the Requirements Specification (RS) and the Design Specification (DS). For more details please refer the below link.