The maiden flight of the Ariane 5 rocket blew up 37 seconds after takeoff because a piece of code that was only used while the rocket was on the ground was left running for the first 40 seconds of flight. It tried to assign a 64-bit number representing the sideways velocity of the rocket into a 16-bit field which then convinced the rocket's navigation computer that it was going the wrong way! It tried to correct the course and the resulting sudden veering started tearing the booster rocket apart. While this is not quite an example of Test Logic in Production (page X) it certainly does illustrate the risks associated with it.
Could this disaster have been prevented by automated tests? While it is difficult to say with certainty, and one could certainly claim that any number of process changes could have detected this problem before it occurred, it is conceivable that automated tests could have prevented this problem.
First of all, a test should have existed for the boundary condition of what happens when the number exceeds the maximum storable. This would have prevented an exception from occurring for the first time ever in production.
The presence of the tests from previous Ariane 4 version of the rocket would have documented the maximum down-range velocity. It is quite possible that these tests would have been updated when the Ariane 5 software was being developed and that the new tests would have failed because of the higher speed of the new rocket.
For a more slightly more detailed (and very interesting) description of "the little bug that could", visit:
Copyright © 2003-2008 Gerard Meszaros all rights reserved