What Does a QA DO?

Note: This is my personal definition and represents how I approach my work, not necessarily what various companies in the industry hire for. While I feel like this is something companies should incorporate into their own QA positions, I recognize this is not the case everywhere.

A QA, within a software development team, is the Quality Advocate first and foremost. It is their job to ensure the quality and work required is balanced with speed of delivery. A QA will create and maintain the test strategy such that major concerns are addressed, bugs are found, and the customer experience is known.

A QA should know what the critical user flows for customers are, as well as knowing and understanding personas of users. They should be able to leverage this knowledge to understand how a change could impact users and how users can potentially read documentation.

A QA should know and understand the architecture of the product. They should be able to leverage this knowledge to identify points of concern (eg, integrating with a volatile dependency).

A QA seeks cooperation, not confrontation. The test strategy is everyone’s responsibility to add to and is owned by the team. The QA acts as the shepherd for the strategy - if there’s a problem with the strategy (eg, one layer takes too long to be useful), the QA will ensure it is fixed (which might involve the rest of the team, or accepting a solution from a team member). The QA will ensure quality related metrics are tracked and communicated when the metrics means something has to change.

A QA can troubleshoot problems found (or do root cause analysis) and assist the developers in fixing it. They should also be able to understand how to change the test strategy to ensure such a problem is caught sooner in the future, or know when such a change costs more than it is worth.

A QA can learn how to appropriately leverage the rest of their development team when they need help. For example, if the QA workload has gotten large enough they feel they are falling behind, QAs can identify tests or other automated tasks developers can aid with. On the other hand, if the QA workload is particularly light, the QAs can look at what tests / automated tasks they can write to lower the developer workload. A QA should learn what tasks can easily be distributed, and which people on their team need a little training or prep to aid with.

A QA will analyze upcoming stories to understand how they affect the user flows and what is needed to test the stories. They will use this knowledge to prepare what they can ahead of time (eg, datasets) and start reaching out for the items they need.

A QA will build a test strategy which maximizes exploratory time via automation and other means. Exploratory tests are usually some of the most important forms of testing, but regression should never be neglected. QAs use their knowledge covered in other sections to identify critical areas for regression and how to implement the regression in an effective way.