IQ,OQ and PQ with Agile methodology

by admin on April 29, 2013

Interested to hear how generally traditional waterfall methodology processes for IQ,OQ and PQ are being adapted for IT projects where development and implementation is being done to Agile methodology? Add more details…

#SQASolutionShare on FacebookShare on Google+Share on LinkedInTweet about this on TwitterEmail this to someone

{ 5 comments… read them below or add one }

Dr. Anil Dhiri, DVM MBA April 29, 2013 at 7:00 pm

Thanks for your comments. Validated testing can only be against requirements I agree. In Agile(Scrum), requirements are there but I suppose the question is when does one consider them formalised. I like Sabine’s approach of working to “Release” concept. So I would say that as part of “Release” the requirements of that release are formalised and the formal IQ/OQ/PQ done for that release. For next release performing a risk analysis, working to GAMP 5, the approach of doing IQ/OQ/PQ for new features seems a very sensible approach. I presume some may still want some regression testing but that should be based on impact/risk analysis. This approach provided stakeholders buy into risk/impact analysis approach sounds the most sensible approach to me to remove massive validation overheads seen in GxP compliant projects in pharma.

Sabine Darolles April 21, 2013 at 10:59 pm

I work on Agile project (Scrum) we have decied to group several Sprints in a Realise. For this Realise we a decicated sprints for the validation efforts with risk analysis and IQ,OQ,PQ test scripts. For the Realise 2 we will manage under change control process with impact analysis, no regression tests and new QI, OQ and PQ tests scripts. The validation process and the role and responsibilities are detailed in the validation plan and all deviation will be detailed and justified in the validation report with the conclusions. I hope it help you

Tonny Sasse April 25, 2013 at 6:39 pm

We have following that approach for some years.
A feature contains one or more high level user stoies (it is only used as a label for organizing test cases). The user story is linked to test cases that define the feature. The test cases are created by a feature team, including Testing, Development and Product management. This ensures that through the test causes the feature is well understood. At done-done the PM signs off on the user story saying that the feature is implemented as intended and it is tested properly, and there are no open defects we want to address ever in the feature. This is all tracked electronically.

Using proper tools to store this information you can create a software definition (not using the word requirement anymore) that defines the product by creating a trace between user stories and testcases through a report. No need for tracing between highly granular requirement documentations as well as functional and test specifications

The reporting will give you validation reports if you can electronically trace user stories, tests run and test results

There much more details at play but it is time to evolve further to go from a full paper validation systems, then replace paper with word documents, to full bore electronic reporting
I would coin that Quality Management System 2.0 (QMS 2.0)

Stephen Goldman April 25, 2013 at 11:00 pm

Qualification testing is not possible without requirements. In order to test, the test must must be in accordance with something. Generally, requirements.

I became a Certified ScrumMaster for the sole purpose of figuring out how to deal wth this situation. The only way I see that it can be handled in accordance with regulation is to either prepare the requiremnts at the same time as the product is being developed or to do an “as built” version after the sprint. Either way, the testing is then performed IAW the requirements..

Richard Mulders April 29, 2013 at 11:01 pm

Working per release indeed is a good approach.

Additionally to that you could also change your mindset from IQ/OQ/PQ documents to information, or records.
Meaning you are no longer approving the requirements document, but the individual User Stories (which hold the user requirement, functional requirement, and acceptance criteria in one set).
The actual test for the user story could also be written, approved, and executed as part of the development process.

The release sprint then can focus on the regression testing of the additional functionality (with current functionality, if required) and on the creation or update of the Validation Report.

Yes, you will get a lot more approvals.
But with the right Part 11 compliant supporting system, which allows you to approve on User Story level, this would also mean that functionality which is approved already can go into production via a release, without having to wait on possible discussion regarding another piece of functionality (or documentation around it).

If you’d like to have more information on our Part 11 compliant Compliance Management System, please send me a personal message with your contact details.

Previous post:

Next post: