TL;DR: The average team has automated 57 percent of its tests, per the 2026 Sembi Software Quality Pulse Report, but that number hides where the automation actually gets written: a sprint after the feature ships, not during it. Teams call this the "Sprint N-1" lag, automation that always trails development by one cycle, so every release ships on manual testing or no testing at all, and coverage only catches up once the code it is testing is already in production. Closing that gap means generating tests from the same artifacts developers already work from, Figma designs, acceptance criteria, API contracts, instead of waiting for a finished UI to automate against.
Quick answers
What is in-sprint test automation?
In-sprint test automation means writing and running automated tests for a feature within the same sprint that feature is built, instead of the next one. A feature gets coded, tested, and automated together, so the sprint that ships the code is the same sprint that ships its test coverage.
What is the "Sprint N-1" problem?
Sprint N-1 is shorthand for automation that always trails development by one sprint. QA can only start automating a feature once it is fully built and merged, which pushes the actual test-writing into the next sprint's capacity. By the time coverage catches up, two or three more features have already shipped ahead of it, and the backlog never actually closes.
Can test automation realistically be generated before the UI is finished?
Yes, for a growing share of cases. Acceptance criteria and Figma designs describe the expected behavior and layout before a single line of UI code is written, which is enough structure for AI-assisted tools to draft test cases against. Those drafts still need a human review once the real UI exists, but the first draft no longer has to wait for it.
The Sprint N-1 Trap: Why Teams Fall Behind on Automation
In-sprint automation is the sprint-level version of a broader shift-left testing principle: catch defects as close as possible to the moment they are introduced. The trap most agile teams fall into is a handoff that quietly breaks that principle on a two-week clock. Dev builds the feature in sprint N. QA cannot meaningfully start automating it until the code is merged and deployed somewhere testable, which is often days before the sprint even ends. Whatever automation work is left over gets carried into sprint N+1's capacity, competing with that sprint's own new features for the same hours.
That single sprint of lag rarely stays a single sprint. If sprint N+1 also ships new features on schedule, its own automation backlog stacks on top of the carried-over work from sprint N, and the gap compounds instead of closing. A few sprints in, the team is not one sprint behind on automation, it is three or four, and every release in between shipped on manual regression testing squeezed in at the last minute, or on no regression testing at all.
The lag is not just a scheduling annoyance, it changes what bugs actually get caught before release. Teams that automate within the sprint, rather than after it, tend to catch defects significantly earlier in the development lifecycle than teams relying on end-of-sprint manual testing, simply because the person who just wrote the code is still available to fix what the test finds, instead of a defect surfacing weeks later against code someone has since moved on from.
Autonomous Test Generation from Figma Designs and Acceptance Criteria
The reason automation has traditionally waited for a finished UI is simple: you cannot write a locator for a button that does not exist yet. But a button's existence, its label, its expected behavior when clicked, is usually described twice before it is ever built, once in the acceptance criteria and once in the Figma design. Both are structured enough for an AI-assisted tool to draft test scenarios against, well before the first line of UI code is written.
Acceptance criteria written in a Given, When, Then format map almost directly onto a test scenario: the "Given" sets up state, the "When" is the action a test script performs, the "Then" is the assertion. Writing acceptance criteria this way, which most agile teams already do for the sake of clarity, means a usable first-draft test scenario exists the moment the story is written, not the moment the story is done.
Figma designs add the piece acceptance criteria usually leave out: what the screen actually looks like and where things sit on it. A design file's component names and layer structure give an AI-assisted tool enough to draft the shape of a UI test, which fields exist, what a success state versus an error state should show, even though the exact selectors still need to be finalized once real markup exists. The draft is not the finished test. It is a head start that turns "start automating" from a task that begins after code freeze into one that begins the day the story is designed.
Creating Codeless API and UI Contracts Before Backend Code Is Merged
Frontend and QA work waiting on a finished backend is one of the most common sources of the Sprint N-1 lag, and it is also one of the most avoidable. Consumer-driven contract testing solves this by having the frontend and backend agree on the shape of a request and response, the contract, before either side finishes building. The frontend and its tests are built and validated against that agreed contract. The backend is built and validated against the same contract independently. Neither side blocks on the other actually being done.
"Codeless" is what makes this realistic inside a sprint instead of a separate integration project. Defining a contract by hand, in code, across every endpoint a feature touches is its own significant task, one teams under sprint pressure tend to skip. A codeless approach lets a QA lead or product owner define the expected request shape, response shape, and status codes for each scenario through a visual interface instead, the same plain-language approach that makes acceptance criteria usable as test scenarios in the first place, and generates the enforceable contract and matching mock responses from that definition.
The payoff shows up immediately: UI automation can run against the mocked contract response the moment the frontend has something to render, not the moment the backend team merges. When the real backend is ready, the same tests point at the real endpoint instead of the mock, and any mismatch between what was agreed and what was actually built shows up as a failing test rather than a bug discovered in staging.
Definition of Done Checklist for True In-Sprint Automation
A story is not actually done in the same sprint it ships just because the automation work started that sprint. It needs a Definition of Done that treats test coverage as a release blocker, not an aspiration. Five conditions worth adding to that checklist:
- An automated test exists for every acceptance criterion, not just the happy path. A story with three acceptance criteria and one passing test is not done, it is a third done.
- Tests run in the same CI pipeline as the code, on every pull request, not queued for a separate automation sprint later. A test that is not wired into CI yet does not count as coverage.
- The test is authored or reviewed by someone on the story's own team, not handed off to a separate automation backlog where it competes with every other team's stories for priority.
- Any UI change that would break an existing locator gets that locator fixed in the same pull request, not left for whoever notices the test went red next sprint.
- Coverage is visible on the sprint board itself. A story cannot move to Done without a green pipeline run attached to it. Aiming for 60 to 80 percent of critical test cases automated within the same sprint is a realistic target for a mature agile team, not 100 percent; some exploratory and edge-case testing will always trail into the following sprint on purpose.
Autonomous test generation only closes the Sprint N-1 gap if the tests it drafts do not need a rewrite the moment the real UI ships. ContextQA's platform lets your team author tests in plain English against acceptance criteria as they are written, then point that same test at the finished screen instead of starting over. See it on a 15-minute demo.
Frequently Asked Questions
Does in-sprint automation work for teams with no separate QA role?
It usually works better. The Sprint N-1 lag is largely a handoff problem, a separate team waiting for another team to finish. When the same engineer who writes the feature also writes its test, there is no handoff to wait on, and the automation naturally lands in the same sprint as the code.
What happens if acceptance criteria change mid-sprint?
Regenerate the affected test scenarios against the updated criteria. Because a criteria-driven draft test is cheap to produce in the first place, a mid-sprint change is a re-draft, not the loss of hours of hand-written locator work.
Is 100 percent in-sprint automation a realistic goal?
No, and treating it as the target usually backfires. Reserve deep exploratory testing and rare edge cases for dedicated time outside the sprint clock. The realistic target is critical-path coverage, the acceptance criteria and the core user flows, landing in the same sprint every time.
Bottom Line
The Sprint N-1 lag is not a staffing problem, it is a sequencing problem: automation waits for a finished UI and a finished backend when it could be starting from the acceptance criteria, the Figma design, and an agreed API contract instead. Generate the first draft early, let a human refine it once the real thing exists, and hold every story to a Definition of Done that will not let coverage slip into next sprint's backlog. Do that consistently and the gap between shipping a feature and trusting it stops being a sprint wide.
