he’s seeing some pain within his organisation around Quality, or lack thereof.
Just to be clear that’s not a tester problem, that’s a company problem.
He explained how the testing team is being swamped and often bypassed because their backlog of things to test is too long and he wanted to know what is a good Dev:QA ratio.
Not where I’d start, nowhere near. “Person-hours” is rarely the problem, and guess what happens when you throw more bodies at something that doesn’t work? You get 5 road workers staring at a hole drinking tea. I’d look at what’s in the backlog and find out why it’s there. Good testers should work within the boundaries they are given. Working with resources available, or “logistics”, is a vital part of a good test strategy. So why are they insisting on using so much time?
If there’s a process making them all slave at the rock-face of pointless work, that would be a great thing to change before they spend a few grand on hiring.
- Are they made to fill in pointless sheets or other busywork that kills the time of a skilled professional?
- Do they have a prescriptive process of filling out test case templates or automating everything that’s thrown at them or something else from the 80s that needs to piss off and die?
- Is there a test manager, and are they awful?
- Are the testers awful?
- Are there giant walls between the testers and the teams they work with? Do they ever actually talk to each other? Sitting people in close proximity and hoping that information will travel via pheromones sounds like the ramblings of an insane person, but I’ve seen it implemented as a business strategy.
- Are bug reports flung over those walls over and over again like some kind of tennis match in hell?
etc. This is the role of your team managers, project managers, test managers, etc. It’s what their highly trained, shiny shoed, kale-eating bodies are built for when they’re not sporting fashionable shirts or hitting the squash court.
Here’s some stuff one could do instead of spending 20% salary on recruitment, £15k on a probationary salary, £2k on national insurance, £4k on pension, £800 on onboarding and training, £1k on office space and equipment plus holiday cover, health care, gym membership and the drinks in the free fridge, then waiting for the teams to settle back down after you disturb the workflow by throwing people into it, then repeating the process when people start leaving because your processes are still broken.
Examine team processes and see what’s taking so long. Check for overly formal processes, busywork and timesheets. If you make testers fill out little forms any more than absolutely necessary you might as well take their wages down to the casino instead. Burn the paperwork in the car park in a ritual, wearing board marker as face paint. Look for large feedback loops. Look for communication failures. You know what’s faster than a 2-page bug report? Finding the bug mid-coding and talking face to face and it never going into a build. A company-internally-written bug report is a failure of communication and process that should be minimised.
Examine the backlog and see what’s in it. Why is it there? Ask your testers or test manager this question: “How does this serve your test strategy?”. You may also need “what is your test strategy?”. If it isn’t serving a test strategy then it’s pointless - you need to find out why it got there and why nobody threw it away.
Examine your dev team and see why they’re moving so fast. If they are in any kind of even slightly agile environment why are the coders picking up work when there’s a blockage in the pipeline? Have WIP limits and enforce them. Visualise what gets tested and do not permit anything to escape without test. Hold teams accountable when bugs escape - did they test it? Who decided not to even look at it? Then you’ll get your testing down pretty fast, one way or the other (or, probably deservedly, go out of business). You cannot move without bandwidth and slack. If your coders can spare a second for the proles in the testing pits perhaps they could help clear the right side of the Kanban board? Throwing pottery orders at some busy potters is not helping to make more pots.
Examine your release schedule. Are you releasing often, or are you going for a more traffic-jammy approach of letting everything build up like Augustus Gloop in the chocolate tube? Do your testers have a soul-destroying 6 month “regression suite” filled with pointless nonsense nobody’s really looked at in years? Try replacing that with a non-animal sacrifice, such as spilling the blood of a lettuce before the Gods - this is fast, and offers the same feeling of unearned comfort. For 5 testers earning £25k a year at 37.5 hours a week that’s over 8k a month. Spend it wisely.
Here’s a crazy idea I read in “Wild Management Ideas So Crazy You’d Have To Be From The Future”: Ask your testers what is taking so long. What do they think would be a better, faster, less wasteful way of working? How about the rest of the team?
A business needs healthy FLOW. Unblock whatever’s in its way, or pay for the blockage.
Find all of those problems and fix them until your processes look like you’re actually achieving something, then you can see much more clearly where the issue is lack of bodies. THEN you get to think about hiring, although I’d still go for a second opinion (<== this is the answer to your question of when to hire a/more testers)
Remember: When doing something stupid, more people means more stupid. When doing something clever, more people means more problems.