Why Continuous Validation is important in Agile Product Development
It wasn’t so long ago that Agile development processes were considered incompatible with validated systems because of the documentation requirements but their use is becoming more common and experience has shown that getting features into the system quickly through incremental release is worth the extra work of the more frequent validation packages. Continuous Integration (CI) is a process where changes to the system are integrated into the core system code as each feature is completed. At PHARMASEAL we have embraced CI and extended it so that each new feature passes through its own discrete validation process as it is integrated. Our process maintains the system code under such control that a validated release can be made in one day - from code freeze to validation approval, including manual smoke testing and analysis of test failures.
Requirements management:
Each feature is described in a User Story and prioritised in a shared tracker / management system by the Product Owner in consultation with the team. The user requirements for any release can be generated as a report from this system on demand.
Automated testing:
Each new feature has automated testing defined right from the start which must pass before acceptance testing can commence. The automated testing is maintained and acts as regression testing in the future. The whole set - currently over 4,500 tests - is run every time a change is made to the system. The test definitions are written in plain English and the full set can be combined into a document to form the Functional Specification for the system.
Continuous Integration:
On completion of each piece of work on the system, the updated code is integrated with the current version of the system in the QA branch. The integration procedure requires the code changes to be approved by peer review and a successful run of the full set of automated testing. The test results of all runs are stored and reports can be downloaded on demand.
Acceptance:
Each Feature is formally tested and accepted by the Product Owner after delivery to the QA environment. The story is only considered done once accepted.
Release management:
Releases of new versions of the system to the production system are scheduled and carried out under change control. The release candidate is identified in QA and moved to the Staging environment for final validation prior to release to Production.
Validation pack:
As all the core validation artifacts - requirements, functional specifications, test specifications and test results - are stored as data, the bulk of the validation deliverables are generated as reports. To create the validation package we run, review and approve all the reports, carry out manual smoke testing at key release stage gates, analyse any test failures and document the process in the Release Notes. When the validation package is approved the change control is approved to allow release of the new version to Production. At the moment it takes us about 8 hours to generate the validation package for a new release from code freeze to sign-off.
The benefits of this Continuous Validation approach are not just that we can release new functionality (and bug fixes) much quicker while maintaining quality and control, but also - because the manual repetitive steps are automated and reproducible - the whole team spend much more time thinking about the process and how we can improve it - so quality is always at the forefront.
Many thanks for your interest, please reply with any questions or comments - Hugh O’Neill, Operations and Quality Director for Pharmaseal info@pharmaseal.co