Test Cases
The Test Cases page of a project: what each case proves, what must be true before it starts, the steps a tester walks or a script runs, the suite it is filed in, how it is automated, the review lifecycle and the versions.
By the end of this page you will have written down what the team checks before it ships, as test cases a tester can walk and a script can run; know every field a case carries and what reads it downstream; and know how a case moves from a draft to active, how it is deleted, and where every version of it, steps included, is kept.
A test case is one scripted check: Redeem an expired voucher at checkout. It says what the
case proves (the objective), what must be true before the first step, which kind of check it is
and how much it matters when time is short, whether a person or a script runs it and which test
in the automation suite does, how long a tester needs, who owns it, the data and the environment
it needs, and the steps: what the tester does, what should happen and the data each step
uses, numbered in order. Cases number on their own sequence (CRM-TC-45), are filed in a
suite, reach active through the same review a
requirement does, and keep every save as a version, steps
included. A case verifies a requirement or a rule and covers a story or a use case through
links, so the record says which check proves which promise.
Before you begin
| You want to | You need |
|---|---|
| Open the Test Cases page | test-case:view-any on the project, which every staff role carries. A client guest sees the active cases only. |
| Add a test case | test-case:create. Project managers and QA engineers have it by default. |
| Edit or move a test case | test-case:update. |
| Delete a test case | test-case:delete. |
| File a case in a suite | The suite to exist on the project's Suites tab. |
| Name an owner | The person to be a member of the team. |
The page lives under a project: open the project and choose Tests in the sidebar, badged with how many cases you may see. The page has two tabs, Test Cases and Suites; this page is the first.
Read the test cases
The table lists one case per row:
| Column | What it shows |
|---|---|
| Reference | The case's key, such as CRM-TC-45. |
| Test Case | The title, with the objective beneath it. Press the title to open the detail flyout. |
| Suite | The suite the case is filed in, or Unfiled. |
| Status | Draft, in review, active or deprecated, as a badge. Hidden from a guest. |
| Priority | Critical, high, medium or low. |
| Kind | Functional, regression, smoke and the rest; the status reference says what each means. |
| Automation | Manual, candidate, automated or deprecated; hover an automated case to read the test that runs it. |
| Steps | How many steps the case carries. |
| Last Result | How the case's last execution ended, or Not run until a run executes it. |
| Updated | How long ago the record last changed. |
| Row menu | View Test Case, Edit Test Case, Move to, Activity, Delete Test Case. |
Sort by reference, title, status, priority, kind, automation, last result or updated by pressing a column heading; press it again to flip the direction. The list opens in the project's own order.
Above the table, narrow the list with the search box (words in the reference, the title, the objective or the automation reference), the status, kind, priority and automation lists, and the suite list, which offers the project's suites in tree order. The filters travel in the page address, so a filtered list can be shared and the Suites tab's View Test Cases opens the page already narrowed to one suite; Clear Filters on the empty state drops them all.
Add a test case
- Press New Test Case.
- Type the Title: the behaviour the case checks, such as Redeem an expired voucher at checkout. This alone is enough to save.
- Pick the Suite to file it in and the Owner who keeps it current, and choose the Kind and the Priority.
- Write the Objective and the Preconditions.
- Under How it runs, choose the Automation state and, for an automated case, type the Automation Reference: the test in the suite that runs it. Type the Estimated Minutes and what the Environment must offer, and write the Test Data the case needs.
- Under Steps, press Add Step once per step and type what the tester does, the Expected result and the Data the step uses. Steps are numbered from one in the order they sit; the arrows reorder them and the cross removes one.
- Press Create Test Case.
The case takes the next number of the test cases' sequence (the first of CRM is CRM-TC-1),
starts as a draft, appears in the table at once, writes its first version with its steps inside
it, and test_case.created goes out to every endpoint subscribed to it.
One behaviour per case, one action per step
A case that checks one thing fails for one reason, and a run can say which. Keep the objective to the behaviour, put the setup in the preconditions and the values in the test data, and write each step as one thing the tester does with one thing that should follow. An automated case must name the test that runs it, so the results a pipeline reports later find the case.
Open a test case
Press a case's title, or View Test Case in its row menu, to open the detail flyout: the reference, status, priority and kind at the top, the title, then the suite, the owner, the automation state with the test that runs it and the estimate, the objective and the preconditions, the steps with their numbers, expected results and data, the test data and the environment, the last result with when it was executed, the dates, and the Versions section with every save of the case. Below it sit the Links, Files and Discussion panels every artefact carries. From the flyout:
- Edit opens the editor on this case.
- Move to changes the status in one step, offering only the moves the lifecycle allows.
- Restore this version under any earlier version puts it back, steps included; see revisions and versions.
- Activity opens the case's history: every change, who made it and where it came from.
- Delete opens the confirmation.
A link such as /projects/<id>/tests?show=<test case id> opens the page with that case's flyout
already open; Heimdall's View buttons use it.
Edit a test case
- Press Edit Test Case in the row menu, or Edit in the flyout.
- Change what you need, the step rows included: Add Step appends a row, the arrows reorder the rows and the cross removes one. The suite must be one of the project's, the owner a member of the team, and an automated case must name its test.
- Press Save Changes.
The save writes a new version of the case, steps included, and test_case.updated goes out with
the columns that changed, each with its old and new value. A save that changes only the steps
writes a version and announces nothing, since no column of the record moved. The status does not
change from the editor; it moves from the list, the flyout or the approval bar.
Move a test case along its lifecycle
A case reaches In review and Active through its approval alone: Submit for review on the approval bar puts it in review, and the approvers' verdicts move it out, to active when the request carries and back to where it stood when it is rejected or withdrawn. Move to in the row menu or the flyout offers the other moves the lifecycle allows from where the case stands, and is refused while a request is open:
| From | To |
|---|---|
| Draft | Deprecated |
| In review | Draft, deprecated |
| Active | Draft, deprecated |
| Deprecated | Draft |
An approval stamps when the case was agreed and at which version, and a client guest sees it from
that moment on and loses it when it is deprecated. Every move writes a version with the reason
moved and test_case.status_changed goes out with the status before and after; an approval
writes one with the reason approval.
Delete a test case
Delete Test Case in the row menu or Delete in the flyout opens the confirmation. Deleting
removes the case with its steps, every version it kept and its activity history; its number is
never handed out again. test_case.deleted goes out. Prefer Deprecated for a case the team
retired: it keeps the record and the results it gave.
All the fields
What happens next
- Every save, move and restore writes a version, steps included, and an entry in the project's activity history.
test_case.created,test_case.updated,test_case.status_changed,test_case.steps_changed,test_case.restoredandtest_case.deletedgo out to the webhook endpoints subscribed to thetest_case.*family.- An active case may be picked by a plan and executed in a run with a result per step, a failed step will raise a defect pre-filled from the case, the import of automation results will find cases by their automation reference, and the traceability matrix will show which requirement has no case, as those parts of the module land.
Heimdall on this page
Heimdall reads test cases and their versions through the same tools the MCP server offers, and carries the open project as its context.
On the editor, Ask Heimdall beside the objective, the preconditions and the test data drafts the field, improves it, shortens it or makes it testable; the draft waits under the field until you take it or drop it. See inline assists.
The test generator will draft cases with their steps from a story's acceptance criteria into a review list, as that assist lands.
From the API and MCP
Test Cases API
List, read, add, change, move and delete test cases, replace their steps, and read and restore their versions.
Testing tools
list_test_cases, get_test_case, create_test_case_draft, update_test_case and delete_test_case: the MCP tools that read and write test cases.
Permissions
| Action | Permission |
|---|---|
| See the test cases | test-case:view-any, test-case:view; a client guest sees the active cases only |
| Add a test case | test-case:create |
| Edit or move a test case | test-case:update |
| Delete a test case | test-case:delete |
| Read or restore its versions | test-case:view to read, test-case:update to restore; never a client guest |
Frequently asked
Related
- Suites — the folders the cases are filed in
- Traceability — the Links panel in the flyout: what this verifies, covers or relates to, read from either side
- Comments and mentions — the Discussion panel in the flyout: questions, answers, mentions, followers
- Attachments — the Files panel in the flyout: screenshots, fixtures and recordings pinned on the record
- Acceptance criteria — the promises on a story that cases prove
- Approvals — how a case reaches review and active
- Revisions and versions — every save kept, any version put back
- Status reference — every status, kind, priority, automation state and result
test_case.*webhook events
How is this guide?
Last updated on
Testing
Where the team writes down what it checks before it ships: the test cases with their steps, the suites they are filed in, the review that makes a case active, and the versions every save keeps; plans, runs, defects and the traceability matrix join as the module grows.
Suites
The Suites tab of a project's Tests page: the folders the test cases are filed in, nested by area and then by screen or flow, each tied to a component when it covers one, with how many cases each holds.