Introduction to 3Qs of Software IQ-OQ-PQ:
IQ, OQ, and PQ constitute the 3Q’s of the Software Validation Process.
As testers, we all know that the Software Development Team develops the software in-house as per the Software Requirements Specification (SRS) and Functional Specification, and later the Testing Team verifies the implementation at different levels of testing in various testing environments, from the simplest to the high end, which thereby replicates the production environment.
Table of Contents:
3Qs of Software
With this approach of SDLC, the Software Development Team generally washes off their hands by handing over the completed software (developed and verified) to the Operations Team.
Further, it is the Operations Team (generally referred to as Ops Team) that takes care of deploying it to a production environment and make it ready to be used by the end-users.
Now, here lies the real challenge for the Operations Team to make the software function in the production environment, because, during the software development phases, development and verification has been done in a simulated environment, and quite rarely close to the live environment, only in case of availability of data and configurations of the production environment.
This is where the validation of the software comes into the picture. Once the verification is completed and the software is signed off by the Program/Product team, the Ops Team will carry out a set of activities before accepting the software to be deployed to production to prove that the software is behaving as expected, which is nothing but validation activities.
Verification vs Validation
Here, let’s clearly understand the difference between the “Verification” and “Validation” activities. Verification is to evaluate the software with respect to the given set of requirements and specifications which is done in-house at the Software Development site by the Developers and Testers.
Whereas “Validation” is a set of quality assurance checks which are carried out by the external customers, owners, and vendors on the product being delivered to them, to check the suitability before accepting or purchasing the product. Validation activities are mostly carried out at the production site.
Hence, in the case of Application Development, it is the Ops Team that is carrying out the Validation activities for the software.
Also read:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Phase of Validation Process
Generally, the Validation Process of any product refers to the complete life cycle of a product from development through use and maintenance. Hence, the validation process is broken down into 5 Phases.
The 5 Phases of the Validation Process are:
This 5 phase approach to the Validation process is being followed in many Industries like Manufacturing, Medical, Pharmaceuticals, etc. Here validation will be done by the end customer before buying the machinery, equipment, or product.
The constituents of the Validation activities for software is to prove that the software is ready for consumption by the users’, and to mainly verify the successful installation of the software followed by the functionality and operability.
3Q’s Approach: IQ-OQ-PQ
However, in the software context, the 3Q’s approach, IQ-OQ-PQ is being followed as part of Validation and it will be carried out by the Operations team, who are ultimately responsible for deploying the software to production.
Given below is the Validation Process Flow Diagram:
The template, plan, and any other documents which are input to carry out the 3Qs, will be laid out by the Software Team for their software and it includes the detailed approach, tasks/activities/tests to be conducted as a part of these qualifications along with the test results.
Summary reports will be handed over to the Ops Team during the software handover along with the binaries and other deliverables.
At a high level,
Overall, the purpose of carrying out IQ, OQ, and PQ is to ensure that the software can be successfully deployed and all the functionalities can be used without any bottlenecks.
Ideally, IQ, OQ, and PQ are sequential activities, which need to be executed in order. Unless the installation is done, the functionality of the software cannot be verified and unless the functionality is proven, there is no point in measuring the performance. Sometimes due to time constraints, PQ can start in parallel to OQ, once the key aspects of OQ are established.
Now, let us understand more about each of these 3 phases in detail.
Installation Qualification (IQ)
Installation qualification is also referred to as “IQ”, is the process of validating if the supplied software (binaries, scripts, etc.,) can be successfully installed in the specified environment with the specified configurations, and verifying how these installation steps are recorded in the document called “Installation Guide”.
The following items are supplied by the Development Team along with the delivered software package and are used by the Ops Team to carry out IQ.
1) An “Installation Guide” document which documents the installation steps in the selected environments.
2) A “Configuration Guide” document to set up the configuration of the software. Sometimes this document becomes a part of the Installation guide document itself.
3) Software package and Installation scripts, preferably automated scripts.
The software Installation Qualification phase is considered to be the most crucial one and typically many issues open up during this phase.
Because:
a) The development environment will not have a 100% real-time environment available to verify the installation issues and hence a difference in the environment that contributes to several issues.
b) Due to various reasons, there may not be enough collaboration and coordination between the Development and the Operations Team during the initial stages of software development to handle the issues well ahead.
c) There could be some documenting issues while recording the actual installation steps in the document, which may not exactly match the production environment.
These days, the entire software installation procedure will be automated as much as possible via a series of scripts. If there are any issues with the installation, then the automated installation fails due to any mismatch in the configurations, and manual intervention to fix those issues is required.
As the Ops team carries out the IQ by strictly following the instructions provided by the Software Team in the Installation guide, it is very important and also the responsibility of the Software Team to ensure that the “Installation Guide” is written in such a way that the installation steps match to the real-time environment.
It is the Tester’s responsibility to ensure that the ‘Installation’ process is verified in-house along with document verification for its completeness and to identify any mismatches with the actual steps to be run in the system against the documented steps in the Installation guide.
The following points need to be kept in mind while writing an Installation Guide and verifying them in-house, in order to minimize the issues during software installation at production.
| SNO | Installation Guide Points |
|---|---|
| 1 | Main and utmost, the ‘Installation Guide’ should be written in a simple and easy to follow language. |
| 2 | Need to ensure that it does not run into long, more than 5 pages. It should be short and neat. |
| 3 | Need to provide the serial numbers for each step of execution in order to track its status. |
| 4 | Automate the steps as much as possible and bundle all of them into a single script. |
| 5 | A standard template should be used to write installation procedure. |
| 6 | Pre-requisites should be clearly mentioned to avoid the miss-match and the steps to verify them needs to be provided. If there is a miss-match, instruction to bring them up to the expected level or to install those packages should be provided. |
| 7 | The typical time taken to install the software should be mentioned in the Installation Guide for the Ops Team to have idea on the approximate timing of installation to plan their activities accordingly. |
| 8 | The services that needs to be brought down during installation, how to bring down, impact of bringing them down needs to be clearly mentioned in the guide. |
| 9 | Providing links to other documents should be avoided and switching from one document to other. Every piece of information needed should be made available in the same document. If additional documents needs to be referred, supply them along with the software package, and in turn they need to be referred in the main documents. |
| 10 | Need to ensure that the name of the script mentioned in the document is same as the one which is packaged along with the binary. |
| 11 | Should ensure that all the scripts referred in the installation Guide document are supplied along with the binary. |
| 12 | Ensure that all the configuration parameters are clearly mentioned in the Installation Guide/Configuration Guide along with the default values and other supported values. |
| 13 | Automated tests to carry out the build verification tests after the software installation is completed should be supplied. They need to be minimum in number and important ones to verify that build is successfully installed. |
| 14 | ‘Smoke Tests’ needs to be supplied to ensure that end to end connectivity of the system is perfect and all the components of the system are talking to each other as expected. |
| 15 | In case of failure of software installation, rollback scripts are supplied along with the package and rollback procedure is clearly written out in the Installation Guide to carry out rollback and restore the system successfully. |
With all the above points to be taken care of, it is best practice to automate the software installation process with minimum human intervention in order to avoid human errors.
If any issues are found during the IQ validation phase, then they will be reported to the Software Team, upon fixing which, the smoke testing and build verification tests will be carried out to check the success of the software installation.
Hence the IQ phase includes installing the software package followed by conducting the build verification and smoke tests.
So, successful completion of the IQ phase is very important as a successful and proper installation of software ensures that most of the issues related to functionality failures are negated.
Operational Qualification (OQ)
Operational qualification, also called OQ, is the next activity of the software validation process after the successful completion of IQ.
Operational qualification activity includes tests to be run in order to verify that the software is operationally fit to be deployed to the consumers. Ideally, the key functionalities of the software are verified as part of this validation process.
An OQ Plan for carrying out the OQ Validation needs to be prepared by the Software Team (Testers) which should cover all the aspects of OQ testing that need to be carried out, including the details like no. of tests, test schedules, methodology, tools, impact on the service, test execution sequence, method of reporting issues and the SLA’s for fixing them, Defect Triage approach, etc.,
The Operational Qualification Tests which are run as part of OQ, are again supplied by the Software Team along with the software deliverables. These Operational Qualification tests are a collection of important tests which are designed based on the “Functional Requirements Specification” document to ensure that the entire software system functions as per the expectation.
This OQ Test Specification Document is prepared by the Test Engineers against the Functional Requirements Specification document. Often this document will be a subset of the System Test Specification document prepared and verified during the system testing phase of the SDLC.
Tests may be altered or updated to suit the Operational Team’s requirements and the conditions of the site where they will be executed.
Hence additional care should be taken while selecting the tests which are a part of the OQ to ensure that all the key functionalities and the main business workflows are included as a part of this verification.
The following are the tips for Testers while preparing the OQ test specification document.
| Sno | Tips for Testers while preparing the OQ Test Specification Document |
|---|---|
| 1 | Ensure that key functionality tests to prove that software functions as expected are chosen and included and hence the necessary traceability for each of the written test cases are available in the OQ Test Spec document. |
| 2 | Ensure that the tests are neatly written with step by step actions, are self-explanatory and able to be understood by a common man. |
| 3 | Do not refer or avoid usage of any technical terms in the test cases as much as possible, since the user of this document may not know about those terminologies.e that the test data used does not already exists on the system. Provide multiple sets of data, in case if user wants to execute the test cases more than once. |
| 4 | Clearly mention the mandatory and optional pre-requisites for each of the tests. |
| 5 | Include majority of the positive test cases to verify the functionality. |
| 6 | Include very few negative test cases to ensure that software behavior is as expected in case of irrelevant input and the system is able to handle the negative cases successfully. |
| 7 | Test cases related to boundary value need not have to be included, which verifies for extreme values, but use the most common day to day used values as inputs, wherever required. |
| 8 | Mention the configuration values to be set, if needs to be changed from the default values. |
| 9 | Supply the automated test cases to be run, wherever available. Ensure before in hand that those automation scripts can be run on the system where the OQ is being planned. |
| 10 | Ensure that each test cases have the clear ‘Expected’ and ‘Actual’ results as a reference. And add any comments if necessary to explain the actual result. |
| 11 | It is also necessary to include the ‘Acceptance criteria’ for each of the test cases. The Acceptance criteria could be the status of the system after the execution of the test cases. |
| 12 | Supply the ‘Test Data’ to be used for each of the tests accurately. Try to supply most common data from the live. And also few exceptional data, to ensure that system can handle the exceptional cases as well. Ensure that the test data used does not already exists on the system. Provide multiple sets of data, in case if user wants to execute the test cases more than once. |
| 13 | If multiple Operational users are running the tests from different locations in parallel, provide the instruction to carry out testing accordingly with different set of data. |
| 14 | Provide checklists where ever required to ensure that all the configurations, pre-requisites are set as expected before running the tests. |
| 15 | Keep monitoring the logs, when the tests are running, if access is available to the system. |
| 16 | If possible and required provide an execution support to the Operational users during execution of these test cases. |
| 17 | Explain the method of reporting the issues, found during execution. It is better to use the bug tracking tool to track the issues. Monitor each issue carefully and take it to closure as per the agreed SLA’s. |
| 18 | Run ‘Defect Triages’ involving right stake holders to understand the critical and severe issues and provide updates on those issues frequently. |
| 19 | Provide the final ‘OQ Test Execution Summary Report’ template to publish the final results after the completion of the execution. |
Thus prepared OQ Plan and Test Specification should be thoroughly reviewed and signed off by the relevant stakeholders to mainly ensure that either the coverage is not too low or too much and all the key functionalities are covered.
Successful completion of OQ demonstrates that the software will function according to its operational specifications in the selected environment and it is the stage-gate in moving the software towards its production and is the signal to go ahead with the next activity of the Validation process which is PQ.
Performance Qualification (PQ)
After ensuring successful IQ, OQ completion the next activity in the Validation process is to ensure that the product/software meets the specified Performance aspects under the expected load consistently without causing any bottleneck in the production environment.
The key aspect of PQ is to ensure that software, when installed on the expected system, can handle the live load and meet the expected response time, and does not crash under the peak loads and stress while handling concurrent users.
Hence PQ is mainly to ensure that the specified performance criteria for software are achieved over a period of time (maybe a week) on a reliable basis with varying load conditions, as is the pattern in life. Hence these tests have to be run every day to monitor the software system behavior and hence PQ will take a while to complete till it is ensured that the system is proven for its performance.
Ideally, PQ Validation is carried out post the completion of OQ, where the functionality of the software is ensured and can go ahead with verifying the performance aspect of the product or software. Sometimes due to time constraints, PQ can start in parallel to the OQ, based on the confidence in the percentage of OQ completion.
It is ideal to carry out these performance tests on the live system with the fully loaded system or on conditions similar to live and ensure that there are no bottlenecks in the performance aspects.
The following tests are generally run as part of the Performance Qualification. The choice of tests varies from software to software.
#1) Availability Test: To ensure that the software is continuously available without crashing or going down.
#2) Accessibility Test: To ensure that the software is easily accessible from every location with the expected performance speed without any issues.
#3) Load Test: To measure the system behaviour, the anticipated day-to-day load and also peak load conditions.
#4) Stress Test: To measure the breakpoint of the system under extreme loading conditions.
#5) Throughput Performance Test: To measure the response time of the system and to measure TPS (transactions per second )
#6) Scalability Testing: System can scale to handle the expected concurrent users.
Performance Test Scenarios and corresponding automated scripts are prepared based on the performance-related requirements specified in the “User Requirements Specification” document.
Similar to an OQ Plan, a detailed PQ plan which clearly states the testing approach, strategy, plan, and schedule along with tools, should be prepared and run through with the PQ executors.
The performance testing and monitoring tool needs to be installed in the environment where the PQ is being carried out to measure and report the performance metrics.
The following are the tips for the testers to enable the Operations Team to carry out the PQ successfully.
| Sno | Tips for the testers to enable the Operations Team |
|---|---|
| 1 | Prepare the key business specific scenarios to carry out the performance testing based on the URS. |
| 2 | Ensure that tests are included to prove that the system meets the expectations of response time, speed, scalability, and stability under various loading conditions. |
| 3 | Ensure that specified load is available or method and tools to generate the required load are clearly mentioned in the respective test cases. |
| 4 | Mention the pre-requisite for each of the scenario clearly, like the pre-load conditions that should exist on the system, number of concurrent users etc., |
| 5 | Mention tools recommended to be used to carry out the performance testing specific to each category of test and for each test. |
| 6 | Ensure that the process to monitor the performance metrics are mentioned clearly. |
| 7 | Guide, support and train the Operations team to carry out the performance testing on the system. |
Upon successful completion of PQ, meeting the performance requirements is very important as any performance-related deviations can cause a huge business loss by creating discomfort to the user, and the trust in the software to be used will be lost leading to the failure of the software.
In a nutshell, the table below summarizes the IQ-OQ-PQ activities.
| IQ | OQ | PQ | |
|---|---|---|---|
| What | To verify the process of software installation and how the process is documented | To verify the proper functioning of the system | Customers, Owners, Vendors, Operations team |
| Who | Customers, Owners, Vendors, Operations team | Customers, Owners, Vendors, Operations team | Customers, Owners, Vendors, Operations team |
| Where | At owners site, operations team location, live site, prod like environment | At owners site, operations team location, live site, prod like environment | At owners site, operations team location, live site, prod like environment |
| When | When the software is received from the software team, before OQ and PQ. | Before releasing the system for use and after successful IQ completion | Before putting the system to Live and after successful IQ, OQ completion |
The table below explains the various inputs for each validation phase.
| Type | Input |
|---|---|
| IQ | 1. Design Specification Document 2. Software binaries and other installation scripts 3. Installation Guide Document 4. Configuration guide Document 5. Build Verification and Smoke Test Document |
| OQ | 1. Functional Specification Document 2. OQ Plan Document 3. Operational Qualification Test Document 4. OQ Test Summary Report Template 5. IQ completed successfully |
| PQ | 1. URS (User Requirement Specification) document 2. PQ Plan Document 3. Performance Qualification Test Document 4. PQ Test Summary Report Template 5. IQ and OQ completed successfully |
Conclusion
Even if the product/software has passed all the verification stages and fails to prove any one of IQ-OQ-PQ, the result can be disastrous and will incur a huge cost. Hence successful completion of IQ-OQ-PQ alone is the successful transfer of the product from the development site to the production site.
Overall, the successful completion of the IQ-OQ-PQ validation process not only gives confidence in the software but also gives peace of mind to the Client, Owner, Software Developers, and Testers.
Running IQ-OQ-PQ also reduces the risk of deploying it to live, without carrying out testing and reduces the cost of failure, and mitigates the risk of recall of the products.
So, Guys, Software Developers, and Testers, no celebration after completing development and testing in-house and releasing the software to the Ops Team. The celebration is only when it successfully completes IQ-OQ-PQ and the software is live on the targeted system.
Hence the success of a software depends on the successful completion of IQ-OQ-PQ and when the software is live and ready for consumption by the end-users.
About the Author: This article was written by STH team member Gayathri Subrahmanyam. She has more than 2 decades of experience in the field of Software Testing. During her testing career, she has done a lot of TMMI assessments, Test Industrialization work, and TCOE setups in addition to handling test deliveries and implementing DevOps practices for a huge engagement. But according to her, learning never stops…
Share your experiences -in carrying out the validation process and let us know if you have any queries about this article.
It has been astonishingly explained/illustrated! Very much educational. Thank You!
Hello
When IQ and OQ completed on production build (quality environment) then shall we start PQ on live build (production build)???
Substantial information to the Ops team.
Thank you for Sharing!!
Thanks for sharing, content is very useful and important.
yes need to perform IQ Again.
Hi,
If same version of software were installed on replicate system, then we will perform IQ/OQ on all system and perform IQ/OQ/PQ on only one system. then it is acceptable or it will required IQ/OQ/PQ on all the system?
Regards,
HItesh Patel
Hi everyone,
Thanks each one of you for all your motivational feedback, which encourages me a lot…
Leared a lot from it!
Hello Gayathri,
Very good article and easy to understand with great illustration.
Plan to share with my collogues.
If you don’t mind, may I know your reference for this article?
Stay Safe,
Khai
How are software security patches and minor version changes affecting IQ, assuming no functionality has changed? Would updates to a system without any configuration changes require new IQ/OQ/PQ documentation to be produced? I am wondering how we could possibly stay up with security patches quickly, if it is burdened by this process with every update?
I am from development team and was not exposed to IQ/OQ/PQ. Thanks for the detailed write-up.
Hello Gayathri,
I am working on the computer system validation for the ERP system.I have finished one module of the ERP system.Can you please review the IQ, OQ and PQ.
Can you share any example of IQ, OQ & PQ for computer system validation?
Thank you
Bhawan
kindly share me the draft copy to this no please 8940059197
Thanks Gayatri for sharing detailed information.
Thanks a lot Gayathri Subrahmanyam.
Please share your email address here for further questions & clarifications if required in future as you are more experienced.
hi my email id is
javaidusman82@gmail.com
and i am trying to connect to the life science and bio tech community for IQ,OQ,PQ and with in validation process
i would highly appreciate it someone can connect with me on the subject to enhance further knowledge since i am stepping in to this industry
much obliged
earnestly thanking you
Thanks for sharing, these terms IQ, OQ, PQ mainly used in Health care domain specially in Pharma and Life science.
Thanks for sharing your insights on the aftermath of in-house testing! Much appreciated…..
Who writes the IQ, OQ, and PQ scripts?
The topic is well explained and clear. Thank you
Hi, is there an error in the table “In a nutshell, the below table summarizes the IQ-OQ-PQ activities.” in the “What” row for PQ. The cell says “Customers, Owners, Vendors, Operations team” which is the same as in the “Who” cell. I would expect something like “live load, expected response time, peak loads and stress while handling concurrent users during intended processes”.
Hi Gayathri Subrahmanyam! Thanks a lot for this very useful article!
I have a question regarding PQ, you mentioned that it must be done before taking the System live and i totally agree with you, but what about the Systems that are already live and have not been validated yet by customer and cant be uninstalled to perform Validation activities? is not it enough in this case to perform IQ & OQ (during OQ the functions of the System will be tested + Tests reflect daily activities done using this system ) as the System is already since years live?
Thanks for your Feedback!
Ferhad
Hi,
Is IQ has to be done again, if we are formatting the OS?
Eg: My instrument is running on windows-7 supported software,as windows-7 is not available in market from december 2019,Vendor suggested to upgrade it to windows-10.
What GAMP guidelines suggests in this issue?
Can you share any document related to it.
Thank you
Ravi krishna
Excellent article. Illustrative and straight to the core.
I wonder how can it be adapted to validation of today’s increasing demand on digital health softwares.
I would appreciate receiving some leading literature on the topic.
Thank you very much.
I am working on the Validation process in my company…and your article is very helpful for me…Thanks…
Keep sharing
Very much in detail….really a helpful content for test professionals from novice till amateurs…
You summed up validation process very effectively. Big Thx to you ….
Well articulated, Gayathri … Keep it up