AI-Assisted Test Generation: What It Actually Does (and Doesn't)

• —Reads requirements, user stories, tickets and API descriptions and proposes scenarios.
• —Suggests boundary values, negative cases and combinations a person might not list.
• —Drafts automation code for scenarios in the framework you use.
• —Groups near-duplicate cases and points out gaps against the written requirements.
• —Updates drafts when a requirement changes.

It works well when the inputs are good

Clear acceptance criteria, an accurate API description and a short list of the rules that really matter all improve the output. The reverse also holds: if a requirement is ambiguous, the draft will quietly pick one reading and present it with confidence.

• —Know your business rules. Discount stacking, eligibility, regional differences and exceptions live in people's heads and in the conversations around the ticket.
• —Judge risk. It cannot tell which scenario matters most to your customers or your contracts.
• —Judge usability. Whether something is confusing or unpleasant is not in the specification.
• —Know what is missing. It works from what is written; the unwritten expectation is exactly what experienced testers add.
• —Ensure meaningful coverage. A long list of cases is not the same as a meaningful one.

A common failure is the test that passes because it checks very little. Imagine the story "A user can apply one promo code at checkout". A first draft might look like this:

// Draft produced from the storytest("applies promo code", async ({ page }) => {  await page.goto("/checkout");  await page.getByLabel("Promo code").fill("SAVE10");  await page.getByRole("button", { name: "Apply" }).click();  await expect(page.getByText("Promo applied")).toBeVisible();});

It runs, it passes, and it proves almost nothing: it checks that a message appeared, not that the total changed correctly, and it says nothing about the second code the story implies should be refused. A reviewer improves it:

// Reviewed: asserts the outcome and the rule in the storytest("one valid promo code reduces the total once", async ({ page }) => {  await page.goto("/checkout");  const before = await readTotal(page);   await applyPromo(page, "SAVE10");  await expect(page.getByText("Promo applied")).toBeVisible();  expect(await readTotal(page)).toBe(before - discountFor("SAVE10", before));   await applyPromo(page, "EXTRA5");  await expect(page.getByText("Only one promo code can be used")).toBeVisible();  expect(await readTotal(page)).toBe(before - discountFor("SAVE10", before));});

The difference is not the tooling. It is someone asking "what is this test really claiming?", which is a question about the business rule, not about code.

1. Does each test trace back to a real requirement or risk?
2. Is the expected result stated independently, rather than copied from what the product happens to do today?
3. Does it assert the outcome that matters, not only that something appeared?
4. Is the data and state under control, so the test is repeatable?
5. What important cases are missing, especially negative and boundary cases?
6. Should this be automated at all, or is it better explored by a person?