Why even have Quality Assurance?
This one starts with a question: what is the purpose of Quality Assurance in a product company?
I think we all agree that there’s a very big primary goal of making sure bad products don’t get delivered to customers. The question, then, is in all the little secondary factors, and the tradeoffs that they imply.
For example, is it ok to prevent all bad products from getting to customers by also preventing all good products from getting to customers? You’d probably say no, but in for example a company with a complete monopoly, this could even make sense. Of course this is a wild exaggeration from anybody’s intentions, but it is certainly a tradeoff that is being made in the ‘traditional’ organisational role, where QA is tasked with the combinatorially exploding task of checking that every piece of product functionality works with every other, plus any third party integrations, all at the same time.
Finding our way out of the quagmire
Modern (and not so modern) software engineering practices have a way to route around this value-delivery-halting problem: automate this exploding complexity. Even better, the effort of implementing this automation should fall onto the exact same people implementing the new features; this is critical to provide backpressure at the implementation phase, towards making the product ‘testable’.
‘Testable’ in this context is a nice way of saying:
- easy to understand
- deterministic, and
- able to be used on its own, not just when tied into the rest of the system.
All of these are critical properties of good software design, and will pay back many times over in the long run.
A change of perspective
So, what is QA meant to do then, if they aren’t reading through an ever-expanding set of instructions and blindly executing what they are told? Well, there is one huge gap that the automated testing can’t cover, and that is the interpretation of the product requirements, and checking that the engineering efforts actually resulted in something that solved the customer problem. So, QA needs to take on more of a Product Owner role.
In fact, the Product Owner should probably be doing the final QA themselves, otherwise how do they know that their vision is what is being achieved?