I’m looking for some advice on a situation where development output is growing much faster than QA capacity, while increasing the number of QA engineers is not really an option.
In this situation, QA obviously can’t realistically test everything in depth before every release.
How do you normally handle this?
Would you recommend:
Sitting down with leadership/product to explicitly agree on what QA can realistically guarantee, what should be deferred, and what is lower priority?
Keeping the scope as small and manageable as possible, rather than trying to cover everything?
Gradually increasing automation coverage for stable and repetitive flows to reduce the manual testing workload?
Making the remaining risks explicit before go-live, so that everyone understands what has and hasn’t been covered?
I’m particularly interested in how other teams handle the situation where Dev can continuously increase their output, but QA capacity doesn’t scale at the same rate.
How do you balance delivery speed, test coverage, automation, and release risk in this situation?
What processes or strategies have worked well for your teams?
I had the same problem when I had a job. Getting more QAs was not an option. I was laid off before I even got a chance to figure out how to deal with it. So, I’ll just follow this thread. But, I have some questions about your process that might help you to get better answers from other people.
1 - How often do you release?
2 - Do you have too much manual testing work for every release? E.g. regression, bug bash, document preparation etc.
3 - Do your Developers use AI for development? If yes, then does QA also use it? Why/Why not?
4 - Can the Developers contribute to automation tests or even some testing ? (E.g. you could give Devs test cases for manual tests for execution.)
5 - Is your manager open to hiring a contractor for maybe 1 year to help with the manual testing while you automate tests?
I’d take a step back and look at what activities your QA are doing and ask does it make sense still to do those activities.
As a tester my role is the discovery and investigation of product risk, not as a final quality gate, but as one of the ways teams surface both risks and assumptions and build shared understanding throughout the lifecycle.
Now fast is the wrong term but I’d like to think that I’m fairly efficient at it, I might be solo testing on say four products on any given day and that is currently a healthy limit without overloading on context switching. I do other QE and automation activities but I want to keep my time on those to a minimum as time on those take me away from my primary skill of testing, note I also only in very rare cases write test cases for the same reason, they take me away from time on testing where my critical thinking and analysis skills are constantly active.
If we do get to a point where the development is outpacing my testing, it’s likely rather than take on more projects that I may double up my sessions on products so say reduce from four products to two, I am not seeing this to date as I often have capacity for secondary and tertiary activities that I’d likely shift first.
What I am seeing though is that many others have been broadening the QA role, perhaps spending a lot of time on things like test cases, scripting, automation alongside picking up more QE devops type activities so they have been fully loaded on perhaps secondary and tertiary activities with some of them carrying a lot of waste, so busy work.
Busy work will struggle development increases in speed, because they are already busy, busy work will lead to AI doing things that likely should never have been done in the first place.
That is what I’d recommend looking at, how much of the work being done now could be regarded as busy work, is it still needed, is it better placed in a different role, is a rebalance required or maybe a shift back to focus on the core critical thinking strength areas?
i’d stop treating QA as the release gate and make risk ownership explicit. for each change, product and engineering should name the user path at risk, decide what must be tested before release, what can be sampled, and who accepts the uncovered risk. then spend QA time on unknown behavior and move deterministic checks into the delivery pipeline.
for browser work, keep a small critical-path smoke set and require every failure to carry the starting state, exact action, expected versus actual, and the first useful console, network, or trace signal. that lets the team act without burning scarce QA time reconstructing the path.
track escaped risk and time spent investigating failures, not test-case count. if output rises but those two worsen, the team is shipping faster by borrowing from support and engineering.
Have the dev team own the testing too. They will obviously work based on some requirements and those requirements should actually be very detailed and locked in. Then it becomes a dev’s job to make sure they covered the use cases at the very least.
Automation for everything that gets tested and deployed. AI is your friend (not google anymore) so setup an agent that knows how to write your UI tests.