The Testing Elephant in the Room


Even thought it is 2014 and the IT/programming industry has been creating software for over 40 years, testing is still “an elephant in the room”…let’s pause there for a second to let that sink in – software has been developed for over 40 years (since at least the 1970’s…even longer)…software development processes have existed for a long, long time.  However, even some basic parts of the process are still not “burned into” every IT professional’s brain.  Don’ t believe me?  Let’s take a look at some recent examples…

Even though it’s “shootin’ fish in a barrel”, I have to call out (but don’t worry, I’ll go beyond that).  Regardless of your politics around the ACA or ObamaCare, everyone – or at least IT professionals – should be horrified at headlines like this: “Team Obama Never Finished Testing Before Launching It”. Really???  In 2013, how can any major web app be created and be accused of this?  Regardless of all the issues with, it’s clear that major fundamentals were not there…including testing. Its been said that followed an agile methodology.  I disagree with the poster that it failed in spite of agile methodology.  I counter that IF they really followed agile methodology, issues would have surfaced and resolved (by the team) long before it spiraled out of control.  Clearly, that can’t be as releases and testing would have been available long before Oct 1.

Now a knee-jerk response might be that this was an isolated case.  Unfortunately, it’s not.  Let’s look at just a couple other recent articles.  First, Nevada’s health insurance exchange also had major problems in various areas and it’s just inconceivable to me that reports were talking about testing as a normal thing at the END of September before an Oct 1 go-live.  Really? (again) In what universe is an end of September UAT phase a good plan?  At the very least, basic functions should have been fully tested and certified 6 months prior.

To show that this is also not an isolated case, let’s look at the Minnesota health information exchange. I think it’s a spectacular example of a fundamental mind-set flaw minimizing the testing process and overall value of testing.  A couple of my favorite quotes are “MNsure officials might have known about many of these problems if they had tested the site with consumers prior to Oct. 1” and also …Testing “is one of those things that’s so foundational, it doesn’t even deserve a ‘Why?'” said Krigsman, who specializes in preventing IT projects from failing. “It’s like, ‘Why do we need to breathe the air?'”. As my son says, “Wow…just Wow…”

Ok, so now you might argue that a lack of a “testing mindset” is inherent in those who are less current in their development thinking.  However, let me point to a December post about even agile developers feeling so much pressure that they don’t think they have time for testing.  All these things convince me that testing just doesn’t yet have it’s rightful place in common development process.  Of course, there are many instances where things are working well.  However, it is way to easy to find examples where testing just isn’t valued….and I’m sure that all of you can post past experiences that validate this, right?

So this is a call to action.  When I create development plans, I pad more time for testing and issue resolution that people expect.  It’s always good and an easy conversation if you don’t need that extra time.  However, I always carve out more time because we usually need it.  Another way to break the current mindset minimizing testing is to talk openly about not “if” you find bugs; but rather, strategize about the possibility of big bugs.  By going far to “the other side”, people intuitively are more conscious about finding problems and will work extra hard to avoid it.  In some projects, we focused so much on the possibility of major problems that they never came up.  What are your strategies for giving testing it’s rightful place and helping educate business and executives about the importance of appropriate and frequent testing?

Business Cliche of the Day (Followed by It’s Real Meaning): We need to do some blocking and tackling – “We really screwed up the fundamentals”


Veteran technology professional and manager

Posted in programming, work habits
One comment on “The Testing Elephant in the Room
  1. […] run into without much experience using Application Lifecycle Management (ALM) tools.  Along with testing, it seems all too often that the “stuff” that goes around the actual programming gets […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: