Saturday, October 9, 2010

How important is to check the input data type while testing...

Input type testing or input domain testing is the word which we usually use for testing the mismatches of inserted input value to our program.So, how important this type of testing in our test life-cycle. Some testers may find it important, on the other hand some may not put special importance on this. Because the second group may think that developers by default check this input testing while coding. But, do the developers always check this things?? I think they do not. So, are you still thinking about the importance of input testing??
I bet you will give more importance on this testing after reading the story below:

Explosion of the Ariane 5

On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after lift-off. The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,768, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
The following paragraphs are extracted from  report about the explosion::
On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.
The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system.
The internal SRI* software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. 

So, what are you thinking now after reading the story. Is input type testing is worthy or not. Are you not convinced yet. If you are not, then i think you probably will never be.



  1. Interesting stuff. Beware of programmers telling you no user will ever enter such unusually high or low or weird value, when testing such type boundaries. You may need to come up with credible scenarios when you discover such bugs, to get them fixed.

    Also, these get extremely difficult to test when you have very complex expressions and dependencies. I suspect that was the case in this disaster, rather than negligence. Everything sounds very obvious when analyzing the cause after the problem has occurred. This is called narrative fallacy.

    Keep up the good work!

  2. Thanks Sajjad bhai for your nice inspiring comment. Actually, this is a common scenario that i've faced many times in my short career. Programmers many times try to say that users will not think in your way and there are lots of things to do that is worthy than this checking. But, it is we who have to have strong points to make them believe that this insignificant things can have significances in many scenarios that often the users can experience.
    Few days ago, i found a bug which creates a system to crash when a zip file of 25 mb size has been uploaded instead of an image. It is not a common scenario, but user can mistakenly do this stuff. So, we have to make sure that this small checking or testing must be incorporated while designing the input domain.

    Thanks again for your valuable comments, sajjad bhai. :)