Bug hunts

A bug hunt is an event: a name, 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 → Create.

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
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.

Assigning them randomly

:::note Recently changed Assign randomly is new. Before it, every test case in a new hunt was assigned one row at a time. :::

Select two or more test cases, press Assign randomly, and tick the people who should run them. The selected cases are shuffled and shared out evenly — nobody gets more than one case more than anybody else — and the dialog says how many each person will get before you confirm. Any assignee already set on those cases is replaced. Viewers are not offered, since they cannot run a test.

Nothing is saved until you press Create, so a split you do not like can be redone by pressing the button again, or changed row by row.

Milestones and the old Release field

:::note Recently changed Creating a hunt no longer offers a Release version field. Use a Milestone instead — it covers the whole release, not just this one hunt, and its readiness is computed rather than typed in.

A hunt that already had a release version keeps it, shown read-only in the header as, for example, "Release: 2.1 (legacy)". Nothing converts it to a Milestone for you. The list's Release filter stays available only while some hunt in the project still carries a value. :::

A hunt can be in several Milestones. Its header lists each one, with an arrow that opens the project's open Milestones as ticks; on the Bug Hunts list, the Milestones cell of a row opens the same ticks, so a hunt joins or leaves a Milestone without being opened. A closed Milestone keeps the hunt: it stays ticked and cannot be unticked. You can also pick several when creating a hunt. See Milestones for the rules, and for what it means for one to be ready.

:::note Recently changed A hunt used to be in one Milestone at most, chosen from a single chip. :::

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.

Its steps follow the library. Whenever the case is opened in the hunt, its steps are brought in line with the test case:

• a step added in the library appears in the same place in the hunt;
• an edited step shows the new words and keeps the result already recorded on it;
• a step moved in the library moves in the hunt;
• a step deleted from the library is removed from the hunt, with its result. Bugs and comments left on it stay on the case.

What else the copy means:

• 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.

:::note Recently changed Until release 1.1.0 the steps were matched by position: a step inserted in the library appeared at the end of the hunt's copy, a deleted step left the last one repeated, and a step could show up twice. A result could also end up on a different step from the one it was recorded on. This page used to say that editing the library did not change a hunt's copy. The steps had in fact been following the library for some time; now they follow it correctly. :::

Finding a case

A hunt lists its cases a page at a time — 50 by default, or 25 or 100 — with the same toolbar as every other list:

• Search matches a case's name.
• Assignee narrows it to one or more people, each with their picture. You are at the top as You, then everyone with cases in this hunt, each with how many they hold, then Unassigned.
• Status narrows it to Untested, Passed, Failed, Blocked or Archived.

The search, filters and page are part of the address, so a filtered hunt can be bookmarked or sent to someone. A link to one case — from a notification, or from the Bugs page — opens the page that holds it, clearing any filter that would hide it, and scrolls to it.

:::note Recently changed Hunts used to list every case at once, which made a hunt of a few thousand cases slow to open, and the browser's own find was the only search. If your instance shows every case on one page with no toolbar above them, it predates the change. :::

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

Changing a step's result sets the verdict for you: Passed once every step has passed, Failed as soon as one fails, and Untested otherwise. A verdict you pick yourself that the steps do not agree with — Blocked, or Passed with nothing ticked — stays, whatever happens to the steps, until you pick another. Once your verdict and the steps agree, the steps carry it from there. Comments and bugs never change it, and neither does opening the case.

:::note Recently changed A verdict picked by hand used to be replaced by what the steps said — Untested while none was ticked — whenever the case was opened, commented on or given a bug, and again by the next step you ticked. A result recorded through the AI connector went the same way. :::

:::note Recently changed The verdict is now worked out by Sekee, when the step's result is saved, rather than by your browser sending a second change afterwards. The rule is the same; what differs is that it now applies to a result recorded by anything else too — an assistant using the AI connector moves the case verdict exactly as ticking the step would, and the answer it gets says what the case's status became. A verdict you set by hand still stays. When the verdict moves, the case's linked Jira issues are updated as they always were. :::

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

A comment an assistant wrote through the connector carries an AI generated badge beside its author, here and on the hunt's own page.

Click a step anywhere to open it. Step progress and the steps table's column names stay at the top as you scroll, so a long case keeps both in view.

Comments and bugs live in the Discussion panel, grouped under the step they are about:

• A step's comment or bug count opens the panel on that step's comments, or its bugs — it says Only Step 3, with Show all steps to go back. Click the same count again to see everything.
• Right-click a step — or press and hold on a phone — for three choices:
  • Quick comment… opens a small box right where you clicked. Write, press ⌘ + Enter (Ctrl + Enter on Windows) or Comment, and the box goes away again; the comment is in the step's thread like any other, and @ tags work as they do in the panel. Esc or × puts the box away without posting, and so does clicking elsewhere while it is still empty. It suits a one-line note in the middle of a run, without opening the panel.
  • Comment in Discussion and Report a bug open the panel with the composer on that step, ready to type.
• Comments and Bugs at the top of the panel switch the composer to match when nothing is typed in it yet. Anything half-written stays as it is.
• Click a bug to open its own page.
• Reply makes the next comment an answer: the composer says Replying to … — or Commenting on … for a bug — until you post or press ×, and the answer is drawn under what it answers as part of its thread, on the same step. Threads are one level deep, so replying to a reply joins the same thread. A comment on a bug is also listed on the bug's own page, and one written there shows here. This works the same on the hunt's own page and beside a case being run. The hunt's table counts threads, not every comment in them.

:::note Recently changed A step's comment and bug counts did nothing when clicked, the right-click menu is new, and the progress card and column names used to scroll away. Bugs had a Reply, and clicking one on the hunt's own page opened its test case rather than the bug. Reply on a comment used to point the composer at the same step and post an ordinary comment, not an answer under it, and a bug could not be commented on. :::

Bugs found here

A bug carries a title, a description, screenshots, a severity (Low/Medium/High/Critical) and a status:

Open · In progress · Done · Won't fix

The description is a rich text editor, so steps can be a list and the expected result bold. Screenshots go in the strip under it: pick or drop them there, or paste one straight into the description — a pasted picture is attached, not put into the text. The first one is the bug's thumbnail in the Bugs list.

:::note Recently changed The description was a plain text box, and a bug found in a hunt had no screenshots of its own. :::

:::note Recently changed Severity is new here. It is set when the bug is reported and can be changed afterwards by any member — see who can edit a bug. :::

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.

Linking an automation run

A release is usually covered twice: by the cases somebody works through in the hunt, and by whatever CI ran against the same build. Link a run puts the second one on the hunt, so both halves of the answer are on one screen.

Each linked run shows as a row with the share of its tests that passed, its pass and fail counts, and the run's status down its left edge. Clicking it opens the automation run itself.

The link points one way. The run appears on the bug hunt; the bug hunt does not appear on the run — a CI run gets referenced by any number of hunts over its life, and listing them on its own screen would say more about the hunts than about the run.

You can link as many runs as the hunt needs, and unlink one with the × on its row. Linking needs edit permission on the hunt; the runs offered are the ones belonging to the same project.

:::note Recently changed Linked automation runs are new. If your bug hunts show no Automation section above the test cases, your instance predates the change. :::

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.