The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.
It's being edited by Lee Hawkins who is posing questions on Twitter, LinkedIn, Slack, and the AST mailing list and then collating the replies, focusing on practice over theory.
I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be.Perhaps you'd like to join me?
--00--
"What’s the right ratio of developers to testers?"
You're an intelligent person with a sense of humour, so I hope you won't mind when I start my answer with what's the right length for this string?
As usual, there are a bunch of factors that are relevant in answering your question, or maybe the question behind the question. The extent to which you care about the answer, and the use you want to make of it, will help us know how deep we need to dig. Establishing those facts early on can save a lot of time, effort, and frustration on both our parts.
For example, if you're asking because HR want some kind of hiring estimate for next year's budget I'd guess you just need something ballpark, plausible, and defensible. And yesterday, naturally.
A reasonable strategy would be to get numbers from ongoing projects, assume nothing much will change about how projects are set up in the coming 12 months, and use that as the basis for your response.
Alternatively, maybe you're setting up a couple of new teams and are wondering about how to staff them. Of course you'll also be thinking about the impact on existing teams that lose members in the process, won't you?
At this granularity, factors such as the kind of work these teams will do (greenfield, maintenance, integration, research, ...), the mix of personnel (experienced, expert, newbie, enthusiastic, completer-finisher, creative, ...), their skills (development, testing, architecture, co-ordination, leadership, ...) and their familiarity (with the tech, with the domain, with the customer's system, with each other, ...) are important to consider. At least, important to the extent that the projects matter against all of the other work that's going on and the opportunity costs they incur.
Or if you're worried about a particular project, then we can wonder how you got from whatever quantitative and qualitative feedback you've received to the relative numbers of developers and testers. Lots of bugs? Lots of production incidents? Lots of rework? Lots of people crying that testing is a bottleneck?
There will be those who reckon that adding testers (more testing to get quality up) or removing testers (no safety net, so developers will have to test more) is the answer. If this project is really flagging, then in my opinion it's more likely that talking to the team members and looking carefully at its practices, its interfaces with other teams, the business, and so on is a better way to fix things than waving some arbitrary and context-free mathematical wand.
So, how long should we make that string and what will fall over when we pull on it?
Image: https://flic.kr/p/ouk2wb
Comments
Post a Comment