Why Obama Administration Should Have Paid More Attention to Load Testing

October 1, 2013, was the most anticipated date for the Obama administration since his re-election. It was to be the day every American would have access to health care on one centralized website. However, according to at least one report only six people enrolled in Obamacare on the first day. Then shortly after, the entire website crashed along with its infrastructure.

The massive crash happened because within the first 10 days of launch HealthCare.gov had over 14.6 million unique views. Something the Obama administration was not prepared for, nor the testers.

The website should have been able to handle tens of thousands of people at once, but in a trial test before the launch a mere 500 users caused the website to crash. In testimony before U.S. Congress, the contractors responsible for HealthCare.gov said they didn't have enough time to fully test the website. The inability to properly load test the website well before the launch date of October 1st led to one of the worst federal website debacles of all time.

What Went Wrong The HealthCare.gov website was designed to provide Americans with a simple solution as a one-stop-shop for health care insurance, but as we all know it wasn't that simple.

The site was built by 55 contractors and is considered one of the most complex software projects ever undertaken for the federal government, which might be where their problems all started.

According to Louis Woodhill, a contributor to Forbes magazine, the Obamacare website is comparable to the Soviet Union. "In their effort to build an IT system to implement Obamacare, the U.S Department of Health and Human Services was trying to do the same thing as the USSR's Gosplan agency: elicit coordinated, purposeful action from a collection of entities that don't know each other, don't trust each other, have conflicting objectives, and face diverging incentives."

Mixing contractors wasn't their only issue, the Obama administration continued to make a series of rookie mistakes that led to the demise of the website.

Incorrectly Assessing User Behavior. First, the administrators in charge of the website decided in late September to exclude the feature that would let people shop for health plans before registering for an online account. This lead to a bottleneck in the process because more people than expected had to go through the registration process before they could even browse through plans.

Broken Systems Integration. Second, the registration process was flawed. The consumer was supposed to enter basic account information, a security question and so on, but the communication between the systems responsible for storing this information wasn't working properly. This resulted in thousands of users who were unable to successfully create an account.

Rebuilding Components from Scratch When Proven Systems Were Available. Last, the Data Services Hub, which is a proven identity service available to the government for consumer applications, was surprisingly not used to its full extent. Instead, the website builders created new software systems meant to do exactly the same thing. In an article by Mashable the author emphasizes the fact that if the HealthCare.gov site had in fact fully leveraged the Data Hub, then it wouldn't have been such a mess.

With all of these missteps and rookie mistakes under consideration, what is known is the fact that HealthCare.gov was overwhelmed with the amount of visitors to one site.

Why the Government Should Have Made Load Testing a Priority It seems like those responsible for deploying the site didn't really appreciate the importance of load testing, which is especially surprising when you consider that the website had in fact failed a pre-launch load test miserably. Of course, politics came into play as the deadline for the website was non-negotiable. But with all the red flags warning of failure, load testing should have played a much more critical role and here's why:

Prioritization of Problems and FixesA big issue with HealthCare.gov was that the contractors claimed they didn't have enough time and felt extreme pressure to roll out the website before it was properly tested. If load testing occurred earlier in the website development phase, testers would have been able to identify the parts of the website that were not working properly.

The major pain point in the entire HealthCare.gov website was the registration process that millions of Americans attempted to fill out. Had they load tested the website months out from the launch, the team would have been able to identify the root causes of performance issues and determine whether they were in application code or the app servers and infrastructure components.

Earlier Identification of Issues

This chart illustrates how much it costs the paying client to fix a bug according to the stage of development. At the operation stage, a bug can cost clients more than 150 times as much as a bug caught in the requirement stage.

Had the testers broken down their tests into smaller test cases, over time the administration might have taken the time to listen and understand that these little bugs needed to be fixed prior to the public launch.

Decisions Made from Intelligence on the Ground We know the tension between testers and business owners can be pretty intense. The funders of the website want it up and running right away, but testers want to properly identify errors and have enough time to fix the issues that arise.

The only way to increase the scope of a project without changing the due date would be to add more resources. Since the administration was rigid on all three sides of the triangle, the quality of the website suffered.

It's no wonder this website failed. The dynamics between the testers and heads of HealthCare.gov were strained, and it appeared the Obama administration chose to ignore testers who knew the website was not ready.

HealthCare.gov Today The HealthCare.gov website isn't through the woods just yet. According to The Washington Post, the website has been flagged by over 22,000 people trying to correct errors the system made when they were signing up for a new federally-mandated health care plan.

Apparently, federal workers aren't able to access consumer data manually. "An unknown number of customers who are trying to get help through less formal means - by calling the health care marketplace directly - are told that HealthCare.gov's computer system isn't yet allowing federal workers to go into enrollment records and change them."

What needs to be understood here is that it's important to test early and often. If tests would have been conducted throughout the entire website development, the Obama administration would have avoided such an embarrassing and reputation-tarnishing event.

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

This topic is all about SOA Testing techniques used for testing IT assets that are part of a Service Oriented Architecture and a Cloud-based deployment. As SOA and Cloud computing begins to tie the fabric of IT infrastructure, actively and aggressively testing XML, REST, SOAP and Web Services has become crucial. Comprehensive Functional, Performance, Interoperability and Vulnerability Testing form the Pillars of SOA Testing. Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.

Cloud Expo

Cloud Computing & All That
It Touches In One Location Cloud Computing - Big Data - Internet of Things
SDDC - WebRTC - DevOps
Cloud computing is become a norm within enterprise IT.

The competition among public cloud providers is red hot, private cloud continues to grab increasing shares of IT budgets, and hybrid cloud strategies are beginning to conquer the enterprise IT world.

Big Data is driving dramatic leaps in resource requirements and capabilities, and now the Internet of Things promises an exponential leap in the size of the Internet and Worldwide Web.

The world of SDX now encompasses Software-Defined Data Centers (SDDCs) as the technology world prepares for the Zettabyte Age.

Add the key topics of WebRTC and DevOps into the mix, and you have three days of pure cloud computing that you simply cannot miss.

Delegates will leave Cloud Expo with dramatically increased understanding the entire scope of the entire cloud computing spectrum from storage to security.

Cloud Expo - the world's most established event - offers a vast selection of 130+ technical and strategic Industry Keynotes, General Sessions, Breakout Sessions, and signature Power Panels. The exhibition floor features 100+ exhibitors offering specific solutions and comprehensive strategies. The floor also features two Demo Theaters that give delegates the opportunity to get even closer to the technology they want to see and the people who offer it.

Attend Cloud Expo. Craft your own custom experience. Learn the latest from the world's best technologists. Find the vendors you want and put them to the test.