What happened
Ariane 5 reused inertial reference platform software from Ariane 4. But the early flight path of Ariane 5 was different. It carried much higher horizontal velocity than its predecessor. That single difference in operating conditions set the failure in motion.
Those higher velocities produced an internal value called BH, or horizontal bias, that was far larger than anything Ariane 4 ever generated. When the system tried to convert that 64-bit floating-point value into a 16-bit signed integer, the number was too big to fit. The conversion overflowed.
The resulting exception was handled inappropriately and shut down the inertial navigation system. That was the component responsible for helping steer the rocket.
The most important QA detail is that the function that overflowed served no purpose after lift-off on Ariane 5. It was alignment code that Ariane 4 had needed, left running for roughly 40 seconds because of an old Ariane 4 requirement.
The code that destroyed a $370 million rocket was not doing useful work. It was dead code, kept alive because it had been trusted before and never re-examined against the new vehicle it was now flying on.
The damage
The rocket disintegrated and self-destructed less than a minute into flight. The vehicle and its payload, four European Space Agency research satellites, were lost.
The direct loss was more than $370 million, but the damage went beyond hardware. The failure delayed the Ariane 5 program, damaged confidence in the launch system, and became one of the most cited software failures in engineering history.
The lasting cost was not only financial. It was the lesson the industry had to relearn publicly: "it worked on the last system" is not evidence that it works on this one.
How QA would have prevented this
This failure was preventable because every guardrail it needed is standard QA practice.
First, reused code should have been tested against the new operating context. A module's track record on Ariane 4 proved only that it worked under Ariane 4 conditions. Ariane 5 had a different flight profile, which meant the inherited software needed to be treated as unproven until tested against that new profile.
Second, the system needed boundary value testing around the type conversion. The bug was a value that did not fit into a 16-bit integer. Boundary testing exists specifically to push values to and past their limits. A boundary test on that conversion could have found the overflow before launch.
Third, the real Ariane 5 operating profile needed to be simulated. The higher horizontal velocity was knowable before launch. A simulation using the actual Ariane 5 trajectory would have produced the oversized BH value on the ground, in a test, instead of in the air.
Fourth, dead code should have been removed or guarded. Code that no longer serves a purpose is not neutral. It is still live surface area for failure. If a path is not needed, it should be removed. If it must remain, it should not be able to take down the system when it fails.
Your product does not need to launch rockets for this pattern to matter. Every shared library, copied module, third-party SDK, and "we already have a function for that" can become trusted code running in a context it was never tested against.
Before you ship, the components worth re-validating are the borrowed ones: the auth library copied from another project, the payment logic shared between services, the migration script everyone trusts because it has worked before, and the utility that nobody questions anymore.
A focused QA pass checks the dangerous edges, validates reused code in its new context, and surfaces failure before your customers do.