How AI-led testing should actually be done (and where teams get it wrong)

There's a lot of noise right now about "AI testing," and a good chunk of it oversells what's actually happening under the hood. So let's talk about what good AI-led testing actually looks like versus where teams get tripped up.

• Where it goes wrong #1: treating AI as a replacement for test strategy. AI can help generate and maintain test cases, but it can't decide what actually matters to your business. If nobody's thought through which processes are high-risk and business-critical, AI will happily generate coverage for everything and nothing important gets prioritized.
• Where it goes wrong #2: ignoring the data problem. A lot of AI testing tools focus entirely on the UI layer — recognizing buttons, fields, labels — while still running against static or synthetic test data. That's a shaky foundation. If the data behind your test doesn't reflect real referential integrity, you can pass a test that would fail against actual production-like data.
• Where it goes wrong #3: no human review loop. Self-healing sounds great until a script silently "heals" itself into testing the wrong thing entirely — clicking a similar-looking button that isn't actually the right one. Good AI-led testing has a review step where meaningful changes get flagged for a human to confirm, not silently auto-approved.
• What good looks like: business process logic and test data are kept separate so AI-driven adjustments happen at the right layer. Test data comes from live, real referential sources, not static fixtures. And AI-generated coverage is reviewed against actual risk priorities, not just generated in bulk because it's easy to generate.

The goal isn't "let AI run testing." It's "let AI remove the repetitive, low-judgment work so humans can focus on the parts that actually need judgment."