Bugs

A bug outlives the hunt or session that found it. The Bugs screen is every bug in the project — from every bug hunt and every exploratory session — in one list: the view a single hunt or session screen cannot give you.

Where each bug was found

The Found in column says which kind of place a bug came from, with a small label:

• Bug hunt — the hunt's name, and the test case in it the bug was raised against
• Session — the session's name

That label is a link back to where the bug was found — a hunt bug to the hunt's test case, a session bug to the session — with the bug highlighted for a few seconds. The rest of the row opens the bug's own page.

Statuses

Status	Meaning
Open	Filed, nobody has picked it up
In progress	Somebody is on it
Done	Fixed, or otherwise settled
Won't fix	A decision was made to live with it — requires a reason

The list opens on Open and In progress, because a list that opens with every bug ever filed is a list nobody reads. The settled ones are one click away, and the counts in the filter labels are computed over every status, so the tabs can tell you how many are Done while showing you what is not.

:::info "Open" means two statuses, everywhere Open and In progress both count as open — in this list, in a test case's known issues, and in requirement coverage. A bug somebody picked up must not stop counting against the requirement it threatens. :::

Bugs found in hunts and bugs found in sessions use the same four statuses, and the counts cover both.

Severity

Low · Medium · High · Critical. Severity is what the bug does, not how soon somebody will do something about it — that is what status is for.

:::note Recently changed Severity is new on bugs found in a hunt. It can be set when a bug is reported and changed afterwards, in both places it appears — this list and the hunt's own bug list — as a colored control on the row, not a separate edit screen. A bug filed before this change reads as Medium. :::

Filtering

The standard toolbar applies: search, plus filters for status and severity. Found in, Bug hunt, Session, Reported by and Milestone are in the Filters menu — switch one on and it joins the toolbar. Selections go into the URL, so a filtered list is a link you can paste into a chat.

• Found in — Bug hunts, Sessions, or both (the default). Use it to see only one kind.
• Bug hunt shows only the bugs found in the hunts you tick; Session only those found in the sessions you tick. Tick hunts and sessions together to see the bugs of each.
• Milestone shows the bugs found in the bug hunts and sessions of the milestones you tick — a bug belongs to a milestone through where it was found, and shows no milestone of its own. No milestone is the bugs whose hunt or session is in none. A hunt or session in two milestones counts for both.
• Search matches a bug's title, description and won't-fix reason, and — for a hunt bug — its Jira key.

Status, severity and Found in are fixed sets, so unticking everything shows nothing rather than silently reverting to the default. Filters that grow from your data — hunts, sessions, reporters, milestones — treat "nothing ticked" as "everything".

:::note Recently changed Milestone is new. :::

:::note Recently changed Only Status and Severity are shown by default now. The other four used to sit in the toolbar on every visit; they are still there, one click away in Filters. Switching one off puts it back to its default, so a hidden filter never narrows the list. :::

A bug's own page

Click anywhere on a bug's row to open its page; the open icon beside the title says so when you point at the row, and the bug's first screenshot sits beside its title. The page is laid out and edited like a test case: status and severity are picked at the top of the panel, and the name is renamed by clicking it. Below them, two columns:

• on the left, the Description, the Jira issues (a bug found in a hunt only — a session bug has no Jira key) and the Screenshots — each with Edit when you point at it, saving on its own. A screenshot taken off a bug is deleted.
• on the right, the Reporter and where it was Found in.

⋯ → Edit at the end of a row in the list opens the page with the description ready to write in.

The Found in column, and Where it was found on the page, go to the hunt's test case or the session with the bug highlighted for a few seconds. Each bug has its own address, so a link to one can be shared.

:::note Recently changed Bugs had no page of their own: clicking a row went to the hunt or the session the bug came from. That is the Found in column's job now. :::

Comments on a bug

Below the bug's panel, Comments lists what people said about it, oldest first, with a box to add one (@ tags a colleague; ⌘/Ctrl + Enter posts). They are the same comments its session or bug hunt shows under the bug — a comment written here appears there, answering the bug, and one written there appears here. The session's or hunt's followers hear about each as they would any comment. Edit your own with Edit; owners and admins can edit any. Anyone who can comment in the session or hunt can comment here — in a bug hunt that includes viewers.

:::note Recently changed A bug had no comments; the conversation about it happened beside it in its session or hunt, and could not be read from its page. :::

Turning a session bug into a comment

A bug found in a session that turns out not to be a bug — a question, an observation, a duplicate note — can be turned into a comment on that session: ⋯ → Convert to comment at the end of its row here, or the ⋯ menu beside Where it was found on its own page. Bugs found in a bug hunt are not offered this; a hunt has no comment stream to put them in.

Sekee asks first, because a comment has no status, severity or won't-fix reason and those are dropped. The title, description, attachments and reporter move to the comment, which keeps the bug's place in the session, and the comments on the bug become its replies. The bug leaves this list, and Open in session takes you to the comment; from a bug's own page you are taken there straight away. Any member can do it, as with editing a bug. Turning it back into a bug, from the session's feed, makes an Open, Medium bug — see Sessions.

:::note Recently changed A session bug could not be turned into a comment; it had to be deleted, which only an owner or admin can do, and its words written again as a comment. :::

Who can edit a bug

Any member — the title, description, status, severity, Jira key (hunt bugs) and won't-fix reason are all open to any member of the organization, not only whoever reported it, whether the bug was found in a hunt or in a session. A bug is shared work, not the reporter's property, which is why this is looser than who can edit a comment. Guests cannot edit; deleting a bug is owner/admin only, same as everything else.

Won't fix, and the reason

The reason is enforced on every path that can set the status, for both kinds of bug: creating the bug, editing it — on its page, in the hunt or in the session — and the status control in this list. It is cleared when a bug moves back out of Won't fix, so a stale justification never reads as though the decision still stood. The reason is shown under the bug, here and on the session or hunt.

Where else bugs show up

• On the bug hunt or session that found them
• On the test case, under known issues, while still open (hunt bugs)
• Against a requirement, holding its coverage down while any linked case has an open bug
• In a Jira issue's remote links, if the integration is connected (hunt bugs)