You don't need a survey to know that something's off with your testing. You can actually notice it yourself. Release dates keep being pushed. In stand-ups, someone shrugs at yet another red build. And then there's that late-night Slack thread buzzing at 11 p.m., with everyone trying to figure out whether a failure is real or just noise.
Somewhere along the way, quality assurance (QA) has quietly become the slowest part of your release cycle, and every single fix you make feels like you are patching a leak on a sinking ship.
Before you throw more tools or people at this problem, make sure you take a step back and run a proper QA process audit. You don't need a full-scale consultancy to do this, just an honest, structured walk-through of your process that you can wrap up in an afternoon.
This article brings you the same audit a seasoned QA consultant would conduct, compressed into five questions and three fixes.
Recognize the Symptoms First
Before you begin the QA process audit, you need to be honest about whether you actually have a testing bottleneck. If you do, it usually looks like this:
- Release keeps getting delayed because QA hasn't signed off on it yet.
- Flaky tests are ignored.
- Manual regression takes two to five days per release.
- No one on the team actually trusts the test suites.
These issues aren't minor, especially since they compound over time, and when left unchecked, they increase the cost of engineering time, among other things.
Five-Question Audit
To get started, grab your engineering manager or QA lead. Set aside 90 minutes to work through these questions honestly and jot down the answers.
1. How long does it take from "code complete" to "deployed"? Where does QA sit in that timeline?
This tells you how fast you're actually shipping changes. If QA takes three days in a five-day cycle, testing is slowing everything down.
Look at your last ten releases and find the average. This number tells you a lot. High performing teams generally ship in hours. Most teams, however, take days, and a big chunk of that time is spent waiting for testing.
2. What percentage of your test failures are real bugs versus false positives?
Check your last two weeks of CI runs. Count how many builds failed, and see how many actually needed a code fix. If most failures pass after a retry, you have flaky tests.
These tests should be less than 2%. Unfortunately, many teams are at 10% or more, and they don't realize it.
3. How many hours per week does your team spend maintaining tests versus writing new ones?
Ask a few engineers and calculate the average based on their answers. If more than 30% of their time is spent fixing tests, that's a problem. It usually means tests break too easily, like when they depend on UI elements that change often.
4. How many production bugs landed in areas you thought were tested?
Look at your recent production issues. Check if those areas underwent tests. If bugs still slipped through, your tests aren't covering real user behavior. Though tests exist, they're not testing what actually matters.
5. Could a new team member run your test suite without being onboarded to the project?
If the new additions to your team need to ask people for access, setup steps, or hidden tricks, your tests aren't easy to use. A good test suite should run without special knowledge required. If it doesn't, your testing depends too much on people rather than the process.
Interpreting Your Answers
Each question points to a specific root problem, so don't rush past this step. The fixes only work if you know what's actually slowing you down.
1. Slow feedback loops
This usually means testing only starts after development has been finished. Everything piles up at the end and waits on QA as releases drag out.
The solution isn't to hire more QA engineers. You should actually be testing earlier, in pull requests. This is what "shift-left" really means: testing sooner rather than later.
2. Selector-coupled tests
This means your tests fail even when nothing is broken. Most of the time, it's because tests depend on fragile things like CSS selectors, page layout, or fixed wait times. Small UI changes break tests, even when the feature still works.
3. Manual bottlenecks
If your team spends too much time fixing tests, that's a sign they are brittle. Every small UI change breaks something, and instead of helping the team move faster, the tests end up slowing everyone down.
At that point, your test suite stops being a safety net and starts acting like a manual bottleneck.
4. Coverage gaps
This usually means your tests focus on what's easy to cover, not what actually matters. Teams often over-test simple flows and skip the complex ones where things tend to break. For example, login gets tested repeatedly, while something like a multi-step checkout or edge cases get ignored.
Instead of asking yourself where you have tests, you should look at where bugs actually occur and cover that area.
5. Undocumented process
This usually means too much knowledge lives in people's heads. Maybe someone needs special access or there's a setup trick nobody has documented. All this works until that one person leaves; then things start to slow down and break.
When you match your answers to these problems, you'll probably realize you're hitting two or three of them at once, but that's normal. What you want to avoid is fixing each symptom separately, instead of recognizing they all come from the same root cause.
Three Highest-ROI Fixes
You can't fix everything at once. Even trying to do so is likely to make things worse. Instead, you can start with these three moves in this specified order. They are expected to deliver the biggest impact for the least effort.
1. Automate the regression bottleneck first
If manual regression testing takes three days, that's three days added to every release. Every time. That delay won't go away unless you fix it.
So that's where you should start. However, don't just convert your manual tests into Selenium scripts if that is not the best option for your use case. That will just create another problem: fragile tests that break whenever the UI changes. And you'll end up trading one bottleneck for another.
A better approach is to use AI agents that test the UI like a human would. Instead of relying on fixed selectors, they actually understand what the page is doing. As a result, your tests won't break every time a button moves. This is how Upsales has replaced over 320 hours of manual testing with agents.
2. Move testing to the pull request
If you run tests on a nightly basis, feedback likely takes a day or more, which is slow. However, if you were to run tests on every pull request, feedback would take minutes. And that's what you want: to catch issues before code is merged, not after it ships.
But there's a catch: this only works if your tests are fast and reliable. Slow or flaky tests at the PR stage are worse than no tests. The developers will ignore them, and once that starts to happen, your testing loses its value.
More importantly, you should focus on running tests in parallel to make them faster and fixing flaky tests to make them reliable. This kind of improvement compounds and improves the QA process significantly.
3. Replace your most-maintained tests with agentic equivalents
Pull a report and find the ten tests that broke most often last quarter. These are usually the ones quietly draining your team's time, and at some point, it no longer makes sense to patch them up over and over again.
Instead, you should replace them with AI-driven tests that adapt when the UI changes. Rather than relying on fragile rules, these tests learn how your application behaves. This is where things start to change:
- Tests stop breaking on small UI updates.
- Engineers spend less time fixing tests.
- Coverage improves instead of slowly getting worse.
With this, testing workflow is optimized, and your team starts go get their Friday afternoons back.
Wrap-up
Ta-da! You've conducted an audit based on your own data. What you do next depends on where you're starting from. If you're:
- Moving from manual regression to automation, then check out the "From Manual to Autonomous QA" guide.
- Building a business case, use the CTO playbook for ROI, rollout strategy, and stakeholder conversations.
Oh, and one more thing: make sure to run this audit every quarter. QA debt builds quietly, and once it catches up, it slows everything else down. The fastest teams are those who spot problems early and fix them before they escalate. If that sounds familiar, it might be worth booking a quick demo to see how this works in practice.