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.