Roles vs Goals: A Note on Expectations in QA

Software development is a dynamic and constantly evolving field and, as a result, it has a lot of moving parts and targets. This can sometimes result in ambiguity and confusion as to what the expectations are for those involved. That being the case, a little clarification can go a long way, especially as it pertains to the roles and goals of QA and how that impacts our relationship with software developers and product owners.

QA’s role is to question, to clarify, to check and confirm; and to break things, preferably a lot. That last bit can cause more than a bit of frustration and consternation to project managers, product owners, and stake-holders, as it tends to run against their own roles which involve moving the product along in its development. It is during these times that it’s worth remembering that we do all share the same goal: to help make a great product. QA does this, by checking and verifying that features work as expected and by hitting the edge and corner cases. It is our responsibility to pursue a feature’s happy path and do some rather unhappy things to it.

Quality is not as simple as a stamp of approval or a series of test cases highlighted green and marked “Pass”. Any seasoned project manager knows that metrics alone are, at best, a very one-dimensional measure of the readiness of a product or of a new build. Quality is the byproduct of the ongoing interaction between the hammer and anvil of the devs, and the fire and quenching of QA. They build it, we break it. A great product is the result of that collaboration.