V Model – a succinct Test Strategy

UAT is all about “How to Make Try to understand if the cake is ready”.   Which is Google translate for:  “Come Fare la Prova per Capire se la Torta è Pronta”.  Which you can read all about on WikiHow. Actually this is really more like a “System Test”.  UAT would look more like:

bill_murray_gif_9And by the way – not to digress too far but in looking for a good picture of eating cake I found some very very disturbing images of wedding and baby-shower cakes.  Anyway, we don’t have time for this.  Testing!!!…

The point of the cake lede is this.  If you have to test a cake – how much more should we test our software implementation.  In fact, the principles here can be applied to any deliverables of consequence.

If you have participated in software projects you will know the following to be true:

  • Testing is essential for success.
  • It is possible to run extensive tests without testing all the testable conditions.
  • You cannot test quality into a product (this has to be designed and built in).
  • When development slips, the extra time is taken from the test phase. The end-date, being set in stone is the hard place against which the test-team is squished.

The V Model for testing provides a useful framework for dealing with these issues. It is not the silver bullet but it does offer a route into the heart of necessary conversation.

Here is a view of the model I prepared for a breakfast presentation a while back.


As you can see there are four distinct areas of action in the V Model:

  1. Analyse and design the system: The process on the left follows the usual Systems Development Life Cycle (SDLC).
  2. Create test materials. The actions down the middle are the steps you take to create the test materials.
  3. Formal Technical Reviews: Here the relevant stakeholders assemble to read through the outputs from the previous two steps. Formal Technical Reviews are the most effective way to ratchet up the quality of writing and software.
  4. Develop, Integrate and Test: In this process, the work is carried out to develop the code, to test each unit developed, to integrate the units into working components and to test each of the components as they are compiled and assembled.

The V model reads from the top left and ends at the top-right.

V Model starts by collecting User Requirements

The first step is to find out what your users want. Books have been written about this step. For some teams the idea of going out to speak with users is novel, bewildering even intimidating. The process invariably involves marketing and selling. Steve Jobs just said “They don’t know what they want because they haven’t seen it yet, but when they see it they will desire it with all their hearts.” (Don’t google this – it’s a paraphrase)

Next design the relevant tests.  With the documented requirements, usually in a Business or User Requirement Specification, the test team can compile the tests to be run to show that the system really does deliver what was requested, the User Acceptance Test (UAT).

The next step is where the magic happens. Formal Technical Reviews, are tightly controlled read-throughs of documentation (or code) under development and they represent possibly the most valuable use of time in the whole development process. The development team and the test team sit with representatives from the community of users and they read through the documents, the requirements and the test cases.

And here is the trick.

Everyone in the meeting comes prepared. They have all read the documents and noted points they want to query or clarify. If the preparation has not been done, the session should be cancelled. (Usually you have to do this only once). The facilitator steps through the documents, reading each line. When a line is read that concerns one of the participants, this person voices their concern. The concern is logged and the read continues. Concerns are not discussed, simply logged. This requires tough facilitation and some specific training. The risk of getting into debate is really high, especially if the writer of the document being reviewed has a fragile ego.

At the end of session, everyone involved has a clear view of what has been written and their concerns have been heard. After the session smaller groups meet to address concerns and clarify issues. If the changes are small they are addressed and the documentation is updated. For large concerns, a redesign meeting may be convened.

Rinse and repeat

The same sequence continues for each phase in the V Model.  As shown by the different colours in the model, this process may be carried out for each level in the model. By the time the development reaches the upside down apex, the yellow block that says ‘code’ everyone knows what they have signed up for. The development team carry out the unit developments, run the defined tests. They link the units as agreed and run link tests. They test the system on the required platforms and with the interfaces specified in the design.

And finally, when it is all working, the users (who have been involved in the process from the start, run the UAT to confirm that they are getting what they wanted.

Here is the other side of the V Model card:


Sure this is an ideal view. And sure there may be costly changes to the design once the coding has begun. A statistic I remember from my days as a Quality Manager is that an error in requirements, identified during the Final UAT may cost 100 times more to fix than if the same error is only found during the final UAT. But now everyone knows what they are in for when the projects hits obstacles.

And if a project runs into one of these high cost changes, they discuss it as a team rather than finding ways to pretend it is not happening or ways to level blame. The change is tabled and everyone is kept in the picture.

This sounds like a LOT of meetings.  Well it may be.  But in my experience this addresses one of the yawing pitfalls in any development process: the lack of adequate communication. Not enough conversation. And we all know, when we talk enough, everyone just knows what to do.  And anyway it is possible to hold efficient meetings.  Another posting topic.