Validation Testing …

During my graduation, I had a course named “Software Engineering” and I remember there is a mention about two terms – “Verification” and “Validation”. I like the way these terms are defined:

Verification – Are we doing the right thing?

Validation – Are we doing the thing right ?

Observe the placement of the words – ‘right’ and ‘thing’.

Before I jump to the actual topic, let me touch by the other word in the title – “Testing”.

Well, many techies out there feel that “testing” is a “boring” task, or relatively boring than “development”. This is a common feeling among people who are into software development.

Let me not open a debate on this, but take an opportunity to express my views on “testing”.

To me, testing is “comparing expected vs. actual” – as simple as that but of late, I realized that my definition is simpler than the actual work !! Now where is the complexity – the actual is what you see, but the complexity is in what is “expected”.

When you ask somebody to give an example for testing, people start off with the simplest/junkest possible example – method ‘add’ that takes two numeric values and returns a result (numeric again). Test this by passing 2 and 3 and compare the result with an expected value of 5. And then, people say, that’s it dude, you now know how to test, just go and attack that s/w ;-)

As I pointed out, the key thing is to get the “expected” value right. Now if you don’t know what to expect, what do you test?

If you scroll up, you might realize that the definition for "Validation" is apt – “Are we doing the thing right?” and the implied question is –“Do you know what is right ?”.

Let me wind up with one of the cases that I came across recently:

We have developed a data transformation package that takes a bunch of spreadsheets with a set of worksheets in them as input and loads the data in these sheets into a couple of tables in the database.

The requirement is not that complex and with the documentation that we have, we were able to implement the package successfully. Now the tough part is “Validation Testing” – in simple terms – “How to justify that the package is loading the data properly into these tables?” Well, the package executes with “no errors” and that doesn’t mean that the package is doing what we expect, isn’t it?

To justify that the package is producing the expected results, we have defined a set of parameters like – ‘number of rows in the sheet, number of rows inserted into the table, etc’ and started collecting metrics for these parameters. Believe me, the statistics did really justify that the package does what is expected and it also helped us identify the errors (implementation logic related errors due to incorrect understanding of requirements) and troubleshoot the same.

If you think that the process of calculating metrics is “boring”, it can be automated by using a sophisticated tool or by developing a tool all by yourself and thus turn a “boring testing” task into an interesting “development” task :-)

I always used to wonder how “medicines” and “aeroplanes” are tested, ‘coz even though you know the expected result in such cases, an ‘error’ is very expensive :-(