Obamacare – HealthCare.gov Debacle – What can testers learn from it…
While the world bid good bye to 2013 and we enter 2014 with a bang, I only hope that troubles for already troubled Obamacare website come to an end. For those who have buried 2013 in the history books, this is what transpired in the last quarter of last year.
- Oct 1st 2013 when ObamaCare with all the hype went live, thousands of West Virginians who thought they had signed up for Obamacare had to re-enroll because of glitches in the system. The problem-plagued ObamaCare website was only equipped to handle 1,100 users a day before it was launched
- Technology experts say this website did not go through proper security testing before it went live on October 1 – Dougall and his wife signed up on the website in October, but over the weekend got a disturbing call about a man in North Carolina who also registered, and was shocked to get the Dougalls’ eligibility letters, including their names and home address.
- It was found that the website had failed with a small test pool of 200 to 300 people that included employees from the government and insurance companies. The government employees worked at their own computers and desks within the Centers for Medicare and Medicaid Services (CMS), which oversaw the health care implementation.
- CMS employees were provided fake personal information to enter into HealthCare.gov rather than their own data and were given a date that testing would begin. However, on that date, the employees were told it was being postponed.
- Units of CGI Group Inc. (GIB/A) and UnitedHealth Group Inc., which designed healthcare.gov, said a branch of the U.S. Department of Health and Human Services was responsible for the end-to-end testing that they said should have been done months earlier.
- Cheryl Campbell, senior vice president of CGI, suggested in prepared testimony that Congress should look beyond the contractors. HHS “serves the important role of systems integrator or `quarterback’ on this project and is the ultimate responsible party for the end-to-end performance,” she said. Overwhelming interest from consumers triggered the website problems, she said. “No amount of testing within reasonable time limits can adequately replicate a live environment of this nature,” she said.
- Quality Software Services Inc., owned by UnitedHealth Group Inc. (UNH), helped design a system that created a “bottleneck” blocking a majority of users from signing up. Andy Slavitt, representing QSSI’s parent company (United Health Group), that was responsible for testing the website, said the operation’s virtual back room, known as the federal data hub, is working well despite some bugs. But his company was also involved with another part of the system, a component for registering individual consumer accounts that became an online bottleneck.
- Campbell said QSSI’s tool that allowed consumers to create secure accounts created a “bottleneck” in the system. Slavitt later said QSSI takes “accountability” for the problems with that function.
- Centers for Medicare and Medicaid Services, or CMS, decided to take control of the project, rather than signing it off to the IT contractor responsible for the site.
Enough of postmortem of this debacle has been done in the past and after all that slicing and dicing I think the launch of HealthCare.gov in the U.S could have been smooth if only the following points were taken care of.
There is no evidence that a comprehensive test strategy / test plan was in place for testing this site. If at all there was one and had the organizations involved (CGI, QSSI, CMS and HHS) followed it, the disaster and embarrassment could have been avoided.
Enough of System Integrating Testing
Too little of Integrating testing was done on Obamacare website – a complex system that was internally/externally integrated with many upstream and downstream systems. Ideally it takes months to test a complex website like Obamacare. However, last minute end-to-end testing was performed with no clear exit criteria. An SIT Test Plan with a proper test approach could have saved the day.
Too many cooks spoiled the broth?
There were multiple stakeholders involved in the testing and in the end too less testing was done. QSSI said they were not given enough time to test but they never raised an alarm about it. This also highlights the importance of risk management and highlighting risks on time. Others who were supposed to do end-to-end testing did not either press the panic button on time. Proper risk planning and mitigation would definitely have helped.
The author of this post is Founder and CEO of ImpactQA Services Private Ltd and the views are personal.
Share this post
Related Posts
Our Case Studies
