How do we differentiate between Verification and Validation
First of all let us see how IEEE defines the terms Verification & Validation
A) Software Verification: “it is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.”
“it is the process of evaluating, reviewing, inspecting and doing desk checks of work products such as requirement specifications, design specifications and code”.
“It is a human testing activity as it involves looking at the documents on paper.”
B) Software Validation:
“It is defined as the process of evaluating a system or component during or at the end of development process to determine whether it satisfies the specified requirements. It involves executing the actual software. It is a computer based testing process.
“Both verification and validation (V&V) are complementary to each other.
Hence good testing expects more than just running a program.
To demonstrate this statement let us examine an example cum tutorial for leap-year function working on MS SQL (Server Data Base)
CREATE FUNCTION f_is_leap_year (@ ai_year small int)
RETURNS small int
–if year is illegal (null or -ve), return -1
IF (@ ai_year IS NULL) or
(@ ai_year <= 0) RETURN -1
IF (((@ ai_year % 4) = 0) AND
((@ ai_year % 100)< > 0)) OR
((@ ai_year % 400) = 0)
RETURN 1 –leap year
RETURN 0 –Not a leap year
Now let us execute the above program with different inputs as described in following Database table: Test_leap_year
(Year to Test)
|Expected Result||Observed Result||Match|
There are 15 sets of inputs in the above database table. We may feel that these 15 cases are sufficient for such a small program. We may write 100 such cases and show that this program behaves as per specifications. However, this is not testing.
By testing any program, we mean adding value to it. Adding value means raising the quality or reliability of the program. And raising the reliability means finding and removing faults. Hence, our objective should not be to show that the program works as per specifications. But, we should do testing with the assumption that there are faults and our aim is to remove these faults at the earliest.
If our goal is to demonstrate that a program has faults, our inputs selection should have a higher probability of finding faults. We should concentrate only on weak and critical areas of the program.
The critical areas for the above leap year program are as under
1) Removing statement ((@ ai_year % 400) = 0 would result in Y2K problem.
2) Entering year in float format e.g., 2007.12.
3) Entering year as a character or as a string.
4) Entering year as NULL or zero (0).
We may think of so many situations, which are quite risky for this leap-year function. These are critical areas. And the results are very strange with these inputs.
Our objective is to identify weak situations of any program and design test cases that makes the program to fail under such simple circumstances that no one would tolerate. If we are not able to remove faults, then proper warning messages should be introduced at proper places in the program.
Hence we can say that a good tester is the one who gets the most faults fixed.
|If you want to keep track of further articles on Software Testing,|
Get your Absolutely Free Copy of Several MS PowerPoint Presentations & E-Booksrelated to ISTQB, HP Load Runner, IBM RFT, HP QTP & QC Certification Exams, prepared by Popular Writers & Trainers, by writing to:Software.email@example.com
Study Material for Certification Exams on Other Automation Tools:
Download Full Study Material – HP QTP & QC Certification Exams
Study Material to prepare for Manual Testing & QA:
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.