That one time I fired our QA team
August 30, 2021I got a few complaints from developers who didn't enjoy splitting focus between dev and testing, but they admited it was better than before.
A few short years ago I was managing a small number of scrum teams building some software. Each scrum team had designated “QA Engineer”, who was responsible for manually testing the work each developer did before the end of the sprint.
This lead to two big problems:
- The first half of each sprint, our QA engineers were mostly idle, and the second half the devs were mostly idle
- There was an adversarial relationship between devs and engineers
To complicate matters further, most of these QA engineers were contracted through an off-shore staff augmentation service, and most of our developers were in house. So there were different and complicated reporting structures, and different incentives in play as well. This also meant that the off-shore QA engineers were actively opposed to any form of test automation, since it meant less work for them.
How did we solve the problem?
I hired a test automation consultant to spend 6 months with us. She helped us build automation where it made sense, and trained our in-house QA engineer and the developers on how to use it, and we gave the off-shore QA team notice.
Then we prepared, with baited breath for the next day. Everyone was nervious. Surely we’d have more bugs get through to our end users. Surely the sh*t would hit the fan!
I scheduled extra regular meetings with our freelance automation engineer, and our in-house QA engineer to handle all the problems we knew would come up after the transition.
Our extra scheduled meetings were complete unnecessary. Nothing else broke. Quality didn’t drop.
What’s more, developers were no longer waiting on QA.
I did get a few isolated complaints from developers who didn’t enjoy splitting focus between development and testing, but they did admit that this was better than before when they were splitting focus between development and waiting on someone else.
Does this mean QA engineers or a QA team are bad?
Of course not. We still had QA, just more on a consultative basis.
I also have no reason to believe this is the only arrangement that would work, or even that it would work for this same company forever. It was simply an incremental improvement over what we had before. Everyone was happier (even the QA engineers we let go, who were assigned to other projects within their agency).
Which skill is more important: Testing, or debugging?
One of these skills, if you're good at it, diminishes the need for the other other.
What's the ideal ratio of devs to QAs?
Of course, as a consultant, I can confidently tell you: It depends!