Skip to main content
Review proposed tests: cases grouped by use case, nothing added until you confirm

​
What Plan Generation Does

TestSprite’s testing agent takes what Feature Exploration observed in your app and plans test cases for each feature. The plan is what you review and edit before any test code is written.
UI plans are flow-grounded: each case follows a sequence of clicks, fills, and assertions the agent saw work during exploration, using your real button labels, URLs, and form fields. A plan row reads like “Verify a new user can sign up with a valid email and lands on the welcome screen”.
Nothing runs during plan generation. No browser actions are issued.

​
What Goes Into the Plan

Features exploration couldn’t reach get spec-based cases instead.

​
The Plan Structure

Each plan row is one test case with a title, description, and priority, plus a step list (Actions such as clicks, fills, and navigations, and Assertions to verify) revealed with the Show flow toggle.
A plan row with priority, test name, description, and its step flow expanded
Case count varies with the feature: a simple “Forgot Password” might get a couple of cases, a complex “Checkout” 10 or more.

​
Reviewing the Plan

The plan view lists cases grouped by use case. Each row shows checkbox · No. · priority · title · description.
1

Read the description, then Show flow if you need detail

The description is what drives generation. Click Show flow to see the Action / Assertion list; you can edit a step’s text right there.
A plan row with Show steps expanded, revealing its Action / Assertion list
2

Untick anything you don't want

Each row’s checkbox toggles one case; the header checkbox is Select All.
Per-row checkboxes and the header Select All toggle
3

Edit titles and descriptions

Test Name and Test Description are plain text inputs, and your edits feed straight into generation.
Test Name and Test Description edited directly as text inputs
4

Adjust priority if you want a case run first

Each row has a Priority dropdown (default Medium). Higher-priority cases run earlier.
Priority dropdown on a plan row
5

Add a custom case

Click + More Test Case at the bottom of the list (suffixed with the use case’s name) and fill in the new row. It’s generated with the rest.
+ More Test Case button adding an empty row at the bottom of the list
Selecting all is usually right on a first run. Pruning makes runs faster but doesn’t change correctness.

​
Adding and Refining in Natural Language

Ask in Chats to add a case or change several at once. TestSprite works out which feature the request applies to and updates the plan; you can review or undo before clicking Run all.
A case added for an explored feature inherits its observed selectors and flow; otherwise it’s spec-based.

​
What “Run all” Triggers

Clicking Run all adds the cases and starts the first run, which generates and runs each test. The plan is frozen at click time; later edits require a re-generation.

UI Test Generation & Execution

Each plan case becomes a runnable Python + Playwright test

​
Spec-Based Cases (Fallback for Unexplored Features)

When exploration couldn’t reach a feature (paywall, login failure, transient error), the plan for it is derived from your description and extra context instead of a real walk. These cases are best-effort:
  • Selectors or button labels may be wrong, since there’s no observed flow to ground them
  • They may miss flows you have, since only what you described is in the plan
  • They still run: selectors are resolved against the live DOM at run time
If one fails on its first run, refine it with the actual UI labels and TestSprite rewrites the test against the real flow.

​
When the Plan Looks Wrong

The case is spec-based or pre-redesign. Refine it: “The button is labelled ‘Save’, not ‘Submit’”, and TestSprite rewrites it.
Exploration probably didn’t reach it (check exploration on the Sources page). Re-run exploration with a clearer test account or extra context, or add cases via chat.
Add domain-specific extra context, e.g. “Our checkout has an ‘Express’ lane for returning customers; make sure tests cover it”. Future runs incorporate it.
The PRD shapes the plan but doesn’t override exploration. If exploration didn’t walk the feature your PRD describes, the case is spec-based and may lack specific selectors. Refine after generation.

​
Where to Go Next

Test Generation & Execution (UI)

Turn the plan into runnable Playwright code

Step-by-Step Replay

What you’ll see during execution

Managing Test Cases

Natural-language adjustments after generation