Doing Justice to V&V

Published 29 July 07 06:40 AM | Earl Beede

One of my secret passions is to kill the man (or woman) who started to use the terms verification and validation in the software world. I know you are hiding out there and when I find you, I will do justice.

I mean, first of all there is this horrible trick of using two words that sound soooo close in English. We don't use many of those 'V' words in this language on a day to day basis so just starting out with a 'V' pretty much means we ignore the rest of the letters. I think I only know about five 'V' words off the top of my head: Valium, (beach) Volleyball, Vacant (my head), and those two nasty beasties listed above. And they all mean the same thing, "time for beer."

And then there are the software related definitions of those two words. Verification: did I build the thing right; Validation: did I build the right thing. Or is that the other way around? I can never tell. I always need to look it up since it is just switching a word here and there. Not that starting the word with a 'V' helps me out much (see previous paragraph). It is like asking if I drank the beer and was it the right beer. Well, by definition, if I drank the beer it was the right beer!

And in the shorter phrase "V&V", which one comes first? Is there a rule on that? Is that rule as critical as the one about not wearing socks with sandals?

Wouldn't it have been better if we called it Requirements Confirmation and Design Confirmation? First of all, we would a nice alignment with the activities that typically produce the needed stuff for the V&V and the V&V itself. Second, we would have words that are completely different and therefore much harder to confuse. The drawback with this solution, of course, is that nobody really gets the difference between requirements and design. (Somebody just said to me the "what vs. how" thing again today and I almost did justice on them!)

There has to be a better way! I will find you V&V instigator! I will vilify you! You will wish you were virtual! I will vanquish the pain you have caused virtuous software developers. Very truly I tell you, vultures will think it vain to feed on the bits left. Victory is ours.

V on!

Filed under: , , , , ,

Comments

# Mike Ramm said on July 30, 2007 09:24 AM:

Earl, count me in for doing the justice, too!

Can you imagine how much more difficult it is to distinguish between Validation and Verification for people whose native language is not English?

I would propose to make a contest for defining better terms. We just have to propose some large volume of beer and we'll have a lot of participant :-)

# Kevin said on August 10, 2007 02:00 PM:

"Very truly I tell you, vultures will think it vain to feed on the bits left. Victory is ours."

Change "bits" to "victuals" and verily, your very venomous and vigorous diatribe against the vampires of V&V will succeed.

On a more serious note, the closest I have come to a successful definition is to say "You validate requirements and verify specifications."

Now, if only I knew the difference between a requirement and a specificaiton.

# brucehenry said on August 19, 2007 09:29 PM:

I am SO with you on the V&V thing.  Which one am I doing now?  How should I write the email to make it clear?  Will the person on the other end understand why we're doing verifi... er... validation on their requirements.  Wait... maybe we're verifying that these are actually their requirements.

Gahh!!

To add yet ANOTHER "verification" into the mix... My personal pet peeve along these lines it the use of the term "regression" when talking about bugs.  Yes, there is such a thing as regression.  But when most testers say that they "have a bunch of bugs to regress", what they mean is that they "have a bunch of bug fixes to verify".

Drives me friggen crazy.

# Kevin Haines said on September 24, 2007 05:47 PM:

If it wasn't the original source, then CMM/CMMI would be a major force behind the use of the terms V&V in software development today. So Earl, I think a visit to the CMU campus should be on your list of things to do.

Like others, I find it near impossible to remember which is which. Ultimately, I find myself not caring which word it is, but being interested in the concept it is trying to instill. An analogy I once heard was that of building a house: "Did you build the right thing?" translates to "did you build the house the customer wanted? Is there the right number of bedrooms, and are they where they were supposed to be?". "Did you build it right?" translates to "does the building conform to local and federal building regulations? Was the electrical and plumbing work done by qualified people?".

Another common problem I have observed is the simple Validation=Testing, Verification=Peer Review. Alas it is not that simple, and some validation "did we build what the customer wanted?" can only be confirmed via static anaylsis (say a code review), and some verification "did we build it right?" can only really be confirmed through execution - static analysis may not be adequate.

In the end, the thing that really matters is what the CUSTOMER wants/needs. Unless there are specific design constraints specified as actual requirements, should we even care about design confirmation (beyond that the design will satisfy all the requirements)?  In that sense, you could argue that verification as defined by the CMMI "...to ensure that selected work products meet their specified requirements" is largely redundant.

I believe both testing and peer reviews are very important tools to producing good quality software, but am far from convinced about the V&V breakdown.