Every time we propose moving QA into planning, we hear the same objection: "We don't have time for testers in grooming. We barely ship as it is." It sounds reasonable. Ceremonies are already long, and adding a QA engineer to requirements discussions looks like pure overhead.
Except the teams we've measured came out faster, not slower. On one project, overall testing time dropped 40% and release velocity went up 30% — with a single manual QA engineer and no automation-first transformation. The sequence that worked was participation before automation: QA attention enters at requirements, grooming, integration, and staging, and the tooling investment comes later, if at all.
Here's how that played out across six projects, with the numbers, and where it doesn't pay off.
What "later" actually costs when testing lives in UAT
The default on most teams isn't a decision anyone made. Nobody sits down and chooses "we will find all our bugs two days before release." Testing drifts to UAT because that's the first moment someone who isn't the author looks at the feature — and it stays there because every sprint is too busy to change it.
That's exactly what we walked into on an enterprise CTEM cybersecurity platform: no formalized quality control procedures, testing executed mostly in the UAT phase, and bug reports without enough context to reproduce anything. The visible symptom was late bug discovery. The actual cost was the loop behind it: a defect found in UAT goes back to a developer who has already switched context, gets refixed against requirements nobody wrote down, and comes back to a tester who can't tell whether the new behavior is correct. Tickets on that project were reopened so often that when we later standardized reports and moved testing earlier, the reopen rate fell by 80%.
Industry-wide, this is not a small leak — CISQ estimated the cost of poor software quality in the US at $2.41 trillion back in 2022, a large share of it rework and defects caught late. But the case for shifting left doesn't need trillion-dollar framing. It needs one honest count of how many tickets on your board are on their second or third round trip.
Requirements and acceptance criteria are the first test artifacts
The cheapest defect to fix is an ambiguity in a story, because at that point there is no code to change. This is the least glamorous part of shift-left and the highest-yield one.
On Catalyst, a data-collection platform for BCBA therapists, there were no detailed specifications at all when we joined. Before writing a single test case, the QA team built the missing layer: detailed specs with clear acceptance criteria — eventually 150 Confluence pages and 60 user stories. Two manual QA engineers, daily 15-minute syncs with the team, no automation to start. The first release shipped three months after we started — a week ahead of schedule. And because testing was driven by explicit criteria, the bugs found were the ones worth finding: 25% critical and 45% major — not a pile of cosmetic tickets.
On SimpliField, a retail operations platform where testing had been done by non-QA staff, requirements review was part of the engagement from the outset: QA checked stories for errors and ambiguities alongside development, design, and product before implementation began. As reported in the case, 65% more bugs were found after the QA team joined (no pre-engagement baseline was published, so treat that as reported rather than a controlled comparison). The engagement eventually grew to 8,000+ test cases and 95% coverage, with 24 app versions released with zero critical or major bugs — but the requirements review came first, and it required nothing more than a tester in the room before the code existed.
Reviewing stories for ambiguity before code exists
Concretely, "requirements review" means treating a story like a failing test. Take a real-shaped example:
As a user, I can export my report as PDF.
Five questions a tester asks before this reaches a sprint: Which report states are exportable — drafts too? What happens on an empty report? Is there a size limit, and what does the user see when it's hit? Does export respect the viewer's permissions or the owner's? What's the expected behavior while generation is in progress?
Each answer becomes an acceptance criterion, and each criterion is a test that exists before the code does:
Scenario: Export blocked for reports the user cannot view in full
Given a report containing sections restricted to "finance" role
And the current user does not have the "finance" role
When the user exports the report as PDF
Then the PDF contains only the sections the user can view
And the export is logged with the user's effective permissions
The trade-off to name honestly: QA drafting criteria alone just recreates the silo one step earlier. On Catalyst this worked because product owned the outcome and the daily syncs kept the specs shared artifacts, not QA's private documents. If your product manager treats acceptance criteria as QA's homework, you've moved the wall, not removed it.
QA in planning ceremonies — without becoming a gate
The fear behind "QA will slow down planning" is really a fear of gates: one more person whose approval every story needs. That's not what participation means. In grooming, a QA engineer's job is to surface risk and ambiguity while changing a story is still free — not to sign off on anything.
Datasport, a platform for organizing sports events and marathons, is the clearest before/after we have. Before: no formal QA process, testing executed by developers, and user stories written so loosely that developing one took 1–2 weeks of back-and-forth. The change was structural: combined grooming meetings for frontend and backend developers, plus individual sessions with product owners and designers to refine requirements before story creation. Story finalization dropped to under 2 days. To be precise about attribution: that drop came from grooming plus story templates together, not from QA presence alone — and along the way the QA team logged over 4,000 critical and major bugs that developer self-testing had been missing.
On The Mortgage Office, a loan management platform we joined in 2025, QA joined backlog grooming and retrospectives from the start of the engagement — it's early, but the process changes landed alongside a regression cycle cut from 2 days to 3 hours.
This setup is still not the norm. The World Quality Report 2024–25 found that only nearly half of organizations integrate quality engineers directly into their agile teams — which means the other half are paying UAT prices for defects that a grooming question would have caught.
Ceremony time is a real cost, and no case we've published measured the developer hours added by these meetings — don't let anyone tell you participation is free. The way to keep it cheap: scope QA participation to stories with cross-team dependencies or unclear requirements first. A copy change doesn't need a tester in the room. An integration between your billing service and a third-party API does.
Moving execution from UAT to integration and staging
Participation earns its keep at the requirements end. The other half of shift-left is mechanical: run the same tests you already run, just in an earlier environment.
On both the CTEM platform and the art management and sales platform we support for a New York gallery network, the vehicle was a redesigned Jira workflow. Before, a ticket went In Progress → Done → UAT, and QA saw it at the end. After, the workflow made testing a first-class state in the development cycle:
In Progress → Code Review → Done → UAT
In Progress → Code Review → Ready for QA (integration)
→ QA in Progress → Verified on Staging → UAT
The point of the diff isn't the state names — it's that a ticket can no longer travel from code review to UAT without passing through an environment where QA executes against it. On the art platform this was paired with a unified user story template, and the combination cut lost and unclear tickets by 95%.
The prerequisite people skip: staging has to be representative. Environment parity is not a footnote here — if staging runs different data, different integrations, or a different config than production, "verified on staging" is a false signal and you'll pay for it twice: once maintaining staging, once re-finding the bugs in UAT anyway. Budget parity work before you move execution, not after.
Where the time comes back
So why doesn't all this added activity slow the team down? Because earlier detection deletes the rework loop, and the rework loop was where the time was going.
The CTEM platform is our primary case: since 2022, with one manual QA engineer, early defect detection increased 80%, overall testing time decreased 40%, release velocity increased 30%, and the ticket reopen rate dropped 80% — alongside 1,200+ test cases at 90% coverage. On the art platform, since 2023, also with one manual QA engineer: early-stage detection up 60%, testing time down 40%, release velocity up 30%, regression risk down 70%.
Two caveats we'd want stated if we were reading this. First, these are single-team observations against each team's own baseline, not controlled comparisons — and the two cases report several near-identical figures, which is a reason for caution about precision, not a reason to double-count them as confirmation. Second, the CTEM gains aren't attributable to shift-left alone: bug-report standardization and AI-assisted test case and test data creation changed in the same period. What the cases do support is the direction: moving mostly-manual QA attention earlier, with one to three engineers, correlated with less total testing time, not more.
Notice what's absent from the sequence: a unit-test pyramid mandate, a developer-owned-testing reorg, a six-month automation build-out. Automation showed up later in several of these engagements — SimpliField's regression flow now runs 4× faster with automation in place — but it was never the entry ticket. If your shift-left plan starts with "first we automate everything," you've scheduled the payoff behind the most expensive step.
When shifting left costs more than it saves
Shift-left relocates verification; it doesn't eliminate later stages, and it isn't free. Skip it, or scope it down, when the math doesn't work:
- Trivial, low-dependency stories. A QA engineer in grooming for every copy tweak and padding change is overhead with no risk to surface. Route participation by risk, not by ritual.
- Staging you can't afford to maintain. If you can't keep staging representative, verification there is theater. Fix parity first or keep the checkpoint in UAT where the environment is at least honest.
- Teams that ship faster than they specify. If you're a three-person team iterating on a prototype daily, formal acceptance-criteria review will stall you. The Catalyst-style spec layer paid off on a five-year engagement with a regulated-adjacent product, not a weekend MVP.
- Genuine user acceptance. UAT still matters for the thing it's named for: users accepting that the product does what they need. Shift-left empties UAT of bug-hunting so it can do that job; it doesn't replace it.
The objection we started with — "we don't have time for QA in planning" — has the causality backwards. The slow part was never the testing. It was the rework loop that late testing creates: the reopened tickets, the context-switched refixes, the stories that take two weeks to pin down because nobody asked the five questions up front.
You don't need a transformation roadmap to test the claim. Reach for this when testing on your team happens mostly in UAT and tickets routinely come back reopened: put one QA engineer in your next grooming session with one job — review the acceptance criteria of the riskiest story before anyone writes code. Skip it when your stories are already unambiguous, your defects are already caught at integration, and your reopen rate is already flat — at that point you've shifted left, whether you called it that or not.
Top comments (0)