Are, Testing Departments for Losers?

Share this:

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