You’ll reap the benefit of dedicated QA sooner than you think

As with most things in life, if you don’t think you need role XYZ, you just haven’t seen greatness yet.

A (past) belief that I developed was that you DON’T need dedicated QA. That’s partly because I hadn’t seen greatness yet. I had only seen quality implemented poorly.

In my time at Angie’s List, we’d ship a bug to production, and everyone’s immediate reaction was to the point finger at the team’s QA resource. Shame on you for not catching that bug!

The engineer who wrote the code escaped any blame or sense of wrongdoing. Same with the engineer(s) who reviewed the code. As did the PM who was driving the release. Naturally, this led to a belief that you don’t need QA.

Between engineering and product, you should own your shit. Have a sense of accountability between the two of you.

However, I’ve regressed on sentiment while watching Dispatch grow. I now think you’ll reap the benefit of dedicated QA sooner than you think. Blindly hiring QA engineers sooner won’t magically solve all your quality problems. It does enable a broader, organizational approach to software development.

You can now have smaller, higher quality releases (and shipping code = addicting to your team).

  1. When you plan your future sprints out (or just the upcoming one), you start to think in iterative releases and constantly prepping release candidates. Smaller releases are key (obvious statement).

  2. You avoid the scenario of an engineer or PM saying “I don’t want to run regression so let’s bundle this one more thing in to prevent duplicate effort before testing.” Suddenly your release candidate has grown in size, and you’ve gone further between releases.

  3. Instead of testing being one of someone’s many priorities (“I’m not sure if I can get through running full regression in order to release tomorrow”), it’s someone’s only focus. Getting your release candidates out the door - measured by reducing the time between a release candidate going onto staging and it either being green lit or rejected.

Every day code is sitting in an release candidate branch, it grows stale when it could be helping make our users’ lives better

All of the above have led to us shipping code faster that’s also higher quality.