How Healthcare.gov Changed the Whole Software Testing Conversation
The website problems that plagued the rollout of Obamacare shoved the topic of software testing into the mainstream conversation.
If you're anything like me, you've spent most of your adult life having your family members describe your career as "something in software." I've been introduced to many people with a plastic smile on my face while my relatives say, "This is Lorinda. She does something in software." And that's fine – despite being surrounded by software and professionals who build it, the reality of how software is built is still a mystery to most people.
I've found that some concepts are easier for people to grasp: 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 (based on what they’ve heard about basement-dwelling Red Bull addicts).
But when I tell them I am a software tester or that I'm 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.
At least, 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 unti Healthcare.gov. Suddenly, Americans are sitting at their kitchen tables – in suburbs, in cities, on farms – and talking about quality issues with a website.
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, admittedly, 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 now worrying about whether their passwords are being passed in the clear now. Imagine that. There was even a major congressional hearing about the site, much of which focused on whether it was tested well enough.
When the media went from talking about the issues in the website to the process used to build the website was when things really got interesting. 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 perhaps also the people they introduce me to.
This post was originally published on Ole’s column
at Network World.