Should engineering organizations have quality assurance (QA)? A lot of engineering leaders say they should not. I review the topic, and provide some suggestions for QA leaders, and some nuance on the problems with the way QA and engineering work together. 🌶️ ahead!
QA should not exist
In some engineering leadership circles, the answer is “of course not”. QA is largely seen as an old fashioned practice: “Engineering should own quality”.
I tend to be skeptical of this type of engineering hubris. But there are some good arguments for this:
QA slows things down . There is too much back and forth when you’re passing work in a gated process. QA finds an issue, dev fixes it. Then QA rechecks it and finds other issues. This continues forever, greatly slowing down engineering velocity.
. There is too much back and forth when you’re passing work in a gated process. QA finds an issue, dev fixes it. Then QA rechecks it and finds other issues. This continues forever, greatly slowing down engineering velocity. Throw it over the wall . There is a moral hazard in having other people responsible for whether your work is correct. You’re creating bad behavior for your engineers by not having them responsible for their quality.
. There is a moral hazard in having other people responsible for whether your work is correct. You’re creating bad behavior for your engineers by not having them responsible for their quality. Incentives are poor for QA. If your job is to find issues, you’re going to find issues. This automatically slows down engineering, regardless of whether the issues are important or not.
QA is often compared to Operations. Having engineers write code and operators put it in production and care for it has similar problems: handoffs and incentive problems.
In a lot of modern and startup environments, engineering leaders view that as a harmful practice. And they’re often dismissive of the value of QA as a result.
QA should definitely exist
... continue reading