Dont Put Up With Costly Software Bugs

By

Carriers count on technology to accelerate their ability to quickly meet evolving customer expectations, address changing regulations and work through mergers and acquisitions. Clearly, speed is a good thingexcept when it comes at the expense of system quality.

In the world of information technology, poor quality often means the presence of software bugs that occur when carriers update existing systems, develop custom applications or add new software packages. And as recently reported by National Underwrite, software bugs are a multibillion-dollar problem.

So why all the bugs?

The answer lies in the way many carriers approach software testing, which is the cornerstone of the software development process. In the rush to quickly deliver results to business users, the tendency is to delay testing until the very end of a project. The result is often buggy software that causes significant problems. Testing to avoid such problems can be relatively inexpensive and painless. Heres how:

Testing earlier.

First, its important to know that carriers will do well to move testing up in the process when working with existing or new software. Testing should also be top of mind for everyone involved.

On software projects today, many carriers follow a process that involves a series of long steps associated with the traditional software development cycle. The cycle includes analysis, design, implementation, testing and production. As such, thorough testing isnt performed until late stages of the process.

The problem is that the cost of finding and fixing bugs increases exponentially the farther downstream theyre detected. Thats because it takes an incredible amount of time and effort to find and fix bugs late in the cycle.

An approach that works well is to have business analysts work with the quality assurance group to write test scripts, which are then given to developers at the same time the developers are given requirements. The same test script is also used later for user acceptance testing. This allows developers to write code that conforms to both the requirements and business functionality tests.

Another technique is test-first coding. Developers write test scripts for the code theyre writing, or changing, before they actually write code. As such, code passes muster at the very beginning of the cycle.

Test-first development means each developer has a failing test prior to writing their first line of code. Developers know theyre finished when the test passes. Once it does, an analyst sits with the developer to confirm that the feature meets the requirements. Only then is that particular code added to the mix.

Automate, automate, automate.

Making it easy to perform tests immediately after changes of any kind are made to new or existing software is also important. The best, most cost-effective way to do so is through automated testing.

This means eliminating or reducing the manual, time-consuming task of executing test cases every time theres a software change. Instead, the idea is to develop a framework, or set of mechanisms, that automatically tests work performed.

The framework is built using suites of test cases written by developers and business analysts that have gone before. The suite grows and matures as requirements are changed or added.

A variety of automated testing tools are also available. Many are open-source, which means you can get them for little or no cost.

Whatever the mechanism, a great deal of time and effort is saved. Automated testing is most effective when integrated with the software build cycle.

Change management.

Youve moved testing up in the cycle and automated it wherever possible. The next step is to manage it. For thats theres a proven and widely accepted technique called continuous integration (CI).

CI allows developers to increase the reliability of their work. With CI, development, integration and testing are done continuously (in contrast to testing that is done daily, weekly, monthly, or not until the end of a project). The result is the ability to catch most bugs before they slip through to production.

CI is essentially a continuous workflow where every change or addition of software code results in a rebuild, retest and redeployment of the system. It can be used at project and enterprise levels. The key benefit is that CI produces better quality code and eliminates time spent chasing down bugs where one persons work has stepped on someone elses without either person realizing it. Thats important. Pesky bugs are often born out of the interaction between two or more pieces of work.

Bugs created by interaction between multiple developers tend to be exacerbated by time. Thats because bugs can be inserted weeks or months before they first manifest themselves. With CI, however, bugs manifest themselves at the time theyre introduced and can be detected and tracked much more easily.

The key to CI is to automate. And an automated CI process doesnt mean exorbitant costs, thanks to a variety of tools on the market (some of which are open-source). These tools automate the build process and integrate automated test suites. Software builds run every time a developer checks in code. Additionally, the full range of needed tests is executed automatically each time a build successfully completes. That means the process can be repeated a dozen or more times a day. Knowing the status of code at all times also allows the testing team to focus its efforts.

Suppose you wanted to update a policy system, which dictates the need to change 20 different products. The typical approach is to update each product one at a time and then manually test each before putting it into production.

Sounds good, right?

Sure, except this approach doesnt allow for testing all of the previous products. In other words, testing stops short, and thats not good when products come from the same code base (which is almost always the case).

People truncate the testing process because they believe its too time-consuming and costly. The theory is that it takes too much work to manually re-test Product A to determine whether it works flawlessly when changes to Product B are made, and to test Products A and B to determine whether they still work when changes are made to Product C, and so on.

However, thorough testing and re-testing can be done at a fraction of the cost by using a combination of CI and automated testing. The reason is that it minimizes time spent writing initial test cases. Automated testing takes care of the rest. It also eliminates the need to look for bugs in all 20 products should an error be found upon system deployment.

By testing early in the software development cycle, automating where possible, and implementing practices like CI and test-first development, carriers can drastically reduce the high costs of tracking and fixing bugs. They can also consistently deploy dependable, high-value IT systems.

And remember, these practices are proven effective. Theyre also relatively easy and inexpensive to introduce into an organization. We recommend experimenting with one or more of these on a project of manageable size. Youll be glad you did.

Bob Hunter is director of insurance and financial services practice, and Tom Boscher is a project manager for ThoughtWorks based in Chicago.


Reproduced from National Underwriter Edition, May 19, 2003. Copyright 2003 by The National Underwriter Company in the serial publication. All rights reserved. Copyright in this article as an independent work may be held by the author.