Exploratory sessions

A session is time-boxed exploratory testing. Where a bug hunt gives you steps, a session gives you a charter — an area, a goal, a question — and a clock.

Creating one

Sessions → Create.

Field	Notes
Title	What this session is about
Charter	The goals, the scope, or the area under test
Tags	Labels for finding it later
Date	When it is planned for
Planned duration	15 minutes to 8 hours, in quarter-hour steps
Participants	Everyone who may log notes and bugs against it

The title and the planned duration are both editable afterwards from the session's own header — click the name, or the duration beside the clock. Both are guesses made before the session started and are routinely wrong by the time it has ended.

Milestones

A session can be in several Milestones. Its header lists each one, with an arrow that opens the project's open Milestones as ticks; on the Sessions list, a row's Milestones cell opens the same ticks, so a session joins or leaves a Milestone without being opened. A closed Milestone keeps the session: it stays ticked and cannot be unticked. The list's Milestone filter matches a session in any of the ones picked.

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

The clock

A session has a real timer, and its status says what the clock is doing:

Status	Meaning	Button offered
Planned	Not begun	Start
In progress	Running	Pause
Paused	Begun, stopped	Resume
Completed	Finished	—
Archived	Set aside	—

The elapsed total is banked whenever the session is paused, so the clock survives a reload, a different device, and somebody else opening the page.

You do not have to open the session to move it. The Sessions list has a status picker on each row, and it offers the five statuses above — Planned, In progress, Paused, Completed and Archived (a session that has begun is not offered Planned). Sekee keeps the time whichever way the status changes: pausing or completing a running session from the list, or through the AI connector, adds the time since it last started to the total, exactly as the Pause button on the session page does.

:::note Recently changed Changing a running session's status from the Sessions list lost the time since it was last started, so completing it there could leave the clock at zero. It keeps it now. The list's picker also offered Draft and Cancelled, which are not session statuses (the server refused them), and had no Planned or Paused; it offers the real five now, so a session can be paused from the list. :::

:::caution A started session never goes back to Planned Planned means not yet begun, and once a session has begun that stops being true of it. The status picker drops the option, and the server refuses the write — so an assistant or a script cannot do it either. Restating the current status and unarchiving a session are not that move and both still work. :::

:::note Recently changed This replaced an older model where the resting state was called Draft and pausing dropped the session back to it — the same word an untouched session wore. If your instance still shows Draft and has no Paused, it predates the change. :::

Notes and bugs

While a session runs you log two kinds of entry against it:

• Comments — observations, setup notes, anything worth recording. Only its author, an owner or an admin can edit one; see who can edit a comment
• Bugs — with a title, severity and status. Session bugs use the same four statuses as bugs found in a hunt: Open, In progress, Done and Won't fix. Choosing Won't fix asks for a reason, which is shown on the bug afterwards and cleared if it moves to another status. Any member can edit a session bug's fields, same as a hunt bug. Every session bug is also listed on the project's Bugs screen, where its Found in link brings you back here with that bug highlighted. Session bugs once had statuses of their own, Resolved and Closed; both became Done, since neither recorded why the bug was settled

A note an assistant wrote through the AI connector carries an AI generated badge in the feed.

Both take rich text and attachments. Files you attach are shown as a strip of thumbnails on the entry; clicking one opens it full size in place rather than over the page, so the note it belongs to stays on screen beside it. The same goes while you are editing an entry, where each thumbnail also has an × to remove it. Esc closes an open picture first; pressed again, it closes the editor, asking before it throws away anything you wrote.

Click an entry to open it — the whole text, and its attachments at a size worth looking at — and click it again to close it, the way a test step opens. An entry that already shows all of itself, such as a one-line reply with no files, looks the same open as shut. Selecting text in an open entry to copy it leaves it open: letting go after dragging across the text, or double-clicking a word, does not close it. A bug's title opens its own page.

:::note Recently changed A bug's title used to open nothing, letting go after selecting text in an open entry closed it, and a screenshot did nothing when clicked while the entry was being edited. :::

Copy link in an entry's ⋯ menu copies a link to that comment or bug. Whoever opens it lands on the session with the entry opened and lit for a moment — the same as a link from an email or a notification. Anyone who can see the session can copy one, viewers included.

Replying to a comment or a bug

Reply — the arrow beside an entry's ⋯ — answers it. The answer is written right under the entry, and once posted it is drawn there as part of that thread: set in, with an arrow in place of the comment icon. Threads are one level deep, so replying to a reply joins the same thread. A reply has no name of its own, and @ mentions work in it as in any comment.

Answering a bug writes a comment on it. The comments on a bug are also listed on the bug's own page, which has a box to add one — whichever you write in, it shows in both places.

Deleting a comment leaves its replies in the session as comments of their own.

:::note Recently changed Comments in a session could not be answered, and a bug could not be commented on; every entry stood on its own. :::

Add starts either one. So do two shortcuts, which are quicker mid-test: ⌘/Ctrl + Enter starts a comment and ⌘/Ctrl + Shift + Enter starts a bug. With an entry open, the same keys save it and start the next. A session with nothing logged yet says so in its empty feed, so nobody has to find the shortcuts list first — on a phone, where there are no keys to press, it only points at Add.

:::info Commenting on a session joins it A session has no owner field — participants stand in for one. So commenting on a session, or reporting a bug in it, adds you to its participants. It is a courtesy on top of an action that already succeeded, and it never fails the action. :::

Turning a comment into a bug, and back

An entry logged as the wrong kind can change kind. Open its ⋯ menu in the feed:

• Convert to bug on a comment asks for the bug's title — filled in from the comment's own title, or else its first line — and its severity (Medium unless you pick another). The bug starts Open. The comment's words become the bug's description, and its attachments and author carry over, so the bug is reported by whoever wrote the comment. The comment's replies move with it and become comments on the bug; the dialog says how many before you confirm. The other way round, a bug's comments become replies to the comment it turns into.
• Convert to comment on a bug asks you to confirm, because a comment has no status, severity or won't-fix reason and those are dropped. The bug's title, description, attachments and reporter carry over. A bug with no description becomes a comment that says its title.

Either way the new entry takes the old one's place in the feed — it keeps the time the original was written — and is highlighted for a moment. If the feed's type filter now hides it, the notice offers Show it. The original is gone: converting is a move, not a copy. Converting back undoes it, except that a bug made from a comment starts Open and Medium again.

Who can: anyone who can edit a bug can convert one; a comment can be converted by the person who wrote it, or an owner or admin — the same people who can edit it. Guests cannot convert either kind.

A comment that becomes a bug tells the session's followers about a new bug, exactly as reporting one does; a bug that becomes a comment tells nobody, and nobody mentioned in a comment is told again. The Activity log records one entry on the session for each conversion. A bug can also be turned into a comment from the Bugs list or its own page; the AI connector can do both.

:::note Recently changed Entries could not change kind: a note that turned out to be a bug had to be written again as a bug, and the note deleted by an owner or admin. :::

A link to a comment — from a mention email, the bell, a comment search or the Activity log — opens the session on that comment, scrolled to and highlighted, as a link to a bug does.

Filtering the feed

The activity list has the standard toolbar: search, and a filter for whether you want comments, bugs, or both.