Mike Ramm said: July 30, 2007 9: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: August 10, 2007 2:00: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.
brucehenry said: August 19, 2007 9:29: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.
Kevin Haines said: September 24, 2007 5:47: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.
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.