The V-model: Can It Be Adapted in Agile Methodologies?


The V-model provides a checks-and-balances approach to software quality assurance (SQA). The Software Development Life Cycle (SDLC) tasks of capturing requirements, designing a system and writing code have corresponding quality checks to validate that the product meets the technical/design requirements, functional & system requirements and business/user requirements. At the same time, the various SDLC phases have embedded verification practices that ensure quality is infused throughout the process.

One of the main objectives of Quality Assurance (QA) is to ensure full coverage of the requirements and code. That being the case, can teams leverage the V-model concept in an Agile environment to govern the quality process? The Agile framework advocates for a Test-Driven Development (TDD) approach that places more importance on a comprehensive quality assurance approach, and the V-model concept can provide a good foundation for this approach.

This article discusses how a team can leverage the V-model in an Agile environment to infuse, track and deliver quality.


What Is the V-model?

The V-model, also known as the Verification and Validation model, is a type of software lifecycle model. As it is aptly named, the model incorporates various verifications and validation activities from the requirements-gathering stage of a project through product testing and user acceptance. These activities assure the delivery of a quality product that meets system, user and business needs.

The V-model gets its name from the sequence in which verification activities are mapped to corresponding validation activities. Figure 1.0 outlines the sequence and the related activities.


v-model image

Figure 1.0 V Model

Verification Sequence

After a project kicks off, the first typical phase is planning, which includes requirements gathering and system designing followed by coding or building of the product. Quality in these activities is tracked via verification activities in the form of reviews as discussed below:

Requirement Definition – A good practice is to have all stakeholders involved early in the process. In your Scrum and SAFe environments, you have a Product Owner (PO) who represents the business and users. The PO is responsible for documenting requirements (user stories) and ensuring the project team and subject matter experts (SMEs) provide their input through review sessions. In turn, the business signs off on the requirements with the confidence that the end product will align with the company’s vision while factoring constraints, risks and level of effort.

Design – The system design provides the framework for how the scoped components interface with each other and integrate to form the whole. Similar to requirements, SMEs are expected to provide feedback through reviews to ensure the system design aligns with the business and technical objectives. Potentially impacted systems are also factored in these reviews.

Coding – Code reviews are essential in Quality Assurance practices. Concepts such as paired programming commonly used in Extreme Programing (XP) are intended to make sure the right thing is built and, in the right way, reducing rework from defects detected further down in the product lifecycle or production.

Test Design – As different test types are written and subsequent test suites are created, peer reviews are facilitated to ensure full test coverage. Testers review each other’s work with an objective of creating a comprehensive set of test cases that meet the business, functional, technical and, in some instances, regulatory requirements.

The above noted verification activities make up the first branch of the “V” in the V-model.

Validation Sequence

The second branch is Validation. The planning, designing and development activities have corresponding validation activities designed to ensure the right product is being built and meets the business and user needs. The concept is to cross-check the code, design and requirements against different testing types as discussed below:

Unit Testing – Unit testing is the practice of testing the smallest testable parts of an application, i.e. the units. Developers execute this type of testing during the development phase (or within a sprint) to ensure code coverage and validate the operability of the completed units.

Functional Testing – Functional testing answers these questions: is the product or application functioning per specifications? Can the user derive utility when using the product without experiencing any system issues? Functional tests are designed to mirror how a user will interact with the system from a holistic perspective, i.e. testers need to test every possible scenario, even if unlikely, to determine whether the application is fully functional (hence the name). Functional testing also validates the functional requirements defined during the planning phase.

System Testing – System testing comprises of a broader set of tests, such as end-to-end testing, integration testing, performance testing, stress testing, usability testing and regression testing to mention a few. This set of tests validates the system design, i.e. they check if the application is stable and properly designed as well as if the components work together seamlessly.

