Skip to main content

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, not a pointer to it. Editing the library afterwards must not rewrite what a tester saw. 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, but the Bugs screen lists them across every hunt, because a bug outlives the hunt 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.

:::caution Session bugs use different words Bugs logged in a session keep an older, separate set: Open, Resolved, Closed. They were not part of the move to the four-word list. :::

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:

  1. The latest verdict on each linked test case, taken from bug hunt runs
  2. Open bugs raised against those cases
  3. 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. :::

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.