← Automation Arsenal
Field notes Stage 01 · Author
Case study · AI test authoring

Kane AIintent → test

Kane AI, LambdaTest's AI testing agent, turns plain-English intent into runnable test steps. I use it to get from acceptance criteria to a first draft fast, and I treat that draft the way I treat any pull request: it gets reviewed before it ships.

Watch a test get written ↓ Official site ↗
What it is
AI agent for planning and authoring tests
Input
Plain-English objectives and steps
Output
Test steps you can export as framework code
My rule
AI drafts. Humans approve.
How it works

Four steps from a user story to a test in the repo

The speed comes from the agent. The trust comes from step three.

1

Describe intent

Start from the acceptance criteria, written the way a product owner would say it.

2

Agent plans

The agent breaks the intent into navigate, type, click and assert steps against the real app.

3

Human review

I check each assertion against the spec, add the edge cases, and fix anything that tests the wrong thing.

4

Export and gate

Reviewed tests become code in the repo, follow its conventions, and run in CI like everything else.

Interactive · intent to test

Watch a draft become a trustworthy test

Pick a user story. The agent plans it, then the review step catches the one thing the AI got subtly wrong.

authoring sessionSimulated workflow · not the Kane AI UI
Plan IntentPlanReviewExport
Intent
    login.spec.tsExported · Playwright

    Pick a story to start.

    The code

    What a reviewed, exported test looks like

    Once it lands in the repo, AI-drafted code is held to the same standard as hand-written code.

    
import { test, expect } from "@playwright/test";

// The agent proposed the first case; review widened it into a table.
const cases = [
  { name: "wrong password", email: "ada@example.com", password: "nope", error: "Invalid email or password" },
  { name: "unknown email", email: "ghost@example.com", password: "Secret123!", error: "Invalid email or password" },
  { name: "empty password", email: "ada@example.com", password: "", error: "Password is required" },
];

for (const c of cases) {
  test(`login rejects ${c.name}`, async ({ page, context }) => {
    await page.goto("/login");
    await page.getByLabel("Email").fill(c.email);
    await page.getByLabel("Password").fill(c.password);
    await page.getByRole("button", { name: "Sign in" }).click();

    await expect(page.getByRole("alert")).toHaveText(c.error);
    // Added in review: the outcome, not just the message
    await expect(page).toHaveURL(/\/login/);
    const cookies = await context.cookies();
    expect(cookies.find((cookie) => cookie.name === "session")).toBeUndefined();
  });
}
    Same error message for "wrong password" and "unknown email" is deliberate: it stops account enumeration, and now a test enforces it.
    Where it fits

    Stage 01 of my quality pipeline

    Authoring comes first: better drafts in, faster, means more coverage by the time the execution stage runs.

    Trade-offs

    Where it shines, and what I guard against

    Strengths

    • Intent to first draft in minutes, which frees review time for the hard cases.
    • Wider coverage. It's good at proposing negative and boundary cases people skip.
    • More contributors. Manual testers and PMs can describe tests without writing code.
    • Exportable code keeps the tests in your repo, not only in a vendor's UI.

    Watch-outs

    • It asserts what it sees, not what the spec says. A bug can get "confirmed" as expected behaviour.
    • Data privacy. Prompts and test data must be synthetic, never real customer records.
    • Generated code needs shaping into the repo's fixtures and page objects before it's maintainable.
    • Cloud dependency and cost need to be weighed against the time saved.
    My rule of thumb

    AI drafts. Humans approve.

    AI makes writing tests cheap. It doesn't make knowing what to test cheap. That part stays with the engineer.

    Next: agents that act → Back to the arsenal
    • Every generated test is reviewed against acceptance criteria.
    • Assertions check outcomes, not just on-screen text.
    • Exported code follows repo conventions before merge.
    • Flaky means fixed or deleted, never ignored.