How Much QA Tax Do You Pay?

Your QA team is there to protect quality. Without them you would release buggy software and lose your loyal, cash-supplying customers. Or so the theory goes. But what if your QA team were actually costing you money?

In my experience, some teams may be paying unnecessary QA taxes: distractions to developers, time-consuming release processes, and missed opportunity for really raising the quality threshold.

So let’s have a look at a few of the QA taxes you might be able to avoid so you can purchase a shiny new Ferrari instead.Care-free Developers who Increase Cycle-times

Time and time-again I see work failing QA because developers have not put in enough effort. They didn’t test it, they didn’t read the requirements properly, or they just didn’t care enough.

But this is the fault of the system — when QA is a safety net, and QA are responsible for bugs getting into production, many developers will not feel compelled to put in the effort and do their job properly. If something goes wrong, it’s not their fault.

Viewing the QA team as a safety net for developers reminds me a lot of Risk Management Theatre.

Apart from the unnecessary work caused by not getting things right the first time, it also reduces development efficiency by frequently distracting developers.More Distractions Reduce Development Efficiency

As a result of more work failing QA, I see developers continually being distracted by the QA team. As a developer myself, I can think of few things that hurt productivity more than being distracted when I am trying to focus on something.

On many occasions I see the QA team distracting developers to clarify requirements. Again, these distractions can really hurt productivity. But really, to me they are a symptom of putting everybody in their silo and not sharing the bigger picture with everyone.More WIP Reduces Quality

Another consequence of work failing QA is that there is more work in progress (WIP). From a developer’s point of view this is bad because there are more reasons to be distracted and lose focus. And from a project point of view this means less efficiency.

From the business’ point of view, more work in progress (WIP) can manifest itself as a lot of incomplete features (as I mentioned in my last post) giving the impression the development team are clueless.Painful Deployment Procedure That Increases Risk

Because QA are responsible for quality, and they are put in the QA silo, then they optimize for their role and not the system as a whole. I see this manifest itself as overly-rigorous testing procedures on every environment before a deployment is allowed:

“Full regression pack on INT. All clear. Full regression pack on UAT. All clear. Full regression pack on hidden Prod server. All clear. Full regression pack on Prod. All clear. Ok, developers, you may now begin adding value again.”

Because this process takes a long time, then deploys are too expensive. This means that work has to be batched up to avoid the high transaction cost of deploying frequently. But bigger deployment batches mean more reasons the deploy will fail, and thus more testing to compensate for the increased risk.

When deploys do fail, it’s often more expensive to fix because it takes longer to work out what has gone wrong. I have a few stories I could tell you about this.How About Hiring People Who Care And Building In Quality?

I know that the QA taxes I’ve talked about are definitely avoidable. Teams that are successfully applying continuous delivery (CD) don’t pay any of these taxes — instead they focus on the fun parts of being a developer — adding value. Fortunately this is also a big win for the business.

But it’s not necessary to go all the way in to CD. You can still trim down your tax bill by making gradual changes.

In my opinion, the first change has to be hiring people who care about doing a quality job and sharing the vision of the business. These people can instantly cut down the number of tasks failing QA and the snowball effects like increased WIP.

I also believe that a culture that builds-in quality, using practices such as group learning and automated testing (aligned with The Testing Pyramid) is the next most important step.

With people who care and a culture that promotes quality, I’ve seen how you can heavily reduce the reliance on QA. But you really need the right people…

Sometimes, you just have to forget about the Ferrari and pay those QA taxes instead.