There's a general aura about testing in software development. The tests themselves can be arduous and painful. The people who create them can be stuffy and sometimes pompous. The results that they generate can be demeaning and bring you to your knees.
Very few software engineers would actually take bug fixing over being able to create new and exciting things. There's something to be said for the adrenaline that get's pumping as you are smashing keys to pump out something that no one has seen or done before... that moment when you throw your hands in the air and clench your jaw to hold back the "I'M A GENIUS" yell though the office. It's what we, as engineers, live for.
Testing forces you to put your arms down, tuck your tail between your legs, and, if you haven't bought on to TDD, start plunking out unit tests to prove you're a genius. Why should you have to prove it? It's right there in the code.
Then, if you're ever so unlucky, you've got to hand your code off to the tester who was just good enough to write code to cobble together some automated tests, but not as good as you, the almighty developer. At best you'll get a few bugs about a random race condition and at worse you'll get a handful of "bugs" which is really just the tester being an idiot.
I bet that's how some of the developers working on healthcare.gov thought.
If you've stayed on top of any of the news around the healthcare.gov failed launch, you'll see two reoccurring themes.
1. A lack of testing
2. Last minute design changes
There are a lot of moving pieces to this web app with multiple intregration points into a lot of archaic systems. No doubt thin access layers had to be built on top of these archaic systems to even get the site to be able to talk to them at all but then when you start trying to manipulate the data on those systems, you're just asking for trouble.
Of the two themes mentioned above, I'm a firm believer that last minute design changes should never be a reason for a lack of testing. Whenever you hear "we didn't get enough testing because of these last minute changes" it purely means that your testing strategy was flawed or non-existent to begin with. The private contractors knew what the overall goal of the site was supposed to be. A proper test strategy should have been agreed upon even before development work started. The governing body (HHS and CMS) who was overseeing this gargantuan effort should have been completely aware and comfortable on that strategy as viable and all inclusive to their goals.
When you have a well thought out test strategy, these "last minute design changes" become mere tweaks to the already implemented test strategy. Yes, there is some effort to tweak the strategy, but it certainly won't be to the level of avoiding testing all together.
I'm floored by the statements from the contractors that they started testing just days before the rollout and that "the HHS and CMS were responsible for end to end testing"
What?! Since when in the time of software development EVER has the client been responsible for end to end testing of the application YOU wrote? This is a clear sign that there was no test strategy created by the contractor... which is a clear oversight on their end. Unfortunately, instead of admitting that they botched testing from the start, they resorted to the blame game.
Would it have been different if the end to end test strategy was in place early? I'm convinced that October 1, 2013 would have been a much different launch date if it was. At least it could have handled more than 200 users.
I wrote my first web app as a 12 year old that handled more than 200 users.
