Software Quality Assurance
Before addressing the question of how to structure a QA team, it is worth talking about the value of QA in software. I strongly believe it is not required until there are clear indicators that it is needed:
- A project has insufficient automated integration testing
- The business impact of defects is high
- Feature and regression testing requires human interpretation
- The velocity of releases are too slow
I don’t advocate not having QA! I just don’t believe it is mandatory.
Team Structure
The answer to my question is: both. Using the team organization methodology presented in Team Topologies, the core product team should be the “stream” style. This means the first place to add a QA resource is directly as a member of the dev team!
QA can Program!
It is likely that a QA resource will be coding. Maybe not 100%, but if they are you want them to code at the same level as any other dev team member. Being an integral part of the product team means maintaining the same standards and review processes. Sidebar: Ever thought about tagging a QA team member to review code?
By bringing your QA member closer to dev, they can improve their own skills, offer more insight into where bugs are, write & commit failing test cases when issues are found and so much more!
Start Sooner!
Have you ever dropped a feature in QA’s lap and said, “Ok, it is ready to test!”? The results are not pretty. Unless your organization has superb specifications and your QA can easily read through them and develop tests… Then… Your dev team is now on calls walking the QA team through the feature and explaining how to test. Even if the team is not great at specifications and design, at least having QA as an integral part of the development process means they already know what is going on.
It also means the sooner test development can start! QA can provide early feedback on UX bugs and code bugs. Smaller circles, faster fixes!
Ownership
The whole point of a “stream-aligned” team is that everyone is coupled and all are owners. Ownership creates quality and member cohesion. By having a separate team, there is a fence that requires effort to cross.
This is Getting Bigger…
Once your QA resources start building platforms and test frameworks it might be time to create a new team. But this is a new team, not splitting the product team. The QA platform team is creating tooling that the product team is using but they are focused on things that don’t actually produce QA results! The original QA team member is still doing the same old work, but now they have a dedicated team releasing tooling to improve their job, but, other than that, they don’t talk much. Good team decomposition means less cognitive load, but also means there should be only light coupling.