Let’s assume that the people who created the V-Model weren’t completely mental. Lets assume they had some secret mystical wisdom that over the ages has been corrupted and obscured by layers of rules.
This video and post will not help you with any exam or ISTQB or anything that other people want you to parrot at them. I really only care about the practical application of models in testing. Not a universal definition.
So to describe a modern V-model testing process diagram. You have various definition stages on the left and then various ’testing’ stages on the right, and the testing stages map on to definition stages so Business Requirements might map on to UAT, and Business Benefits might map on to Operational Acceptance Testing etc. etc.
And this doesn’t work, wastes time and money and detrimentally affects everyone involved. So what do we do? We throw the V-Model away.
No we look at it for its essence.
First get rid of the notion of time. Every project I’ve been on has iterations. Nothing works with a linear time line, assume any model you see that uses this representation will not map on to the real world.
Back in the dim and distant past, we learned about verification and validation so the V in the V-model helped us remember this. Except that it didn’t because for me, mnemonics that use the same letter for different concepts don’t work. V mnemonics for me deal with “V for Vendetta” or “V for Vengeance” and these concepts do not exist in testing (possibly project management but not testing).
Validation was “Are we doing the right thing?”. Verification - did we do it right?
And we have another model for that - Questioning and Checking. We Question decisions, plans, designs requirements - are you sure? should we do this? should we do this other thing? how often should we do this? etc.
Then, as it start to materialise, we check. did we do what we said? And we continue to questions: Should we continue to carry on this way given what we just learned? What else did we do that we don’t understand the knock on effect of.
So I don’t V & V any more, I question and Check.
And in the V model, this left hand line represents Questioning, and the right hand side represents Checking.
Another thing we have to sort out in our V-model relates to the ordering. Because when they drew it for software testing, they made it an ordered model based on time. Which made it appear that you didn’t check the business case until it was live, or you didn’t check the business requirements until UAT.
We can treat anything written on the questioning side a bulleted list. A brain dump of what we think we have available to question: requirements, business case, decision log, GUI - whatever, and we can order it by word length or alphabetically, word length works well with a V-model because the short words sit at the top where the space is smallest.
Since we removed the notion of time we can question these ’things’ whenever we consider it appropriate to do so, and check them, as soon as something exists to check, and as we elaborate, we question and check in different ways.
So I reclaim the V-model for myself. And now it adds value. In fact it stands for Value - V for Value, where our job in the process is to add value, to reframe, question and check. Do it simply and clearly and own our models and communication so we do them in ways that benefit our domain and our context rather than for historical reasons that we don’t understand or agree with.
P.S.
- It doesn’t need to be a V - I just threw in that whole “V for Value” thing as motivational noise.
- In the real world, we have a set of stuff, and we have to remember to question it and check it, so you could model that as three columns:
|Stuff | Some questions of each piece of stuff | Some checks to make on the stuff| - And we don’t limit ourself to questions and checks, we question our answers, we model it all as a graph, we don’t just use columns, we iterate, we do whatever it takes to model our world. By all means start with a V-model, and own it, but build your own model.
