Whence QA?

By Avi Deitcher

Since the dawn of software, more or less, companies wrote their software in a process that went something like this:

  1. Product defines the specifications.
  2. Architecture designs it.
  3. Engineering/R&D builds it.
  4. Quality Assurance (QA) tests it.
  5. If it passes, it is scheduled for release; if not, goto #3.

The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "Quality Gates"?) to validate the software's functionality and performance in every scenario that the firm could foresee, or at least those that mattered.

Just as sales teams tend to be divided into hunters (people who are really good at getting in the door for new deals) and gatherers (those who are better at supporting existing customers and getting them to purchase additional services), so technologists tend to be divided between those who are good at building new things, and those who are good at detailed processes.

In the more recent DevOps world, the person who built the software is responsible for managing the software. They are the very ones who have the ability to "push the button" and deploy to production. This theory has three justifications:

  1. Reducing steps and processes means faster iterations.
  2. Errors that occur closer to development can get fixed faster and with much lower cost.
  3. If the person who built it is the same one to get that 2am wake-up call when it doesn't work, that person will make really sure that it just works.

IEEE Spectrum, the magazine of IEEE (originally, "the Institute for Electrical and Electronics Engineers"), had an article a few weeks ago, looking at what happened at Yahoo when they removed QA entirely.

It seems a bit odd to choose Yahoo, a company clearly in strategic trouble, as an example. On the other hand it often is those firms at serious risk who are willing to take bolder risks. Yahoo is not going to pull back from the brink by doing business-as-usual or delivering more slowly. Additionally, there (still) are some great technologists working there, so the patient hardly is comatose.

The article concludes that it is a great idea. Not only do things move faster, but you get fewer errors. This may seem counterintuitive, but it actually builds upon human nature. It isn't just the "I had better make it work if I do not want to be woken at 2am." There is a deeper issue at play than self-interest.

When you build something, but someone else is responsible for making sure it works, you (sub)consciously contract it out. Your sense of ownership and responsibility for the quality of the product is reduced. Conversely, when you own all of it, there is no one else, no "safety net", and you cause yourself to deliver higher quality.

I have written before about my experiences with testing and QA. If you want fast and accurate quality software, the engineer must be able to run the full gamut of tests with minimal effort and no outside help. Give him or her the power and responsibility to do so, and amazing things happen. Quality goes up, time to deliver goes down.

When I showed this article to an executive colleague of mine, he countered with an article in Medium by Steven Sinofsky, of Andreessen Horowitz (a16z). Towards the end of the article, Steven bemoans the shoddy quality of product over the last year by even the largest companies.

Actually, I think that Steven's and my views lines up perfectly. Steven is not bemoaning the lack of QA teams; I am sure that if you check every single company that had a quality failure in 2015, you will find testing and QA/QE/QC teams. Steven is bemoaning the lack of quality. He wants companies to devote more resources to "making sure it works", not just "making sure it has the feature."

How you get to that quality is an entirely different question. Everyone agrees that it is proper testing. Should that testing be a QA team? The actual engineers? Or someone else?

Summary

Especially in a software world, QA teams for testing software are an anachronism that slow down delivery and reduce quality. Unless the process you are testing is manual and cannot be automated - and those are few and far between - get the additional layer of people out of the process, and give full quality ownership to people building the product.

You will get better quality product faster. Isn't that what we all want?

Are you moving as quickly as you can? Ask us.