How Healthcare.gov changed the conversation about software testing

The website problems that plagued the rollout of Obamacare shone an important light on software testing.

By Lorinda Brandon, Quality Evangelist

Image Alt Text

Credit: REUTERS/Jonathan Ernst

If you're anything like me, you've spent the majority of your adult life having your family members describe your career as "something in software." I've shaken many a hand, with a plastic smile on my face, nodding politely after my relatives say, "This is Lorinda. She does something in software." And that's OK – despite the fact that we are surrounded by software and professionals who build it, the reality of how it gets built is still a mystery to most people.

Some concepts are easier for people to get – when I was a program manager, it seemed to make sense to non-techies because there are program managers in just about every industry. And I suppose if I were a developer, it would make sense to people too (in some vague nerdy way, based on what they’ve heard about basement-dwelling Red Bull addicts).

But when I tell them I am a software tester or manage a testing team, I can see them trying to translate what they know of testing (banging car doors or putting test tubes in a centrifuge) to software. Imagine then trying to explain that I used to do those things and now I am a Software Quality Evangelist… ah, the blank stares.

Well, until recently. While several “software glitches” have been featured on the evening news, I can’t recall any that have caused a national conversation about the process of building and testing software until the Healthcare.gov debacle. Suddenly, Americans are sitting at their kitchen tables – in suburbs, in cities, on farms – and talking about quality issues with a website and who might be at fault.

The average American was given nightly tutorials on load testing and performance bottlenecks when the site first launched, then crumbled moments later. We talked about whether the requirements were well-defined and the project schedule reasonably laid out; we talked about who owns the decision to launch and whether they were keeping appropriate track of milestones and iterations. After that came the public discussions about security holes, which is not an unfamiliar concept to most people. But with those discussions came a healthy dose of encrypted passwords, third-party information sharing, and authentication protocols. School children and grandparents alike are worried about whether their passwords are being passed in the clear now. Imagine. There was even a major congressional hearing about the site, much of which focused on whether it was tested well enough.

It got really interesting when the media went from talking about the issues in the website to the process used to build the website. This is when software testers stepped out of the cube farm behind the coffee station and into the public limelight. Who were these people – and were they incompetent or mistreated? Did the project leaders not allocate enough time for testing? Did they allocate time for testing but not time to react to the testing outcome? Did the testers run inadequate tests? Were there not enough testers? Did they not speak up about the issues? If they did, were they not forceful enough?

Then there was the grassroots movement – testers and developers around the country performing their own tests and doing their own code reviews and releasing fixes after the code was released to GitHub. Testers like Ben Simo got their 15 minutes of fame because they devoted their own personal time to testing the site and blogged about the issues they found. Now the average Americans not only learned what we do for a living but what we’re made of – this is not a 9-to-5 job. This is a lifestyle; this is a belief system; this is just how we tick.

And, while tempers flared and accusations were flung about, I couldn't help sitting off to the side and gloating a little, because finally my family understands what I have spent my career doing and maybe so do the people they introduce me to.

---

About Lorinda

For almost 30 years, Lorinda Brandon has worked in various management roles in the high-tech industry, including customer service, quality assurance and engineering. She has worked at some of the leading companies in the industry, including SmartBear, RR Donnelley, EMC, Kayak Software, Exit41 and Intuit, among others. She specializes in rejuvenating product management, quality assurance and engineering teams by re-organizing and expanding staff and refining processes used within organizations. Follow her on Twitter @lindybrandon.

Copyright © 2013 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022