Test cases
A test case is the written record of one test: what has to be true before it runs, what to do, and what should happen. It lives in a folder, belongs to a project through that folder, and is the thing every other part of Sekee points at.
Anatomy
| Field | What it is for |
|---|---|
| Name | What it proves, in one line |
| Description | The short summary shown in lists |
| Pre-requisites | What has to be true before the steps make sense. Carries rich text and attachments |
| Scenario | Background or context that is not a pre-requisite |
| Known issues | A written note about existing problems — read alongside the live open bugs |
| Tags | Free-form labels. Naming one creates it, and a bug hunt can pull in everything carrying it |
| State | In progress → Active → Outdated → Archived |
| Automation | Can be done, Done, Cannot be done, Partially |
| Estimate | 1–5 minutes, 5–10 minutes, 10–20 minutes |
| Requirements | What this case exists to prove |
| Steps | The ordered instructions |
Steps
Each step has an action, an expected result, optional additional data, and optional screenshots. Steps can be reordered, duplicated, copied between cases, and replaced by a shared step.
Your organization can add its own custom step fields on the Standard plan and above — a Severity column, a Test data column, whatever the team actually needs.
Attachments and rich text
Pre-requisites, known issues and custom step fields are rich text. You can paste or drop screenshots, video, PDF, CSV, Word, logs, JSON, XML, YAML and Markdown straight into them.
Media never renders in the middle of the words. Whatever the field holds, the text comes first and the files appear underneath as an Attachments strip of equal thumbnails. Clicking one opens it full size in place, under the strip, with arrows to walk the set and Escape to close. A screenshot is whatever size it was captured at, and rendering it inline turned a field into a wall.
History
A case carries two histories, side by side above its steps:
- Bug hunt history — every hunt it was run in, with the verdict, how many steps failed, how many bugs are still open from that run, who ran it and when.
- Automated tests — every automated test linked to it, with its recent runs as a row of dots, newest on the right.
Each shows the five most recent. A case run in twenty hunts would otherwise push its own steps off the screen. View all opens a full page for either one — a proper table, one row per run, and clicking a row opens the execution or the CI run it describes.
The lifecycle in practice
- Write the case. It starts In progress.
- Move it to Active when it is ready to be run by somebody else.
- Link it to the requirement it proves.
- Add it to a bug hunt, or let CI cover it by linking an automated test.
- Mark it Outdated when the feature moves and the case has not caught up. Outdated cases still exist and still read; they simply stop claiming to be current.
- Archive it when it should stop appearing.
Flagging one as unstable
Any case can be flagged unstable — a test that passes and fails without the product changing. Flagging asks for a reason and optionally an assignee, and the case appears on Unstable Tests until somebody clears it.
Members can raise the flag and lower it again; that is deliberate, and one of the few deletions a non-admin may perform.
Exporting
A case can be exported to Markdown or CSV from its own screen. The Markdown export is the readable one — it keeps the steps as a table and the fields as sections.