AI Writes the Tests. Judgment Decides Which Ones Matter.

The first time I asked an AI tool to "write tests for this feature," I got forty test cases in ten seconds. It felt like magic until I read them. Half were duplicates of each other, a few tested things the feature doesn't do, and none of them covered the one scenario I was actually worried about.

That's when I stopped treating AI as a test generator and started treating it as a fast, well-read assistant that needs direction. The difference in results was large.

Give it context, not just a request

"Write test cases for login" produces generic output. Pasting in the acceptance criteria, the API spec, the known constraints, and the areas that have broken before produces something much closer to usable. The more the model knows about your actual system, the less it has to guess. I treat a prompt the way I'd treat a ticket handed to a new teammate: what is this, what matters, what's already known.

Where it earns its keep

Brainstorming is the clearest win. Ask for edge cases and negative scenarios on a feature and it will surface angles I'd have reached eventually, but faster. It's also good for drafting automation boilerplate, converting a manual test case into a Playwright or REST Assured skeleton, generating varied test data, and explaining unfamiliar code or a confusing stack trace. All of that is speed work, and speed is what it's good at.

Where I keep my own judgment

Deciding what's worth testing stays with me. The model doesn't know which module was rewritten last sprint, which API flakes under load, or which scenario maps to a real customer complaint. Neither do I get to skip reading what it writes. Generated tests can assert what the code currently does rather than what it should do, which means a bug can be written into a passing test. I review AI output the way I'd review a pull request from someone new: useful, but never merged on trust.

Habits that keep it honest

A few rules I stick to: run every generated test and watch it fail first when it should, since a test that can't fail proves nothing; never paste sensitive data or proprietary code into a tool my company hasn't approved; and verify any claim about how a library or API behaves against the real documentation, because confident wrong answers are the model's signature failure.

The shape of it

Used well, AI doesn't replace the thinking in QA. It clears the repetitive parts so there's more time for the thinking. The testers who get the most from it aren't the ones who ask for the most output. They're the ones who know exactly what good output looks like, and can tell the difference in seconds.