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.
Top comments (5)
At Surevine, we have Test Engineers as part of the development teams (alongside Software Engineers, of course, but also Team Leads and Infrastructure Engineers). The Test Engineers do a lot of testing, of course, but are also continuously involved in the work the Software Engineers are doing, to ensure that the code is testable and - where possible - tested properly with unit tests etc.
But we don't expect Software Engineers to test their own code - the purpose of testing is for an additional pair of eyes to find issues as well as simple QA. We do, however, expect Software Engineers to understand testing properly, in order to support the Test Engineers - and the team, as a whole, tests its own output.
This is what I came here to say. That's how my org works -- there are devs writing unit tests and test engies writing integration and end to end tests within the same team. QA begins when a feature is complete sans unit tests, so by the time it's formally "in QA" on JIRA, it's pretty much done and just needs a quick regression run of the automated tests.
In the past I have worked at companies where there was a QA team which tested our code / user stories and it was never as much of a problem as you describe.
The QA team would be involved in the project from the start and throughout attending stand ups etc, so we did not really "throw things over the wall", it was all part of the process of getting our user stories completed for the sprints.
I would say that it worked quite well and resulted in a higher quality, more "water tight" product delivered to the client as the QA testers would often test things differently to devs and find things we never thought of.
Also there was never any reduction in accountability on individual devs as all work was peer reviewed by another dev before being merged and the ticket assigned to QA, and if you did not want to have to go back and fix things that was a good incentive for doing a thorough job.
Context switching was never a problem because we would simply complete whatever user story we were currently working on and then go back to any which failed testing and fix them.
So to summarize I think having a QA team test the work was a good thing and based on my own experience at various companies in the past this worked very well.
A person who focuses on testing the code another person created can often time find things that even the original developer will have missed in testing. I concur that a separate QA team creates the "over the wall" mentality that is toxic and we should avoid it.
A better model is a person(s) embedded within the development team that is focused on writing automated tests. These folks can find behaviors that developers often miss. This doesn't mean the developers don't write automated tests as well, they should be creating their own unit tests.
I started my career as a separate QA and while the process can take time, and cycles to get things done, it can be done. While its not always necessary to have QA check code a Developer should ALWAYS have someone else check their code, trying to test your own work is a sure road to failure. Often too close, and not thinking outside the box that the code was made for, just doing a review and merging it is a road to failure. Some Developers can test their code effectively, but for a really good QA person there are ways of checking, testing, and trying out things that often a Developer will not. There is a skill set that often makes a person really good at testing, which is not often found alongside those who are really good and elegant at coding.