Who writes code? The obvious answer is that developers write code. Who makes sure the code works? The answer to this question also seems obvious. It should also be developers… right?

Fairly often, that is not actually the case. Many companies have separate QA departments that are responsible for making sure code works. Developers write code, then they throw it over a wall for someone else to test for them.

There are a variety of reasons why a company may want to do this, but they all pale in comparison to the costs. The first is the context switching involved. Think of the timeline:

• Developer writes code
• QA tester tests code… while developer writes code for something else?

A developer isn’t going to twiddle their thumbs while someone tests their code. They’re going to start working on something else.

What happens if something comes up during testing? Maybe there’s a bug. Maybe there’s a clarification needed. Either way, the developer now undergoes a context switch which can be distracting. The ideal situation was the code goes through a pipeline where it is written and then tested, never having to go back to the developer. But if code always worked perfectly, then we wouldn’t need testing. The whole point of testing is because code often fails. Instead of letting a developer focus on one task before moving onto another, this process introduces unnecessary multi-tasking.

This timeline also causes another problem. If your team practices sprints, then you’re also probably trying to start and close stories in the same sprint. With the nature of a testing pass off, a developer either twiddles their thumbs at the end of a sprint or they have to start working on the next sprint… which also means you have to plan two sprints in advance. Or you can have QA work outside of the sprint, which isn’t great because now they are effectively working outside of the team.

Bottom line, unless QA can test instantly, there’s no clean way to incorporate this kind of hand off process very well.

There’s also the issue that having developers throw their code over a wall reduces their own accountability. I’ve seen many developers use a separate QA team as a crutch. Why do more diligent testing if it’s probably going to work and someone else will catch the mistakes in the small chance that there is a bug?

Also, why spend writing automated tests when it’ll save someone else time instead of mine?

These are perverse incentives that can make anyone make bad decisions.

Speaking of incentives, the biggest problem with a separate QA team is that they’re evaluated differently. A development team is often expected to meet timelines. A QA team is expected to not let any bugs through. Rarely is someone in charge to create a compromise between these two incentives to maximize the value to the product as a whole. This misalignment creates rifts between two groups of people that should be working towards a common goal.

It’d be interesting to hear what other people’s experiences have been, but I have never seen separate dev and QA teams work nearly as effectively as a single development team that does it’s own testing. Some people may argue that they can’t trust their developers to test their own code. This is a tragedy for many reasons, but accepting that those developers can not test their own code is not a valid solution. The solution is to figure out how they can.