A release is ready except for testing. Then another feature reaches QA. A production fix needs checking before either of them, and the build for tomorrow’s release is still changing. By the time one item leaves the queue, two more have taken its place.
For a growing software team, this can happen gradually enough that nobody notices the point when QA stopped matching the pace of development. What used to fit comfortably inside a sprint no longer does.
Hiring more testers is one possible response. It is not always the one that frees the most time. A week spent mostly testing is very different from a week spent waiting for builds, recreating data, rerunning unreliable tests, and checking fixes for work that has already been through QA.
Before deciding what to add, it helps to see what is taking the time now.
First, find out where the week actually goes
Sprint boards are not particularly good at showing this.
A feature moves into QA on Tuesday and leaves on Thursday. It appears to have required two days of testing. Open the ticket history and a different picture may emerge. Nobody could start until late Tuesday. A defect was found Wednesday morning. Development returned a fix in the afternoon, but the new build was not available until Thursday.
Actual hands-on testing might have taken a fraction of those two days.
Looking back at several releases, rather than one unusually difficult sprint, gives a more useful baseline. Check:
- How long completed features wait before testing begins;
- How many hours still go into manual regression;
- Which checks return almost unchanged with every release;
- How much time is lost to builds, environments and test data;
- How often a feature comes back after its first QA pass;
- How much of a tester’s week is occupied by setup rather than testing.
There may be an obvious capacity shortage. There may also be enough QA time buried inside the process to change the situation without immediately expanding the team.
Option 1: Bring QA in while there is still something to discuss
One awkward requirement can generate far more work after development than before it. Imagine a feature that changes user permissions. The expected behavior is clear for administrators and regular users, so development proceeds. During testing, QA tries an account that belongs to two permission groups. Nobody has defined what should happen.
Now the question travels back through the team. Product clarifies it, development adjusts the logic, another build is prepared, and QA starts that part again.
Had the same case come up while the feature was being discussed, there might have been nothing to fix.
This is where earlier QA involvement is useful. Not as a mandatory ceremony for every ticket, but around work with enough states, roles, or dependencies to hide questions in the gaps. Payments, integrations, and complicated workflows are obvious candidates.
Testers can also prepare part of their coverage before implementation finishes. The last days of the sprint then contain less reading, interpretation, and discovery before the actual testing even gets underway.
Option 2: Open the regression suite and question what is still there
Regression testing gets heavier almost by default. Tests are added after incidents. More arrive with new functionality. Old integrations keep their checks long after the surrounding product has changed. Removing a case feels harder to defend than adding one, so the suite mostly moves in one direction.
Eventually, a fairly ordinary release carries years of accumulated regression behind it. There is little reason for every change to inherit exactly the same coverage. Authentication work can reach across a product. So can shared components, payment logic or a change to a common data model. A small adjustment inside an isolated feature has a different footprint.
Reviewing regression by affected areas and dependencies gives QA some room to vary the depth of testing. Broad changes can still receive a full run. Smaller ones do not automatically need every historical scenario.
Without that review, even a stable release schedule can become slower simply because the product has existed longer.
Option 3: Automate the work that keeps coming back
Look at the tests people perform every release without needing to think much about them anymore.
The same login flow. The same basic checkout. The same API requests with known responses. The same set of fields checked against twenty data combinations. The same smoke pass whenever a build lands.
Those hours are easier to put a value on than an abstract automation target.
A first pass at automation might include:
- Mature regression cases that rarely change;
- Business-critical journeys repeated for most releases;
- API checks with clear expected results;
- Repetitive tests across multiple datasets or configurations;
- Smoke checks used on every new build.
New functionality is not automatically a good candidate. When the workflow itself is still being revised, automated tests can turn into one more thing that needs editing every sprint.
There is also work worth leaving with people. Exploratory testing depends on curiosity and context. Usability problems are often obvious to a person long before they can be expressed as a pass-or-fail assertion. Once routine repetition is taken out of the day, testers have more time for exactly those areas.
Option 4: Add up the small delays around the test environment
Few teams would tolerate staging being unavailable for three days. Fifteen minutes at a time is easier to live with.
Then another build is deployed over the one QA needed. Test data has to be recreated. A dependent service is down for half an hour. Somebody discovers that the environment is running yesterday’s version.
The tester works around each incident and the day continues. None becomes a major event. Together, they may account for several hours.
Logging these interruptions for a couple of sprints can be surprisingly useful. Include time lost to deployments, environment failures, unavailable dependencies and data preparation. No complicated metric is required; the purpose is simply to stop that time disappearing inside “testing took longer than expected.”
If the total is small, move on. If it is substantial, there is capacity to recover before another tester is placed in front of the same setup.
Option 5: Increase the team when the old team size no longer fits the product
A two-person QA team may have been perfectly sensible for the first version of a web application.
A few years later, the same company has web, iOS and Android products, more integrations, more frequent releases and customers with additional security or compliance requirements. Nothing has to be badly organized for two testers to struggle with that. Sometimes, there is simply more software to cover.
Software QA services can extend an existing team across functional testing, automation, performance, security, compliance, usability, data quality, mobile testing, and other areas that have appeared as the product has expanded.
It still helps to be precise about what is missing. More functional testers will not solve a shortage of performance-testing expertise. Another manual tester can take work from an overloaded regression queue, although automating part of that queue may change how much extra capacity is needed in the first place.
The job that needs doing should determine the extra capacity, rather than a general sense that QA needs “more people.”
Option 6: Keep specialist work separate when it only appears occasionally
Some testing needs arrive in bursts. A large launch may require several weeks of performance work. A particular client or market can introduce compliance testing. Mobile compatibility may become unusually demanding around a major application update.
Between those periods, the normal QA workload looks quite different. The people who work with a product every sprint bring something difficult to replace: familiarity with its history. They know which areas are fragile, which workflows have accumulated odd exceptions, and where a harmless-looking change has caused trouble before.
That knowledge does not require the same people to cover every specialist discipline as well.
A core QA team can remain responsible for recurring product work while narrower expertise is added when needed. If one of those needs becomes frequent, the staffing model can change with it. Mobile QA that appears twice a year is one thing; mobile work in every sprint is another.
Option 7: Look at how often QA is seeing the same feature again
A long testing queue can contain a surprising amount of repeat business.
Monday: QA tests a feature and returns it with two defects. Tuesday: the fixes arrive and the feature is checked again. One of the fixes has changed another behavior. Wednesday: version three arrives.
That single feature has now taken attention on three separate days. A few cases like this are normal. If the pattern runs through much of a sprint, however, the number of new features is only part of the workload.
The reasons are worth tracing. Requirements may be leaving too much unresolved. Developers may be checking the immediate defect without the surrounding behavior. A shared component may have dependencies that are easy to miss.
First-pass acceptance can be useful here. Not as a score for developers, but as a way of seeing how much QA time is going into work the team has already handled once.
Option 8: Repair the automated tests that have become background noise
Most people who have worked around test automation know the conversation.
“That one fails sometimes.”
“Run it again.”
“It passed.”
One flaky test is manageable. A suite full of them changes the meaning of a failed run.
Instead of investigating the product, somebody first separates likely defects from familiar false alarms. Tests are rerun. Results are compared. A pipeline designed to provide quick feedback now creates a small investigation of its own.
These tests often survive because fixing them never feels as urgent as feature work. Their cost is spread across dozens of runs, which makes it easy to underestimate.
Repeatedly unreliable cases need attention. Depending on the cause, that might mean changing the test, stabilizing its data or dependency, or taking it out of a release gate until it behaves consistently.
Otherwise, automation keeps running while part of the QA team keeps manually interpreting it.
Option 9: Pay attention to the size of what arrives for testing
A payment change is ready. So are a new account setting, an API update, three interface changes, and several bug fixes. They all enter one release candidate.
Each item may be reasonably small on its own. QA now has to consider them together.
A late fix in shared code can cast doubt on something that already passed. One blocking defect delays unrelated work. When a replacement build arrives, the exact difference between this version and the previous one matters.
Reducing release size can make this easier, although it is not a change QA can make by itself. Frequent releases depend on deployment reliability, CI/CD, branching practices, and, in many products, feature flags that allow unfinished work to remain hidden.
If engineering still accumulates several weeks of changes into one package, smaller task descriptions on the sprint board will not give QA a smaller release.
The shape of the delivery process eventually becomes the shape of the testing problem.
Option 10: Use numbers that explain why the queue exists
Test execution totals are easy to report. “2,400 tests completed” looks concrete. It says very little about why Thursday’s release moved to Monday.
A more useful view includes the time a feature waits before QA starts, active testing time, the amount of manual regression, repeat QA passes, and defects found after release. Those numbers do not need to become an enormous dashboard. A few of them are enough to show whether the team is dealing with volume, waiting, rework, or weak coverage.
Context matters here. A shorter testing cycle accompanied by more production defects is hardly a win. A larger automated suite does not help much if releases are still waiting on environments.
The point of measuring QA is to explain what happens to a release between “development complete” and “ready to ship.” Everything else is secondary.
Before you hire, watch one ordinary sprint
Forget the release where everything went wrong at once. Pick a normal week.
See when work reaches QA. Notice whether testers can start immediately. Look at how much regression they repeat, how often a ticket returns, and whether the environment interrupts them. Then look at what is left: new testing that genuinely requires more hours, or specialist work nobody currently has the skills to cover.
If that remaining workload is larger than the team, extra capacity has a clear purpose. If a sizeable part of the week is being lost before that point, there are other places to work first. A repetitive check can be automated. A recurring staging problem can be fixed. Questions that regularly send features back to development can be raised earlier.
QA falling behind releases does not automatically mean the team is slow, and it does not automatically mean the team is too small. It means the amount of work arriving and the amount of useful testing time available no longer line up.
Finding out why they stopped lining up is what tells you which option is worth paying for.
