The last mile for any project is the shortest, but it can also be the most difficult to execute. Delivering digital capabilities to policyholders or testing major software applications seem like they should be easy, but these are the places where many organizations get caught flat-footed. At best, this leads to embarrassment; in other instances, it can be much worse.
Software Testing Failures: The Gift That Keeps on Giving
This week, Boeing gave an example of just how wrong things can go when software testing procedures do not receive a vigorous review for applicability in real-world usage. This isn’t another story from the unfolding debacle of the 737 aircraft; this relates to its Starliner spacecraft.
The company now admits that a recent, failed mission was a direct consequence of errors in the software it uses to manage the spacecraft, including a failure to test normal operation activities. Boeing stopped one testing procedure early, which led it to miss a significant problem with the onboard software. “Tolerance stacking” in the testing procedure also contributed to the failure.
The hardware necessary to perform the full testing regimen was not available, so the company substituted it with an emulator. However, the emulator did not act as precisely as the real hardware, which introduced a compounding effect that reverberated through testing procedures. No one was injured as a result of these errors, but a company that was already taking reputational hits for its practices did not need to add to its collection of woes.
Applicability to Insurance IT: Avoiding Others’ Mistakes
Boeing’s failure serves as an object lesson for insurance IT organizations. The pressure to deliver new products and services to market has never been higher. Agile development processes help organizations to move more quickly, but they don’t eliminate the need for thoughtful pragmatism when developing testing regimens. There is little worse than putting an organization’s reputation at risk by deciding to test software in production.
Ironically, many organizations note that cost pressures and the need to move quickly are rationales for shortcutting appropriate quality assurance processes. Of course, they always have the time and the money to fix things that have gone sideways in production.
The challenges for insurers are likely to increase. More insurers are delivering capabilities as a combination of services that strategic partners provide. This tactic can expedite delivery, but it can also fundamentally change how companies think about bringing capabilities to market.
Building quality into development efforts requires careful planning and “looking to the left” in the software development process, regardless of methodology. Some of the best lessons any organization can learn are found by understanding the breakdowns that have affected others. If it looks like the stove is hot, is there a need to touch it to prove the point?
Add new comment