Exploratory sessions
This page helps you test something without a script: poking at a new checkout flow to see what breaks, say. At the end you’ll have a record of what you tried and found, in the order you found it, with a bug ticket for each problem.
An exploratory session is one person exploring a charter, what to explore and what to look for, within a timebox, and logging what they find as they go. Where a manual run checks what you already know should work, a session looks for what nobody wrote a case for. Sessions are in Tests, then Sessions.
Before you start
Section titled “Before you start”- Test management and test results both have to be on for your organization. Without one, the Sessions tab says which isn’t on your plan. Contact support to turn them on.
- Members of the project start and log sessions. Someone with view-only access can read them.
Start a session
Section titled “Start a session”-
On the Sessions tab, choose New session.
-
Give it a Name, such as
Checkout with expired cards, and write its Charter: what to explore, and what to look for. A charter keeps a session on track, so make it specific, such as “Pay with an expired, a declined and a 3-D Secure card on mobile, and look for the order being created anyway.” -
Set the Timebox, from 5 to 480 minutes. It starts at 60.
-
The Tester is you unless you pick someone else. Add the Build, Environment and Configuration it runs against, as for a run.
-
Choose Start session. With Start the timer now cleared, it’s Create session instead, and the timer starts when you do or with your first note.
Log what you find
Section titled “Log what you find”As you explore, log each thing in the session as one of four kinds:
- Note: what you tried and saw.
- Issue: something wrong. A bug can be filed from it.
- Question: something to ask someone.
- Idea: something to test next time, or a case worth writing.
Type it and choose Log note (or the kind you picked), or press ⌘Enter (CtrlEnter on Windows and Linux). Paste or attach screenshots to it, up to 20 a note. The log keeps them in order, so it reads back as what happened.
Only the person who logged a note can edit or remove it, while the session is open. A note a bug was filed from stays, but can be edited.
Keep to the timebox
Section titled “Keep to the timebox”The timer shows how long you’ve explored, against the timebox. Pause it for an interruption and Resume when you’re back. When you pass the timebox, the session says by how much and suggests wrapping up, but it never stops you: keep going if it’s worth it.
File a bug
Section titled “File a bug”File bug on a note files a ticket in the project with the note and the session’s charter already in it, and the note’s first line as its title. File bug at the top of the session files one that isn’t from a note, and logs it in the notes as an issue. Either way, the bug is listed under Bugs on the session.
Close it with a debrief
Section titled “Close it with a debrief”When you’re done, choose Close session. The timer stops, and you can write a Debrief: what you covered, what you found and what’s still worth exploring. That’s what someone reads first. The notes become read-only.
You can write or edit the debrief later, and Reopen the session to explore more.
Does a session have test cases?
No. A session has a charter instead of steps. If you find something worth checking every time, write a case for it in the library.
Can two people share a session?
A session has one tester. Start one each, with the same charter or different halves of it.
- Run tests by hand: work through written cases with your team.
- Test cases: turn what you found into cases.