Skip to main content

Automation overview

Sekee ingests JUnit-style XML test reports from CI and turns them into three things: runs, tests and results. Together they give an automated test the same kind of history a manual one gets from bug hunts — and let CI move requirement coverage.

The shape of it​

automation run          one CI execution: a name, a source, tags, its report files
  └── automation test   one test with a history, identified by a fingerprint
        └── result      that test, in that run

An automation test is found or created by a fingerprint of "<suite> :: <name>" within a project, so the same test keeps its identity from run to run even as runs come and go.

:::info What counts as "a test" depends on the framework A Cypress group is a test — its steps are the entries beneath it. A Playwright entry is a test. Sekee normalises both on the way in, so the history is per-test in the sense the framework means. :::

Getting reports in​

Two ways, both authenticated with an API token sent as x-api-token:

  • sekee-cli — the supported path. One command for a simple run, or init / thread / complete for parallel shards.
  • The HTTP API directly, if you would rather not add a dependency to your pipeline.

Both derive the organization from the token. The token is what makes the request tenant-scoped; there is no other credential.

Reading a run​

Automation → a run. You get the parsed report: suites, tests, durations, and the failure output for anything that failed. A test that has a row in Sekee is decorated with a link to it, and that is where you link it to a test case.

Linking a test to a test case​

Open the run, find the test, and link it. From then on:

  • The test case shows that automated test and its recent runs
  • The last CI result feeds the coverage of any requirement the case proves
  • The case's View all page lists every run of it as a table

This is the one manual step in the chain, and it is deliberate — Sekee will not guess that login.spec.ts › signs in proves the case you called "Sign in with a valid email".

Tags and sources​

A run carries a source (GitHub Actions, Local, Jenkins — free text) and tags. Both are for finding runs later and for scoping dashboard widgets, and both are set by whoever uploads the report.

Watching automated tests​

You can watch a test and be emailed when it changes state — see Notifications. This is the automated equivalent of watching a bug hunt.

Errors​

Failures are also aggregated into error tracking, which is one row per distinct failure across every run rather than one row per run.