If testing is delaying the programme, measure the delay before fixing the testers.
Testing is the last visible stage in many delivery models, which makes it an excellent place for every upstream delay to arrive wearing a new name. Testing is often blamed for delay because it is where three months of upstream lateness finally acquires a timestamp.
If you want an independent bottleneck review, we can follow the work end to end and separate actual test effort from waiting, rework and organisational faffing.
Follow one change through the system
Take a normal change and record elapsed time from development complete to release. Break it into waiting for deployment, environment, data, access, test execution, investigation, defect fixing, retest and approval.
You may find the ‘six-day testing phase’ contains nine hours of testing and five days of waiting for things testing does not control.
Find rework
How often do builds arrive incomplete? How many defects are caused by misunderstood requirements? How much automation is rerun because it is flaky? How often does the test environment differ from the intended release?
Rework can make a team appear slow while the real problem is poor feedback earlier in delivery.
Challenge the regression model
If every change triggers the same giant test pack, the process may genuinely be too slow. Risk-based scope, stronger lower-level automation, better component testing and smaller releases can reduce the amount of late manual regression.
But do not automate everything merely to improve the speed metric. Fast useless tests are still useless.
A blocked tester is not slow testing. It is a queue with a witness.
Fix the constraint that controls throughput
More testers help only when test execution is actually the limiting factor. If deployment capacity is the constraint, add deployment capacity. If data is the constraint, fix data. If defect turnaround is the constraint, get engineering attention onto it.
The goal is faster reliable feedback, not proving that one department can hit its local target while the programme remains slow.
Watch queue size as well as duration
A stage can look efficient in isolation while work piles up in front of it. If individual tests execute quickly but twenty releases are waiting for the same shared environment, the bottleneck is still real.
Look at work in progress, arrival rate and capacity across the whole flow. High utilisation can actually make queues worse because there is no slack to absorb defects, urgent changes or environment failures.
The fastest team is not necessarily the best-performing system. Optimise the path to reliable release, not local productivity statistics.
An end-to-end bottleneck example
A programme calls testing a six-day bottleneck. Follow ten representative changes from ‘development complete’ to production and record elapsed time, including work waiting in queues. The combined average turns out to be one day awaiting deployment, one day awaiting data, six hours of test execution, two days awaiting defect fixes and the remaining time in approvals. The bottleneck is the system around testing.
Now look at how much work arrives together. If forty changes land in a Friday build, the batch creates a queue even when each change is quick to check. Pilot smaller releases or an earlier integrated build, and compare total lead time and avoidable retest work.
Separate evidence of flow from team utilisation. A tester can be busy every minute while the customer waits a week for a change. If the issue is instead the test team’s own repetitive work, see how to reduce test execution and waiting effort.
Test whether batching is creating the delay
Large batches amplify testing pain. Weeks of development arrive together, dependencies collide and every defect threatens a giant release. Smaller changes can reduce regression scope and make feedback easier to interpret. If reducing the test estimate is the only schedule lever anyone will consider, the plan is already negotiating with reality rather than managing it.
If the delivery model allows it, reducing batch size may improve throughput more than optimising the test phase itself. The best way to make a bottleneck smaller is sometimes to stop feeding it work in enormous lumps.