Customers have high expectations that their software solutions have been stress-tested thoroughly in advance for every conceivable combination of events that might occur in production and that vendors who put out buggy products are exposed quickly.

Unfortunately, inadequate infrastructure for software testing is said to cost approximately $59.5 billion annually, according to a 2002 study, "The Economic Impacts of Inadequate Infrastructure for Software Testing," conducted by the National Institute of Standards and Technology. This cost reflects, in part, the extra resources expended, due to inadequate testing tools and methods, to spot and correct errors found in the testing process. This figure represents the long and arduous road developers must travel to provide products that meet the expectations of their customers.

Because of the varied and disparate nature of Linux, the software testing process in the Linux environment is inherently complicated. In fact, it is a practical nightmare for most development teams, a time- and labor-intensive endeavor requiring manual installation of many Linux distributions and combinations on limited physical resources. Easily avoidable code problems and other potential issues are often missed simply because time and budget limits preclude the proper testing of every possible variable.

Fujitsu Siemens Computers (FSC) has customers who demand the highest levels of software availability, reliability, and functionality, so exhaustive testing is critical.

"What we're primarily interested in during the testing process is our products' reaction to system failures," said Ron Sheen, vice president, engineering at the American subsidiary of Fujitsu Siemens Computers. "So we induce different types of errors into the environment, causing communications failures, power failures, systems panics, you name it. And our software reacts to those events and keeps the service functioning. We do many thousands of test cycles and induce every known cause of system failure before our customers ever see the products."

However, consider the challenges of the testing environment:

• FSC Dynamic Data Center products support the enterprise versions of Red Hat and SUSE Linux distributions, meaning that developers must test all known variations of Red Hat Enterprise Linux 3 and 4 as well as SUSE Linux Enterprise Server 8 and 10.
• FSC must account for variations between even the minor releases by testing a broad array of different Linux OS release levels against all of their software for every patch and release that go out.
• FSC products must support many different platforms, which means dealing with both different Linux releases and their underlying architecture - Intel 32 bit, EM 64 T, or IA 64.
• FSC products must also support and be tested against old versions of Linux, as customers are often conservative about updating their own Linux environment.

Previously, given these circumstances, investing huge amounts of time, manpower, physical space, and money used to be a necessary testing evil for Fujitsu Siemens engineers. They would have to manually set up multiple boot discs, and then take time and energy to manually change the discs and the images being booted. In addition to being a major time drain while requiring a high degree of precision, the contents of the root disc would slowly erode from the continuous installation and removal of different patches. In fact, after only a few months of testing, the whole system would require expensive reinstallation because so many things on it had changed.

Needless to say, FSC began looking for ways to automate their manual testing process to save time, energy, and money.

Earlier in 2006, FSC engineers brought Levanta's Intrepid M management appliance into their Linux platform test environment. FSC developers stored common Linux distributions in the repository of the Intrepid M, a step that saved time in testing different Linux variations. In addition, the developers could rapidly bind and unbind the software stacks to the hardware and use of the portability of Linux images to conduct software tests on a fewer number of Linux systems - they tested 30 different Linux templates on only 15 machines.

In addition, they were able to avoid manually changing the images on the boot discs by utilizing the Intrepid M's checkpoint feature. FSC developers viewed changes that had occurred on any Linux server at any time. Each time a change was made in the file system, the developers viewed a snapshot of the image taken by the Intrepid and could see the change that had been made and "roll back" to any previous state to continue testing without worrying about the erosion of the state of the operating system.

By finding a way to mechanize these previously time-consuming processes, what used to take them a week now took only two days.

It's obvious that software problems are much less expensive, time-consuming, and aggravating when identified and corrected during testing rather than in post-production. Finding a way to address and automate as many of the minute difficulties associated with Linux software testing as possible will turn a necessary but time-consuming and arduous feat into a smaller and more manageable process. An ounce of prevention is worth a pound of cure.