At the start of a new sprint, velocity is generally great. Developers build features, mark them as “done,” and hand them off to QA. But then QA start sending tickets back, so devs have to put aside new features to fix bugs. As soon as they've sent those off, more bugs arrive. Suddenly, the team is no longer shipping as fast as before.
On the surface, it seems to be the testing team’s fault; in fact, it almost looks like they are deliberately blocking releases. But, QA isn't the problem. Outdated QA processes are.
In this piece, we'll discuss the handoff pattern, why it’s so common, and why it cripples release speeds. Then, I'll offer three alternative patterns.
But first, let's take a closer look at the handoff itself.
What Is the Handoff Pattern?
Handoff is the process of passing a completed feature from the development team to the QA team. The developer marks a feature as “done" and opens a PR. The testing team picks it up two days later and finds bugs. They send it back to the developer, who switches back to the old code to fix the bugs. Then, they hand it to QA to run tests again. Rinse and repeat.
Each round trip causes a multi-day development delay, not to mention the constant context switching that drains developers and costs hours in productivity.
Despite all the complaints and the constant reminders to do shift-left development, many teams are still caught in the throw-it-over-the-wall pattern. Projects begin great, with everyone following best practices as much as possible. But down the line, dev teams end up stuck fixing bugs.
Why Handoff Persists
The handoff pattern exists because of how we structure teams and workflows. Think of the waterfall model, which goes like this for every new feature:
Requirement analysis → design → development → testing→ deployment → maintenance
The main thing here is that testing comes after development.
Now, quality gates are absolutely necessary. But when they show up once, at the end of development, they become bottlenecks. Unfortunately, many orgs are structured around this workflow. They’ve got separate teams, separate backlogs, and separate reports. The dev team does their stand-ups alone, and QA and stakeholders are both off in entirely different meetings.
Even the teams that call themselves “agile” tend to fall in the same pattern: that is, they complete the sprint, and hand it over to QA. They make sure their team moves as fast as possible, and let the next team in line worry for themselves. In this common setup, QA is always downstream, which means new untested features start to pile up. These delays have nothing to do with productivity, though, they are simply a part of the system.
This leads us to another important reason why handoff persists: incentive. Many dev teams are evaluated based on how quickly they push features, while QA teams are evaluated based on how many bugs they catch.
Luckily, this can be fixed.
Implementing any of the following patterns doesn’t mean you’ll have to reorganize your entire team. Each of them represents a small, impactful change in how your org can build and test new features.
Pattern 1: PR-Level Automated QA
When your team implements PR-level QA, every pull request triggers a suite of automated tests. The developer receives test results before requesting a code review.
With QA.tech, every pull request will trigger the AI agent to run dynamic exploratory and regression tests on your changes against a preview URL or a Vercel build. Then, it will send a detailed report to the pull request's comment section.
There’s one important detail you should keep in mind: the agent runs visual tests, interacting with your app as a real user would. That’s why it needs a preview to work with.
QA.tech PR review screenshot
PR-level automated QA removes the handoff delay issue entirely. Since the developers can see tests run in real time, they don't have to wait days to hear from the QA team. Also, there will be no more context switches. When a feature is marked as “done,” it will actually be done.
For the QA team, PR reviews remove tedious, manual work. Test engineers no longer have to spend hours setting up environments or creating test cases. They can focus on more advanced work, such as developing test strategies and reviewing reports.
Pattern 2: Quality as a Merge Requirement
Next, you can require that a new PR should pass quality tests before it can be merged. It is almost the same thing as a code review, except you won't pull a senior dev from their work or hand it off to the QA team. You just have to add QA.tech to your CI/CD pipeline and configure it to run tests whenever a merge request is opened on a specific branch. Then, you implement the blocking mode to merge only if new code passes all defined tests.
The change is pretty significant. First, the handoff is gone. The dev gets immediate feedback on whether their code covers all required bases. Second, the agent runs automated regression tests to rule out breaking changes. Third, the QA team shifts from testing to defining what the agents should verify. Their value goes up because they now design tests, not just execute them.
Your team can prioritize tests and focus on increasing test coverage. Also, anything that does get merged will be deployment-ready since the team will know that the merged code has been tested for regressions, feature requirements, and edge cases.
Plus, if you still have manual review somewhere in the deployment pipeline, the engineers will only look at the code after it has passed certain checks. This will minimize the need for multiple rounds of feedback and speed up sprints.
Pattern 3: Shared Ownership of Quality
When devs own QA processes, they write test intents for the features they build. And that's perfect because who understands their code better than them? The only thing the QA team needs to do is review test results and edge cases. They can lean on their quality-assurance experience and deep understanding of the user to ensure test coverage is complete and nothing important gets missed.
a list of test cases built around features
With this pattern, quality becomes a shared responsibility, and the QA team focuses on designing a system that ensures it. They are involved throughout the entire development cycler, and if testing is part of every step, the need for handoffs disappears.
However, if you want to pull this pattern off, your team needs a new mindset. Both developers and testers should move from incentivizing quantity to quality. Don't celebrate the number of shipped features; praise the features that don't require feedback iterations.
Stop clapping for the number of discovered bugs, and start clapping for a quality system that prevents them from showing up in the first place.
Wrap-Up
Handoff exists because teams are often forced to work in their own bubbles. The idea is that the builder should not be the tester. Hence, one team codes a feature and throws it to the testing team, which then tosses it back when something fails.
This separation creates a real problem because it distances devs from the idea of what a working feature should be. It also increases test workloads, promotes context switches, and slows sprint velocity.
All this to say something that has (rightfully) been said a million times: QA should be involved in every step of development, from requirements analysis to deployment.
Agentic autonomous testing makes shift-left, continuous testing more practical. Agents build tests around use and edge cases. Then, they run them on pull requests and merge requests to keep devs on track throughout the coding process.
Ready to finally eliminate handoff and oversee sprints that run smoothly from start to finish? Get a QA.tech demo.
