Validation – It’s More Than Just Testing (Part 1: The V-Model)

By Daniel Riganati

Validation is more than just testing. Its scope is broader than testing and it has an emphasis on not only achieving a validated state for a computerized system, but also maintaining that validated state. While the terminology may be different, many aspects of computerized systems validation (CSV) are “good practice” and occur as part of the development, implementation, and maintenance of a system. However, if you do not exercise discipline in your document and record management you may not be able to prove that a system is validated.

The V-Model is similar to the Waterfall SDLC Methodology

The figure below shows a high level overview of a validation methodology, called the V-Model, based on GAMP® 5, and applied to a cloud environment. It shows the deliverables of the V-Model with the validation activities across the top, the project SDLC activities across the bottom, and the allocation of responsibilities between the tenant, the cloud, and the physical/virtual infrastructure hosting vendor along the left.
Figure 1. V-Model applied to a cloud environment


The methodology shown in the figure is called the V-Model because while it has many aspects of a waterfall SDLC methodology, the depiction of the deliverables as a “V” illustrates the symmetry between the testing and verification of a computerized system against the specification on the same level. It starts on the left-hand side of the diagram with specifying both what the users want from the system and also what capabilities and functions the system must have.
From the specification phase on the left-hand side of the diagram, there should be enough information to configure, design, and/or build the system and its supporting physical and virtual infrastructure, which occurs at the base of the V. This is where the system is installed, customized, and tested by the developer.
The dynamic testing and verification of the configured and customized system occurs on the right-hand side of the V. Dynamic testing is exercising the application against a specification while verification is confirming that a requirement is met outside of the system by developing controls and procedures.
Typically, there is a symmetry in the V as the dynamic testing and verification of the application is against the specification on the same level, so there is more detailed testing at the lower levels of the V (white box testing focused on the inputs and outputs of the modules of software) and higher level testing at the top of the V (black box testing looking at the overall functions of the application).
Once all validation deliverables are complete and approved, the application is released to the operation and maintenance life cycle phase.

So what’s different about validation?

Been there. Done that. So what else is new? As I see it, there are four things that differentiate CSV from the SDLC. I’ll be covering these in more detail in subsequent blog posts:

1. Validation terminology
2. Validation scope
3. Emphasis on maintaining the validated state
4. Record keeping