User Acceptance Testing – Also known as Customer Acceptance Testing (CAT), User Acceptance Testing (UAT) is performed by the sponsor and/or by the end users to verify that the application meets their daily business needs. UAT answers this question: does the product meet the demands of our day to day activities and does it perform the job as we intend it to? In turn, the exercise validates the business requirements defined at the start of the project.

The key difference between functional testing and UAT is that the latter is a subset of the former, and the focus is on how users interact with the application on a day-to-day basis. UAT is also executed by the end users and not professional testers.


What Is Agile?

The Agile Manifesto

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

The Agile software development framework is a set of iterative software methodologies that credits its foundations from production management techniques, such as Just In Time (JIT), Total Quality Management (TQM) and the Kaizen philosophy - a Japanese business philosophy of continuous improvement.According to Agile Alliance’s Agile 101 definition, Agile software development refers to a set of practices and methods based on the principles expressed in the Agile Manifesto. Self-organizing and cross-functional teams develop solutions through collaboration, and the product is delivered in shorter iterative cycles unlike traditional methodologies such as waterfall, which takes several months before value is realized. 

V-model Concepts in Agile

A key advantage of the V-model is comprehensive vetting and a checks-and-balances approach that assures not only code coverage but requirements coverage as well. The model also focuses on how tests are written and executed so as to validate corresponding upstream planning activities, hence promoting a test-driven planning and development approach.

Agile could be described as a diced-up approach to waterfall (with some key variations of course) that promotes transparency, communication, continuous improvement and, most importantly, a shorter feedback loop. The key advantages of the V-model that align with Agile are:

  • A higher quality product is based on the verification steps.
  • Verification is done from the beginning of the product lifecycle, thus reducing rework downstream.
  • Defects are caught and addressed at a much earlier stage. One aspect frequently overlooked is that defects can be introduced into a product via wrong, incomplete or missed requirements. The verification steps are designed to catch this.
  • Validation steps push for a test-driven approach, which provides the confidence that the application is being built to meet all business, system, design, regulatory and functional requirements. 

The V-model concepts can be easily molded into Agile practices, and some have already started setting root. We can incorporate this comprehensive quality assurance approach in Agile as follows:

  • Requirement Definition – Ensuring continuous review of requirements (epics, features, and user stories) as they are written and concluded. At minimum, this will include the product owner, scrum master and scrum team. This practice ensures a well-groomed backlog.
  • Designing – Continuous review through white-boarding sessions as well as through technical reviews by subject matter experts and impacted teams or systems. This ensures the ecosystem is not inadvertently impacted by updates or introduction of a new system that may not be compatible with the current systems.
  • Coding – Pairing peer developers to vet each other’s work. This provides a second set of eyes to correct any potential defects and ensure conformity to current protocols and standards.
  • Test Case Writing – Peer reviews help identify missed test scenarios and create an exchange of system knowledge. Similar to code reviews, peer reviews are designed to create a comfortable and informal critiquing environment that yields quick revisions, corrections and additions to current tests. It should be noted that in Agile, developers are included in these test case reviews and the collaboration between testing and development easily yields to a Test-Driven Development (TDD) approach, which is desirable in mature Agile teams.
  • Test Execution – The testing of the code, functionality, usability and system as a whole is executed not just to pass and fail test cases but to also deliberately evaluate whether the intent of the project or system has been actualized. The final tests should check against the product vision and with alignment to the product roadmap.


The V-model provides a process that can be used to verify and validate the various artifacts and steps followed in a software product lifecycle. The concepts are practical in an Agile setting and to a varying degree already in implementation. For example, Extreme Programing (XP) has pair programing, which is a way of vetting work through peer reviews, and TDD approaches quality from a testing perspective.

Agile has a flexible and adaptable concept but also has its formalities, and infusing a Verification and Validation approach can help software shops ship higher-quality technology solutions that meet user needs and the organization’s vision.



  • Kent Beck, Jeff Sutherland, Ron Jeffries, et al. “Manifesto for Agile Software Development”. 2001

  • Agile Alliance. “Agile 101”. 2015