The case for integrated QAs in tech teams
Traditionally, tech teams place their QA function outside of core development. They form entire herds of QA people that come at the end of a feature being developed and do what they can.
Most of the time they’re not even based on the same floor, or they’re outsourced entirely. But why is this?
I believe that the fastest way to achieve quality coding is by making it something that every member of the team is responsible for. It’s very hard to share a responsibility with someone that’s not in your team.
The dangers of QAs sitting outside of the tech team ⚠️
1. Long lag times
When you have separated teams, you need a vehicle to transport information. Developers build features on provided written information, like a JIRA ticket. When they’re done, they send the ticket to QA.
In theory, this should contain all the essential information. Yet if any part of the written task isn’t crystal clear, the QA will be forced to pause, ask for more details and wait for a reply.
My experience tells me that this happens at least once per task, and it’s unnecessarily time-consuming for both the QA and development team.
2. Higher overall costs of development
There’s a direct cost in man hours of taking a task back and forth between the two teams. After the first round of testing, anything from repairing bugs to refactoring might be necessary.
But there are more subtle, opportunity costs too - like the time it takes someone to get back into the right headspace, disputing a bug (often over the internet, especially these days), the time spent building the application every time you receive feedback, etc.
3. Tools can be pricey
Many tools are versatile and can be used by both developers and QAs (although of course, some are better for one team than the other).
But teams often like to choose their own tools, which can lead to the company paying for a number of tools that are virtually the same.
It’s very hard to share a responsibility with someone that’s not in your team.
What you’ll never hear tech teams discuss out loud 🤫
Shallowness of testing - If the QA is in a different team to the developer, they will participate in some, but not all, of the same conversations. This makes it harder for the QA to fully understand a task, as a lot of information won’t make its way to the written task. Even with proper acceptance criteria and a good refinement process in place, the testing won’t be as deep and well-targeted as it could be.
Lower coverage - The number of times I’ve had a developer tell me that they covered all angles in an integration test and, after reviewing it, I found another! When teams are split, the peer review is often performed only by one other developer. So the chances of mistakes being spotted are small.
Some things require the right environment ✅
Specialised types of testing (for example, destructive testing) can be tricky. Without tools like Istio, they’re difficult to perform and it can take what seems like forever.
But on the other hand, infrastructure monsters like Istio require buy-in from the entire team. It’s the only way you can reap the benefits from implementation. Ultimately, a QA stuck on a different floor will have a hard time gathering all the interested parties and convincing them of the idea.
Don't ignore the bigger issues 🙉
Lack of empathy - It always amazes me how often people forget that tech teams are formed of … people. Contrary to popular opinion, we’re not robotic coding machines! The feeling that you’re part of something; that you’re building a product together - this can move mountains. A QA who is part of a team is bound to feel more motivated, and a developer who has a QA in the same team will strive to do more so they’re not just passing on the burden.
Nobody fills the cracks - The secret to any system’s success is not in the actual components, but in the way they work together. Every QA and every developer is different. They have their own strengths and weaknesses. In a team, these qualities tend to balance each other out, because you’re more prone to put in the extra effort for someone you know than for someone in the wider company. Not to mention, there are always tasks that fall outside the obvious scope of any job title which could end up falling through the cracks.
Even in a well intentioned team, things can go wrong ☔
Overlapping efforts can be particularly problematic. Most of the time, developers write unit and integration tests while QAs write the higher level end-to-end tests.
In the vast majority of cases, you can test something on more than one level. But the truth is, any of the levels you chose to write your test on might be right. When teams are separate and you’re not 100% sure what the other has covered, you’re more likely to double check.
It’s not impossible to achieve high quality in a traditional model - it’s just a lot harder.
You need every member of every team to be educated about the potential faults of the system. You also need every person to be committed to taking the right way round, not the easy way (shortcuts won’t cut it). You need every step of the process to work perfectly, unless you want to risk the errors rippling through the teams without being absorbed.
In the world of modern technology, where everything takes the blink of an eye, why would you take the slow path if you could take the correct path?