Welcome!

Java Authors: Sharon Barkai, Elizabeth White, Liz McMillan, Pat Romanski, Kevin Benedict

Related Topics: Java

Java: Article

Software Testing Shouldn't Be Rocket Science

Software Testing Shouldn't Be Rocket Science

Earthdate: October 15, 1997, and the Cassini spacecraft is launched. Mission: to boldly go and explore the planet Saturn.

Saturn is about 10 times farther away from the Sun than the Earth, and to get there required two orbits of the inner solar system, receiving gravitational kicks from Venus and Earth before doing a flyby of Jupiter to get a final assist toward Saturn.

Piggy-backed to Cassini was the Huygens probe that would be dropped onto Saturn's moon, Titan. Unlike most other moons in the solar system that are barren, cratered rocky places, Titan has an atmosphere covering it. The purpose of the probe was to parachute through this, capturing data as it descended onto the planet's surface. The data would be transmitted from the probe up to the Cassini craft, which would act as a relay and transmit back to earth where the experiments' results would be analyzed.

On January 14, 2005, Huygens successfully landed on Titan's surface and provided some fantastic pictures of the moon (www.esa.int/SPECIALS/Cassini-Huygens/index.html). Despite this, there were two major problems on the mission.

The first is that one of the radio channels that the Huygens craft was going to use to transmit data to Cassini failed. The remaining channel was used successfully, although due to this problem only half of Huygen's pictures have come back and some experiments have had all their data lost. The reason for the problem is described as a "software commanding error." The reality is the receiver on Cassini was never programmed to switch on.

The second problem is related to the premise that Huygens transmits its collected data to the Cassini orbiter, which then relays it back to earth. Three years after the launch one of the space agency's employees became uneasy about the fact that this feature hadn't been tested enough in realistic conditions. The story is described in detail at www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004titan.html and provides a sobering lesson in the importance of testing. This employee worked hard to convince colleagues and superiors of the importance of testing the link in real conditions, so a simulation was done by sending data from earth to Cassini mid-mission while it hurtled toward Saturn. This mimicked the separation conditions that would be encountered between the craft and Titan and the raw data sent was echoed back to earth by Cassini and analyzed. It showed a fundamental flaw.

Because of the difference in the relative speeds at which Cassini was traveling in space relative to Huygens, there was a Doppler shift. A Doppler shift is when waves are effectively compressed if the receiver and source are moving toward each other and expanded if moving apart. As the wavelength decreases, the frequency increases, meaning that Cassini would have to adjust its listening frequencies to account for its velocity relative to the Huygens transmitter. In addition, the decoding would be affected. Digital data is split into ones and zeros and compared against a base signal to decipher; however, the Doppler shift would stretch and compress the lengths of the payload actual bits in the wave, meaning the digital signal couldn't be analyzed correctly. A fix was required to rescue the $3.26 billion project.

Despite the fact that Cassini's hardware allows its receiver to receive over a range of shifted frequencies, the firmware program was unable to be modified after launch, even though a small fix would have sufficed. The solution they used was to alter the trajectory of Cassini's orbits of Titan so that the craft's approach allowed the radio transmissions to travel perpendicular to its direction of motion, thereby reducing the Doppler shift.

The cost of the two Cassini bugs is huge. Coming down to earth it provokes questions about testing in general. A trait I've encountered at times in my career is for a program to be released knowing it is flawed because the programmer hopes to release the working version in a subsequent fixpack, hopefully before the user has encountered the errant feature. Upgrading releases is easy for developers, but for a user who has to migrate data and schedule business downtime it's frustrating and must contribute to the perception that the latest release is not a set of fully baked features but a rollup of the previous version's fixes bundled with new features that perpetually introduce their own set of bugs.

Good testing is about attitude, where a developer takes pride not just in the elegance or volume of his or her code, but in whether it meets the user's requirements and performs reliably in its first incarnation. I once heard a developer say that releasing buggy code was part of agile programming to allow you to have more cycles of code/release//fix/code. Apart from not grasping the methodology maturely, it showed a basic lack of pride in their work that they were trying to justify. The same excuses can also lead to bloatware, where code is thrown upon code without any tight design or following the basic principles of software engineering. Is the problem that some developers are incapable of taking pride in the complete quality of their work, or that education and teaching, or marketing pressures in a commercial environment still mean that buggy software is released. Next time you release code without proper testing, keep in mind the Cassini programmers who had to physically alter their craft's passage to find a solution. While we might have the next fixpack or release available to us, in space no one can hear your excuses.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
David Armstrong 02/10/05 12:52:51 AM EST

Re: Good testing is about attitude, where a developer takes pride not just in the elegance or volume of his or her code, but in whether it meets the user's requirements and performs reliably in its first incarnation.

That's true, but it's also a question of time and cost. Most programmers do take pride in their work and their biggest thrill is reliable and functional software. Unfortunately this is often tempered by cost and time restraints that are set by real-world budgets. Testing takes time and the more complicated a project is, the more time it takes.