When did you last test your product end to end?

Ask yourself honestly: when was the last time someone walked your entire product, end to end, the way a real person would?

For most teams the honest answer is "when we launched it." Then came new features, last-minute fixes, a library upgrade. Each one got reviewed on its own. The full journey, never again.

That isn't negligence. It's arithmetic. Manually testing thirty flows every time you touch the code costs days, and nobody has days. So you test what changed and trust that the rest is still standing.

The problem isn't the code. It's the behavior.

There's a class of bug no code review catches, because the code is fine.

A few days ago we audited indexing on our own site. Google reported 75 pages out of the index. One cause was a redirects file: old URLs that were supposed to send visitors to the new ones with a 301. The file was written correctly. The commit message said exactly what it did. It passed review.

In production, all fifteen returned 404. They had been doing it for months.

The reason was an interaction between two framework layers: one rewrote the path before the other could read its redirect table. Each piece, on its own, correct. Together, quietly broken. Nothing in the code gives it away. The only way to see it is to request that URL and read what comes back.

That's an end-to-end test. Not "is this function written well?" but "does the product do what it says it does?"

What AI changed (and what it didn't)

Nearly every team is already using it. A 2026 report puts AI adoption in QA at 76.8%. But only 17% say it delivered significant gains, and 61% report more QA workload, not less, because of the code AI itself generates.

That gap has an uncomfortable explanation: 70% of teams using AI in QA use it only to generate test cases. You ask for a thousand tests and you get a thousand tests. Now you have a thousand tests to maintain and the same question you started with about whether the product works.

Generating tests is the wrong job. The one that moves the needle is running the product and comparing what it does against what it should do.

It's a fundamental difference. A test case is an assumption about behavior. Opening the browser, walking the flow and reading the actual response is evidence.

How we do it

Our internal standard is simple, and we apply it before saying "done":

• Reproduce the broken case first. If we never saw it fail, we don't know what we're fixing.
• Walk the flow in a real browser, as a user: clicks, forms, console errors, network responses.
• Verify what we didn't touch, too. This is where AI wins: the full sweep costs minutes, not days.
• Be explicit about what couldn't be tested and why. An honest "I didn't verify this" beats an optimistic "done."

In the audit above, verification meant forty URLs checked one by one: the broken ones and, more importantly, the ones that already worked and must not break. By hand, nobody does that on every change. It's exactly the work that gets skipped under deadline, and exactly where regressions slip through.

The same logic applies to security. An automated sweep reads every file, every dependency and every commit in the history without getting tired or assuming anything. A human checks where they suspect. And exposed credentials are rarely where you'd suspect.

This does not replace QA

We want to be clear, because the fashionable narrative says otherwise.

AI doesn't decide what matters. It doesn't know that one form brings in 80% of your leads, or that a director opens that report every Monday. It can't tell a cosmetic bug from one that costs you sales. It doesn't define what "correct" means for your business.

All of that is judgment, and judgment is human.

What changes is the division of labor. The person decides what to test, what correct looks like, and how serious each finding is. The machine does the exhaustive, repeatable, boring pass that simply wasn't happening before. QA stops being the bottleneck and becomes the judgment that directs the testing.

Our result: we test more often, cover more flows, and catch things that used to surface in production. Not because the team got smarter, but because the cost of checking dropped far enough that we actually check.

Why it pays, in money

There's an old rule of thumb in the industry, roughly 1 : 10 : 100. A bug you catch while writing the code costs one unit. In testing, around ten. In production, close to a hundred.

The exact figures are debated and depend on context. The shape of the curve isn't. And the curve understates the part that hurts most: the angry customer call, the order that never registered, an entire afternoon spent putting out a fire instead of building.

That's the real calculation. Not "what does testing cost," but "what does finding out late cost."

An honest question

If someone walked your entire product today, the way a user does, what do you think they'd find?

If that makes you a little nervous, that's the signal. It doesn't mean your team did a bad job. It means the full walkthrough hasn't happened in a while, and that's a solvable problem now.

At Avanzia we apply this to our own work first, then to every system we build. If you want to know what would turn up in yours, let's talk.