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.
Writing a step
Adding or editing a step opens the step as a card across the width of the table, with each field labelled and the evidence drop zone at the bottom. Tab moves to the next field. Plain Enter breaks the line.
| Writing a new step | Editing an existing step | |
|---|---|---|
| ⌘/Ctrl + Enter | Saves the step and opens the next one | Saves the edit |
| ⌘/Ctrl + Shift + Enter | Saves the step and stops | Saves the edit and starts a new step |
The line along the bottom of the card says which is which, so there is nothing to remember.
:::note Recently changed
In a new step, ⌘/Ctrl + Enter used to save and stop, and it took Shift to carry on to the next step. The two have swapped: writing steps one after another is the common case, so the plain shortcut now does it. Editing an existing step is unchanged.
Before that, plain Enter saved the step. The fields are full width and several lines tall now, so Enter belongs to the text.
:::
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.
Comments
Comments opens a panel beside the case — the case stays on screen and the conversation sits next to it, rather than either one taking the page.
Each comment shows who wrote it and what they are in the organization, and how
long ago it was said; hover the time for the exact moment. Type @ to mention a
colleague, which emails them, and : for an emoji. ⌘/Ctrl + Enter posts.
Reply answers one comment, and the answer is drawn under it as part of that thread. Threads are one level deep: replying to a reply joins the same thread rather than starting a third column. The case's author is emailed about any comment on it — see Notifications.
:::note Recently changed
Comments used to be a flat list, with no way to answer one in particular, and a new comment only appeared once the whole case had been re-read from the server — a second or two after it was written, with the page blinking on the way. It is on screen as you post it now, and threaded.
:::
Who can edit a comment
:::note Recently changed Only its author, an owner or an admin can edit a comment now. A comment with no author left — from a member who has since left the organization — can only be edited by an owner or admin. :::
Edit, beside Reply on a comment you may change, opens it in place: change the words, then ⌘/Ctrl + Enter or Save; Esc or Cancel leaves it as it was. A comment that has been changed says edited beside its time.
:::note Recently changed Comments on a test case, in a bug hunt and on an automation run could not be edited from the app before — only a session's could. The rule below was already the server's; the Edit button is new. :::
This applies wherever a comment appears in Sekee: on a test case, a bug hunt, a session or an automation run. It is narrower than most content in Sekee, where any member may edit — see who can edit a bug for the looser rule that applies there instead. Deleting a comment was already owner/admin only, and stays that way.
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.
Changing the state from the list
:::note Recently changed The State column in the test case list is a control now, not a label. Changing a case's state used to mean opening it. The same is true of the lists of bug hunts, bugs and unstable tests. :::
Click the state on a row and pick another one. The change is saved as you pick it and the row stays where it is — you are not taken into the case. To open the case, click its name.
Archiving, and undoing it
Archiving is on the row's ⋯ menu. An archived case leaves the list, keeps everything it had, and is still reachable through the Archived state filter.
:::note Recently changed Archiving now says so, and offers Undo in the notice for about ten seconds. It used to happen in silence, and the only way back was finding the case again under a filter you had to know about.
Undo restores the state the case held before — an Outdated case comes back outdated. Until this change, anything restored from the archive came back Active whatever it had been. :::
The notice waits while you are somewhere else: its ten seconds only count while the Sekee window is in front of you, so switching to another application does not cost you the chance to undo.
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 from its own screen, under Export: Markdown, CSV, Excel, JSON, PDF, or one of the two XML dialects other test tools read. The Markdown export is the readable one — it keeps the steps as a table and the fields as sections, and it is the only one that carries the screenshots.
Whole folders go in and out the same way. See Importing and exporting.
:::note Recently changed
Export used to offer Markdown and CSV alone. The CSV it produced was a Sekee shape that no other tool read; it is now one row per step, which is the layout TestRail, Zephyr, Xray, qTest and the rest both write and import.
:::