Core concepts
Sekee has a small vocabulary. Getting it straight early saves a lot of guessing later, because the words mean specific things and the screens assume you know which.
The container: organization → project
An organization is the tenant. It owns every other record, and nothing is ever visible across two of them. Users belong to exactly one organization and carry a role in it.
A project is a unit of work inside the organization. Everything that gets tested belongs to one: test cases (through their folder), bug hunts, sessions, requirements, automation runs and errors.
Each project has two identifiers. Internally it has an id and a documentId;
externally it has a projectId — a per-organization sequential integer.
That last one is what CI passes to the CLI, because it is short, stable and
meaningful to a human writing a pipeline file.
The library: directory → test case → step
A directory (folder) is how the library is organised. Folders nest, and a subscription to a folder covers everything beneath it.
A test case is a written test: a name, a description, pre-requisites, a scenario, known issues, tags, an estimate, a state, an automation status, and an ordered list of steps.
- 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
A step is an action, its expected result, optional additional data, and optional screenshots. A step can also be a shared step — a reusable block maintained once and inserted into many cases.
Running it: bug hunts and sessions
These are the two ways people test, and they answer different questions.
A bug hunt is scripted. It has a name, a release version, a window, members
and a set of test cases copied into it. Each copy carries its own verdict
(Untested, Passed, Failed, Blocked), its own step results, and its own
bugs. The hunt's own status is Planned, Active, Completed or Archived.
:::info Why the test case is copied A hunt holds a copy of each case, so every run has its own verdict, step results, assignee and bugs. The copy's steps follow the library: edit a step and the hunt shows the new words, keeping the result recorded on it. The copy remembers the original, which is how history and coverage find their way back. :::
A session is exploratory. It has a charter rather than steps, a planned
duration, participants, and a clock. You write notes and log bugs as you go.
Its status moves Planned → In progress ⇄ Paused → Completed, with Archived
off to the side.
:::note Recently changed
Sessions used to call their resting state Draft and had no Paused — pausing
dropped a session back to Draft, which is also where an untouched session
sat. If your instance still shows Draft, it predates that change.
:::
What the running produced: bugs and errors
A bug is something a person found. Bugs raised in a hunt live on the case
copy and bugs logged in a session live on the session, but the Bugs screen
lists both kinds, across every hunt and session, because a bug outlives the
hunt or session that found it. Their statuses are Open, In progress, Done
and Won't fix — and Won't fix is the only one that insists on a reason,
because a tracker full of silently abandoned bugs is worse than one with none.
An error is something a machine found. Automation ingest writes one row per distinct failure with an occurrence count. Two failures are the same error when their first line matches — the rest of a stack varies per run and would give one row per run.
Proving it: requirements and coverage
A requirement is a thin reference: usually a Jira issue with its title, status and priority cached on the row, occasionally a statement typed by hand. It has no status of its own.
Coverage is derived on every read from three things:
- The latest verdict on each linked test case, taken from bug hunt runs
- Open bugs raised against those cases
- The last result of any linked automated test
Worst wins. "Passing" means every linked test says so. Nothing anywhere stores a coverage word, which is why coverage cannot go stale.
Automation: run → test → result
An automation run is one CI execution: a name, a source, tags, and the report files it was built from.
An automation test is one test that has a history — found or created by a
fingerprint of "<suite> :: <name>" within a project, so the same test keeps
its identity across runs.
An automation test result is one test in one run.
Linking an automation test to a test case is what lets CI move that case's coverage.
:::info What counts as "a test" depends on the framework A Cypress group is a test (its steps are the entries); a Playwright entry is. Sekee normalises both on the way in. :::
Visual testing: snapshot → baseline
A snapshot is one screenshot a Playwright test captured in an automation
run, known by its name, Playwright project, viewport and platform. Sekee
compares it against its baseline, the picture somebody approved, and gives
it a result: unchanged, changed, new or failed. A person approves a
change, which makes it the new baseline, or rejects it, which keeps the old one.
Baselines are kept per branch — the default branch's, and a feature branch's own once it approves one — and live in Sekee rather than in your repository. Business plan. See Visual testing.
Who can do what
Four roles, highest to lowest: owner, admin, member, guest. Administration is owner-and-admin only. Members can create and edit but cannot delete content. Guests — sometimes called viewers — can read and run what is assigned to them.
See Roles and permissions for the full table.