Bug hunts
A bug hunt is an event: a name, a release it is about, a window of dates, the people doing it, and the test cases to get through. It is how scripted testing happens in Sekee.
Creating one
Bug Hunts → New bug hunt.
| Field | Notes |
|---|---|
| Name | What this hunt is, e.g. "Release 2.4 — checkout sweep" |
| Description | Rich text: scope, what to watch for, what to skip |
| Release version | Free text, editable later from the hunt's header |
| Start / end date | The window. Editable in place afterwards |
| Status | Planned, Active, Completed, Archived |
| Members | Who is running it |
| Tags | Labels for finding it later |
Then add test cases — individually, by folder, or by tag.
The copy, and why it matters
Adding a case to a hunt copies it. The copy carries its own verdict, its own step results, its own assignee and its own bugs, and remembers which case it came from.
This is not an implementation detail you can ignore:
- Editing the library afterwards does not rewrite what a tester saw.
- Removing a case from a hunt hides the copy rather than destroying the record.
- A case's history is built from these copies, which is why a hidden one is left out of both history and coverage — a case taken out of a hunt is not something that hunt says about it.
Executing
Open the hunt and click a case. The execution screen shows the steps, and each one takes a result. The case itself takes a verdict:
Untested · Passed · Failed · Blocked
Alongside the steps you get:
- Known issues — the note written on the case, plus every bug still open against it from other hunts, so you are not refiling something already known
- Bugs — what you find here, raised against this case in this hunt
- Comments — anything worth saying that is not a bug
Bugs found here
A bug carries a title, a description with attachments, a severity
(Low/Medium/High/Critical) and a status:
Open · In progress · Done · Won't fix
Won't fix requires a reason. It is a decision rather than an outcome —
somebody looked at the bug and chose to live with it — and a tracker full of
silently abandoned bugs gets the same bug refiled next quarter. The reason is
cleared automatically if the bug moves back out of Won't fix, so it never
reads as though the decision still stood.
Bugs appear on the hunt, on the test case's known issues, and on the organization-wide Bugs screen.
Progress and completion
The hunt header shows how many cases are done and what proportion passed. Moving the hunt to Completed sends a closing report to everyone following it.
Watching a hunt
Watch emails you about comments, bugs and status changes on this hunt. Watching is not gated on edit permission — asking to be told about someone else's activity is not a change.