Personal Blog (scroll down)
Are, Testing Departments for Losers?
Are, Testing Departments for Losers?

Are, Testing Departments for Losers?

Earlier today I came across a discussion surrounding a recent article, “Testing Departments are for Losers.”  TDafL is well-written with some new things I had not seen before.

Its core premise suggests that QA (Quality Assurance), post-development testing, efforts are not necessary.  Perhaps even a waste of resource and unneeded overhead.  I would be very curious as to your own thoughts.

After more than 20 years in the software industry, here were some of my own thoughts…

“Developers are the ones who inject defects into the code and therefore they are the best line of defense to remove them.

I would agree they are the best source for removing defects; after all, they know their own work.  However not all ‘defects’ are actually defects—the result of poor workmanship. Some are functional gaps, or oversights, where code works as intended (per the specification they work to meet), but the definition may have been lacking, missing insight, or errors in applied logic.

“QA is about positive assurance, which is stating,  “We are certain that there are few, if any, defects in this product.”

Well, perhaps.  It is also to prevent surprises and embarrassment.  Why? Because for most in the software industry, there -is- a point where pursuing perfection carries too high a cost.  Pursuing perfection becomes economically untenable the more sophisticated the deliverable.

Every piece of software I have ever been involved with has been knowingly shipped with imperfections (I hear the whispers already).  A QA or Test Engineering team helps the organization mitigate risk by qualifying, and quantifying, what the known defects and their related risks may be.

“Contrast…what would happen if Microsoft made airplanes…”

There is a slight difference between a software company (i.e. Microsoft) and an aircraft manufacturer.  One operates under the knowledge that, if their product isn’t the best it can be, people will die.  For the most part, certainly in my experience, that doesn’t apply in the software world (discounting embedded software, such as within the aircraft itself).

jtpedersen_321-Ignite_Software Development_Testing_QA_Words 220It is also why, with a past product serving the healthcare industry, we did not pursue services that could be used in an operating room.  We were not prepared, on many fronts, to take on that level of expectation.

While many, many aspects of the article are correct, there is one aspect I found missing.  There is a limit as to how effectively a team can check it’s own work.  You need to have an independent party validate workmanship.

There are at least two basic reasons.  As noted previously, developers are working to spec and do not always catch omissions.  Theirs is a balance between doing the job, to work to spec while keeping eyes open, yet not introducing scope creep themselves.

Second, they’re too close to their own work.  We have all looked at something we have written, perhaps a dozen times literally, yet missed the tipo [sic] staring us in the face until someone else pointed it out.

There is a kicker, too.  Let me introduce one other thought as regards ‘QA.’ Quite often QA teams also include domain experts.  These experts help introduce real-world testing to the arena; and, we all know we can never have enough real-world testing.

jtpedersen_321-Ignite_Software Development_Testing_QualitySo, what are your thoughts?  Are post-development (but pre-release) QA/testing efforts a waste?  Too much overhead?

Image credits:
Word scrambles – Wordle
Quality – Craig Parylo


  1. Hi JT,

    You have definitely put the “321-Ignite” on this topic. After setting up and running SQA for 6 years at a top 10 software company on the number one design software solution…, I have thought about what is different today, over back then.

    The concept and focus of Testing, for software, I think has evolved from a waterfall process step to stamp out defects after a build, and before a release, to one of ongoing process. Several things have changed.

    1. SaaS/PaaS and the cloud enables continual release cycles, so fixes and enhancements can be pushed out anytime.
    2. Agile methods have enabled more collaborative discussions between testers, users, and domain experts on 2 week cycles much earlier in the process, so big systemic changes at the end become less likely.
    3. “Lead User” approaches to design enable design issues from domain experts – in the customer base – to get the product right sooner.

    In general software development environments, technology architectures, and collaborative processes have changed the focus of SQA to one of managing the process more, and ensuring the right changes and adjustments get made before they turn into defects.

    I still believe that there are defects, and there is need for testing, but the process of throwing software “over the wall” to SQA, and then spending months fixing bugs has gone away, in successful organizations.

    Great post!


    1. JT

      Hello Andrew,

      You are correct suggesting this is a hot topic for many.  And, yes, today’s world of software development has continued to evolve. Cloud-delivered solutions have been the chief drivers in my view.

      As a SaaS product manager, I really liked the ease and frequency with which you could roll out product changes.  A big positive compared to more-traditional shrink-wrapped boxed product offerings.

      To clarify, I definitely agree with you that the days of throwing code over the wall to QA are over.  Certainly, they need to be.  As with Agile’s approach toward embedding testing in the entire development cycle, I believe testing needs to be an integral part of the entire product development life cycle.

      My core message is, there remains value having a team—independent of Development—involved in validating the product’s quality.  Processes continue evolve that let us deliver ever-better ‘first draft’ product.  But we’re all still human and having us check out own work 100% of the time is not a good idea.

      What do you think?

      And, thanks for commenting,


Comments are closed.

%d bloggers like this: