Skip to main content
The Test Cases list, grouped by use case with per-row status

​
Overview

The Test Cases page is the working list of every test in the project, grouped by use case. This page covers keeping that list right: editing what a test does, adding new ones, and pruning old ones. Everything here changes the plan — what the test intends to do. To make a change count, re-run the test afterward; that’s why saving a single case is wired as Save & Run.

​
Editing a Single Test Case

A test case open as a drawer — Basics, Runtime steps, and the Preview pane
Click any row to open the test case — as a drawer over the list, expandable to a full page. What you can change, and where:

​
Editing steps and re-running

The Edit steps & re-run dialog — the pass criterion above the editable step rows
The Edit steps modal lets you rewrite the flow from any step onward: steps before the one you picked stay locked (they’re still executed, just not editable), and everything after is free-text — add, remove, or rewrite steps, each typed as an action or an assertion. You can adjust the pass criterion in the same modal. Saving starts a run with the new steps immediately.
For UI tests, edited steps run directly — there’s no code-generation step in between. For API tests, editing the prompt pairs with a Regenerate button right under it: Save & Run replays the existing stored code, while Regenerate rewrites the code from your edited prompt first and then runs. Reach for Regenerate whenever your edit changes what the code must do.

​
Batch Editing

Click Edit Test on the toolbar to open the batch editor — every test case in the plan on one screen, with a use-case nav on the left. It has two modes:
The Edit Test button on the Test Cases toolbar
Form mode — every case as an editable row with its steps expanded
A table of every case with test name, priority, description, and each flow step editable in place, steps expanded by default. Best when you’re touching a handful of cases and want to see them in context.Save writes only the rows you actually changed, and reports per-case if any row fails to save — a partial save never silently loses the rest.
Switching between the two modes discards unsaved edits in the mode you’re leaving — the editor warns you first.

​
Adding Test Cases

The Add More Tests dropdown on the toolbar has both paths:
The Add More Tests dropdown, with the AI and manual paths
  • Add Tests with AI — describe what you want covered (optionally scoped to one use case) and review the proposed batch before anything is created. In the review grid you can edit each proposal’s title, description, priority, and steps, untick the ones you don’t want, and even hand-add rows.
  • Add Test Manually — a form with use case, title, priority, description, and a step list (action/assertion per step).
You can also add from the Coverage Map — per use case, or with the per-feature ✨ AI shortcut.

​
Deleting Test Cases

  • One case — from the trash icon in its drawer, or the row’s context menu in the list. A case that has never run is labeled “Remove from plan”; one with run history warns you the history goes with it.
Deleting a single case from its row
  • Many cases — select rows and use the trash button in the toolbar.
Deleting several selected cases from the toolbar
Deleting a test case permanently removes its run history too. If you might want the history later, consider deprioritizing the case instead of deleting it.

​
Where to Go Next

Refining Tests

This page is “how to change it yourself” — that one is “how to have AI change it”

Coverage Map

Manage the plan visually, use case by use case

Test Detail Page

Where the drawer, tabs, and run controls live