Working with Exploration I – Records (BBC 23Q2)

A 1-hour workshop on how and why we record our explorations of software systems

Open Miro frame. Return to central page

Changes made in Delivery

We did not do the exercise Artefacts and Audiences, or the optional Interpreting observations

We may return to those exercises and the ideas they support in later workshops.

Records of Exploration

In this session, we'll look at how we record our explorations, and how those records are used.

Most of the time, exploratory testing records are kept privately for the tester who tested. Plenty of testers rely on their memory.

I keep records to help my mind to remain available in the present, and to support other minds later.

Purposes in Three Rs

  • Remember – Mnemonic help (me)
  • Review – Sharing, improvement (me, my team)
  • Return – Historical analysis, long-term project memory (whoever comes along)

What to record

Recording Decisions is the key to remembering all the other stuff. You might also record...


  • who
  • when
  • what


  • risk
  • estimated time
  • dependencies

As you go:

  • actions
  • events
  • data
  • expectations
  • bugs
  • plans
  • interruptions
  • actual time taken
  • time wanted
  • problems

We'll start by exploring in small groups. We'll take records to be used immediately, and from that we'll extract some examples for basic principles.

Exercise: Records for Immediate Stories

15-20 mins (first 10 in breakout rooms)

5 mins exploring: In small groups, explore Puzzle 29. Purpose: Describe the reachable lamp combinations, and consider whether the puzzle is deterministic. Everyone in the group should make their own records in whatever format they choose. Make your records to help you to talk about what you found.

5 mins sharing within groups: One of each group should explain their records to their small group. That explanation should be uninterrupted, and will ideally fit into a minute. The groups should focus on the records and narrative, rather than on the puzzle or the exploratory work. Afterwards, discuss what worked. As you talk, record specific examples on the Miro board.

5 mins sharing collectively: In the large group, we'll share those conclusions.

We'll move on by exploring a more-complex system, and sharing our notes directly.

Exercise: Share Records

10 mins exploring and note-taking, 10 mins sharing

Practice fitting your exploration to the available time. Notice if you prefer to explore as hard as possible until the deadline.

This is a sharing exercise, so if you're comfortable sharing with this group, please make your notes public. Use the Miro board, or paste your notes into the Miro board.

Keep notes when exploring JS Sequence Diagrams (the tool, not the page). We won't be judging the tool, and will practice working without explicit expectations. Take as your purpose ONE of:

  • describe and experiment with the ways that the tool copes when it hits natural constraints (window size, record size, others???)
  • describe and experiment with on-screen syntax highlighting
  • describe the tool's tests

Debrief – we'll look at each other's notes. I may ask you to volunteer to talk through your own notes with the whole group. If you see something you feel is an example of a good thing to do, write the general principle on a sticky note and put it on the miro board to share.

We'll also use those records, talking about what we found, and how we explored.

Use of Records

Some audiences – including future you – will want to use your exploratory notes. They might want to see what's been done already, to have evidence of a problem, to look for the absence of evidence of a problem, to see what else might be done, to look for new leads, to learn about how you worked.

Searchability is important for this – and so electronic forms may be more useful; typed notes, keylogging and files, video transcripts.

Some test teams standardise on one note-taking approach; a massive mindmap, a shared OneNote, rich-text on a session-based Jira ticket, a set of sequential blank books. Some don't standardise on notes taken in-the-moment. Others put all long-term information in the issue tracker.

What do you, your teams, and your institution do?

Exercise: Artefacts and Audiences

15 minutes – 5 mins writing, 10 mins group conversation

In this, we'll look into, and share, our typical patterns of action around the ways that we keep notes from our work. Some of those patterns may be personal, from the team, or set institutionally.

Add a sticky note to the Miro board for a specific piece of information which you put into some sort of contained record. On the note, name the artefact, describe the audience, what they want it for, and how long it needs to be available for. We'll use these as examples as we talk.

For variety, it would be good to see 2-3 notes each. A good description of a few is better for this than a long list of titles. It would be great if at least one of those was the output of some sort of active testing work. Try to have at least one which you make for someone else, and at least one which is for yourself at some future time.

We'll talk about the following topics

  • Why might we record?
  • What do you record?
  • How do you keep records?
  • What do you share? Why?

Optional / for later

Exercise: Interpreting observations

Interpreting notes for Puzzle 29

Below is a table of observations made while exploring Puzzle 29. It might be right.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.