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.