Dont Put Up With Costly Software Bugs
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:
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.