Verification and Validation
Verification and Validation
Testers often make the mistake of not keeping their eye on the end goal. They narrow their focus
to the immediate phase of software development and lose sight of the bigger picture.
Verification tasks are designed to ensure that the product is internally consistent. They ensure that
the product meets the the specification, the specification meets the requirements . . .and so on.
The majority of testing tasks are verification with the final product being checked against some
kind of reference to ensure the output is as expected.
For example, test plans are normally written from the requirements documents and from the
specification. This verifies that the software delivers the requirements as laid out in the technical
and requirement specifications.
It does not however address the `correctness' of those requirements!
On a large scale project I worked on as a test manager, we complained to the development team that
our documentation was out of date and we were having difficulty constructing valid tests. They
grumbled but eventually assured us they would update the specification and provide us with a new
version to plan our tests from.
When I came in the next day, I found two programmers sitting at a pair of computer terminals. While
one of them ran the latest version of the software, the other would look over their shoulder and
then write up the onscreen behaviour of the product as the latest version of the specification!
When we complained to the development manager she said "What do you want? The spec is up to
date now, isn't it?" The client, however, was not amused; they now had no way of determining what
the program was supposed to do as opposed to what it actually did.
Validation tasks are just as important as verification, but less common.
Validation is the use of external sources of reference to ensure that the internal design is valid, i.e.
it meets users expectations. By using external references (such as the direct involvement of end-
users) the test team can validate design decisions and ensure the project is heading in the correct
direction. Usability testing is a prime example of a useful validation technique.
A Note on the 'V-model'
There exists a software testing model called the V-model, but I won't reproduce it here since I think
it is a terrible model. It illustrates different phases of testing in the SDLC, matching a phase of testing
to a phase of requirements/design.
I don't like it because it emphasises verification tasks over validation tasks.
Just like the waterfall model it relies on each phase being perfect and will ultimately only catch errors
at the very end of the cycle. And just like the waterfall model there is an updated version which
attempts to rectify this but only serves to muddy the waters.
But the V-model does illustrate the importance of different levels of testing at different phases of the
project. I leave it as an exercise for the reader to uncover it.
10
