Could Better Testing Practices Have Prevented the Healthcare.gov Defects?
Whether you love the Affordable Healthcare Act or think it’s a sign of the Apocalypse, there’s one thing that’s certain – the Healthcare.gov website didn’t work as well as Washington would have hoped.
On Sunday, federal officials announced that the online marketplace needed design changes as well as more server capacity to improve the website performance. But subsequent announcements from the administration indicate that this is more than just a capacity and design issue – in fact, the issue may involve how the site was coded and how it was tested in pre-deployment.
Here’s the background -- on October 1, consumers were offered the opportunity to begin shopping for new insurance policies in the government’s online marketplace. Some states handled their online marketplaces themselves, but 36 states relied on the federal government for the creation, hosting and operation of their portals.
As of Friday, more than 9 million people had attempted to access Healthcare.gov in search of insurance coverage. Tens of thousands were able to start the application process, but due to software glitches, only a few thousand were able to successfully create accounts, and even fewer were able to select a policy.
Despite their best intentions, the administration (or at least it's Web development team) was clearly not prepared for the influx of traffic to the site. Due to load capacity issues, few people were able to even get through to the site, including customer service representatives on the government-run hotline.
In addition to these load issues, there were major code and design flaws in the system. Identity-confirmation and security questions are among the features that need the most attention, meaning even those who were able to successfully access the site, create accounts, and sign up for policies may not be able to keep them.
As if all this weren’t enough, the site has been functioning at this capacity for a week now. The federal government finally recognized publicly over the weekend that there were code, design and server capacity issues that needed to be addressed, but not before millions of people had negative experiences with the program.
In an interview with the Wall Street Journal, engineers at Media Temple said they found several fundamental errors in the website software. There were stray lines of code that didn’t seem to have a purpose, a lack of basic Web efficiency techniques, and a failure to ensure the site could handle the load. Addressing these issues ahead of time could have saved the government a week’s worth of distractions and possibly tens of millions of dollars.
Is it possible that the creators of the website didn’t do adequate functional and load testing necessary for a site of this magnitude? Possibly. Of course, there were probably constraints we’re not aware of, such as delays in approvals, delays in getting funding and any number of common maladies for a project of this nature. Even so, launching a site that isn’t functioning properly is a distraction the government didn’t necessarily need at this time.
The good news is that you probably don’t have the same constraints our friends in the government do. In other words, you can build software testing into your timeline so that your site is tested well in advance of deployment. Better still, you can use collaborative tools that allow multiple people from every one of your locations to make comments and suggestions that lead to a better site.
It’s unlikely that the developers and testers for the Healthcare.gov site were unaware of these kinds of tools. A more likely scenario is that they simply ran out of time and had to rush through the development and testing process in order to meet the deadlines. No matter what, many of the problems the site is running into were avoidable and, hopefully, are being fixed so that the site runs as smoothly as everyone would have hoped the first time around.