Home > Agile, Waterfall Model > Why Agile is better than V-Model?

Why Agile is better than V-Model?

V-model is a software development model that involves building a logical V shape sequence where the testing techniques associated with the design are reflected as descending and are applied for the “verification” and connected to the requirements or specifications parts are reflected as ascending and are applied for “validation”. Equal weight to coding and testing in the V-model gives software development process. The V-model ordains that the code testing documentation is written in tandem with the development phases that means, for instance, the integration tests should be documented as and when the high level design is finalized and the unit tests should be ready as and when the detailed specifications are laid down.


The idea of the V-model is to have a implementation plan for the software testing at each level namely component, interface, system, acceptance and release of the software project which need to be adhered to eliminate discrepancies in the software simultaneously rather than waiting for the software development process to complete before handling it to the software testing professionals.

Agile testing is a software testing practice that follows the rules of the agile manifesto, treating software development as the customer of testing. Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing. Agile methods were developed as a response to the issues that the traditional V-Model and waterfall methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed.


Testing from the beginning of the start of the project and continually testing throughout the project life-cycle is the foundation on which agile testing is built. Every practice, technique or method is focused on this one clear goal. Agile methodologies are designed to break the software down into manageable parts that can be delivered earlier to the customer. The aim of any Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. An Agile project is characterized by having a large number of short delivery cycles (sprints) and priority is given to the feedback-loops from one cycle to the next. The feedback-loops drive continuous improvement and allow the issues that inevitably occur (including the way requirements have been defined or the quality of the solution provided) to be dealt with much earlier in the development life cycle. To achieve this, companies need to re-think their approach to delivery and have their previously independent contributors (Business Analysts, Developers, Testers, End Users etc.) worked together in teams.


The key challenges for a tester on an agile project are:

  • No traditional style business requirements or functional specification documents. We have small story cards developed from the 4×4 inch cards, which only detail one feature. Any additional details about the feature are captured via collaborative meetings and discussions.
  • Testing starts as early as practical and continuously throughout the lifecycle so expect that the code won’t be complete and is probably still being written.
  • Acceptance Test cases are part of the requirements analysis process and are developed before the software is developed.
  • The testing team has a responsibility to create automated unit tests which can be run against the code every time a build is performed.
  • With multiple code deliveries during the iteration, the regression testing requirements have now significantly increased and without test automation support, the ability to maintain a consistent level of regression coverage will significantly decrease.

Why I prefer Agile over V model?


In the phase diagram, it is clear that testing in Waterfall happens at the end, right before release. The diagram is idealistic; because it gives the impression there is as much time for testing as there is for coding. In many projects, this is not the case. The testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.

Agile is iterative and incremental. This means that the testers test each increment of coding as soon as it is finished. Iteration might be as short as one week, or as long as a month. The team builds and tests a little bit of code, making sure it works correctly, and then moves on to next piece that needs to be built. Programmers never get ahead of the testers, because a story is not “done” until it has been tested.

  1. April 26, 2013 at 3:09 am

    We tried forming teamlets (aka, sub teams) with in agile team consisting of 2 developers and 1 tester and implemented V-Model with in the teamlets. Means, we have V-model for each user story. This helped us make testing and dev teams collaborate quickly and work towards common team goal.

    Scrum Coach

  2. Harish
    August 28, 2013 at 3:06 pm

    yeah combining both agile and v model give us good result.

  3. October 11, 2014 at 4:19 am

    I do accept as true with all of the concepts you’ve presented on your post.
    They’re really convincing and will certainly work.
    Still, the posts are too quick for newbies. Could you please
    lengthen them a bit from subsequent time? Thanks for the post.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: