AITest creationExploratory

How do you generate test cases automatically with AI?

Point an agent at a running application and it crawls – reading screens, following links, filling forms – and builds a knowledge graph of the product. From that it proposes test cases as goals in plain language: "a new user can sign up and reach the dashboard." You review the list, keep what matters, delete what doesn't, and edit the ones that are close. What you still decide is which cases matter: an agent can tell you everything the product makes possible, not which of those things would cost you a customer. That judgement stays with you, and it is the part worth your time – it is also the first of the four decisions in our guide to software testing strategies.

Book a demo

Sub-use-cases

  • AI Chat

    Describe a goal in plain language and QA.tech generates the test.

  • Crawler / coverage gaps

    QA.tech crawls your app and suggests cases for untested areas.

  • Issue tracker

    Connect a Linear or Jira ticket and its acceptance criteria become tests.

  • PR / MR review

    The GitHub or GitLab integration analyses the code diff on every pull request, creates tests for untested changes, runs them against the preview deployment, and posts a review comment with results.

  • REST API

    Trigger test creation or runs programmatically from any CI/CD system (GitHub Actions, GitLab CI, Bitbucket and others).

  1. 01

    What AI can generate tests from

    Four confirmed sources. A crawl of the live app, which needs nothing from you but a URL and a login and is where most teams start. A Jira or Linear ticket's description and acceptance criteria, found from the key in a PR title, branch or commit – with real limits: it fetches that one ticket, and does not read sprints, release versions, epic hierarchy, custom fields, attachments or comments. Requirement docs, API docs and help pages you add to the Knowledge Library as crawled URLs or free text. And a plain-language request in the chat assistant: "generate 5 tests for the checkout flow" returns suggestions you review, edit and add.

  2. 02

    How does AI generate test cases?

    The agent needs to know how to get somewhere before it can test what happens there. Daniel Mauno Pettersson, QA.tech's CEO, describes the mechanism: "if you task an agent with something simple, like send an invoice, and it's presented with a login screen, how will it know that it first needs to log in and then go to this page? We solve this by building up this knowledge graph. So it's essentially a site map on steroids, where we have collected every screenshot, every PR, every conversation you have had with our agent." That graph is what turns a goal or a ticket into step-by-step cases ready to review, and it is what agentic testing runs on. It also has an edge the docs name plainly: the agent can't see behind what we call soft walls. It doesn't know what's behind a login, or how to edit a user, until a test builds that path out.

  3. 03

    When to generate tests with AI

    When coverage lags feature velocity, when standing up tests on an app that has none, or when you want a regression suite to grow without an authoring queue. The narrowest and most useful trigger is the diff: on PR testing the agent reads the changed files to choose what to exercise, then generates and runs the cases that change made relevant.

  4. 04

    Who uses AI test generation

    QA engineers, developers and PMs who need coverage without scripting – and, in practice, anyone who has been bitten by the flow nobody remembered. As a director of engineering at a US healthcare-software company put it: "it's very easy for us to forget a specific flow. But if the agent can look at all of them, it has the collection. And it's going to tell us everything that the code makes possible." The value isn't that the agent writes the test. It's that it enumerates what you would have forgotten.

  5. 05

    A worked example, end to end

    Take a registration flow. The crawl finds the form, the validation states and the confirmation screen, and proposes cases: a valid sign-up reaches the dashboard, a duplicate email is rejected with a message, a weak password is refused, an expired invite link fails cleanly. You keep three, delete the one that tests a rule you don't have, and edit the sign-up case to add the verification point that actually matters – that the welcome email is what the new user receives, not just that the page changed. That edit is the work. The authoring isn't.

  6. 06

    Reviewing what the agent proposes

    Fredrik, who runs onboarding conversations at QA.tech, frames it as a new colleague rather than a configuration job: "the biggest bottleneck when you're getting started is that it's a new colleague who doesn't know your product, one hundred percent. It's better to be over-explicit and ask it to verify that it knows what it's actually doing." A QA specialist at a Nordic public-transport operator described both sides in one breath: "it's very good, because it finds its own ways of how to write the test cases, so you need to do very little and it helps a great deal. But there have been a few times it has approved test cases that we don't really feel it should have approved." Expect to verify the first few runs step by step, expect to add explicit verification points where the outcome matters, and expect your prompts to get shorter as you learn what the agent needs.

  7. 07

    What AI-generated test cases are bad at

    Restraint, first. A test manager at a UK fintech asked the right question about a crawl at scale 10: would it return a million scenarios, "because AI tends to return four times what's actually needed?" It also doesn't know your business rules unless you tell it, and it can't tell a deliberate quirk from a bug. Then the sharpest objection, from a lead developer at a US aircraft manufacturer: "it happens sometimes that we make a mistake and then we make a test to cover that mistake, but the test says that the mistake is fine." That is true of tests generated from code. Tests generated from the running product and from stated requirements check what a user can accomplish instead, which is why the diff only chooses where our agent looks and never decides what correct means.

  8. 08

    How QA.tech helps

    Authoring is the real bottleneck in growing coverage. QA.tech generates the cases – from goals, crawls or tickets – so your job is reviewing, not writing.

Companies running ai test generation with QA.tech

FAQ

Common questions

Can QA.tech generate tests from a Jira or Linear ticket?
Yes – QA.tech reads the ticket's acceptance criteria and proposes matching test cases.
Can QA.tech create tests from a pull request?
Yes – the GitHub or GitLab integration analyses the diff on each PR, generates tests for the untested changes, runs them against the preview deployment, and posts the results as a review comment.
Can QA.tech generate tests through an API?
Yes – the REST API triggers test creation and runs from any CI/CD system.
Can AI generate test cases from a Jira ticket or a requirements document?
Yes, and it is usually better than generating from a crawl alone, because a ticket says what the change was for. The crawl tells the agent what the product can do; the ticket tells it what someone intended. Given both, the proposed cases track the requirement rather than the implementation.
Do I have to review AI-generated test cases?
Yes, and budget for it properly on the first pass. Expect to check the first few runs step by step, and to add explicit verification points where the outcome matters. Teams tell us the review burden drops sharply once they have learned what to specify.
Will AI-generated tests test the wrong thing if the code is wrong?
They can, if they are generated from the code. A test written from an implementation inherits that implementation's mistakes and then certifies them. Generating from the running product and from stated requirements avoids that, because the check is what a user can accomplish, not what the code claims.
How many test cases should AI generate?
Fewer than it wants to. Ask an agent to cover an application exhaustively and it will propose far more than you will maintain or read. Start from the flows you would stop a release over, get those solid, then expand. Coverage you don't look at isn't coverage.

Related use cases

← Previous

Account & Profile Settings Testing

Next →

Analytics & Tracking Event Testing

Your team moves fast. Can your testing keep up?

QA.tech agents test your product autonomously, so moving fast never means shipping broken. See how it works in a 30-minute demo.

Get a demo