Run a 90-Minute Exploratory Test Session

Every scripted test passes, yet after release a report arrives: "it freezes when I press this." In most cases that action was never in anyone's test cases. This article covers the testing phase: how to run exploratory testing as a 90-minute session so you can find bugs that no script describes.

Exploratory Testing Is a Time-Boxed Experiment

Exploratory testing means designing and executing tests at the same time. What you notice on screen shapes your next action. What separates it from random poking is that you decide three things up front: goal, time, and records.

Designing the Session: Write a One-Line Charter

Each session gets a short instruction called a charter. One line in this format is enough:

Explore [target] with [approach or angle] to find out [what you want to learn]

Good charters

• Explore the checkout form by going back, reloading, and opening it in another tab, to find out when entered data is lost
• Explore profile image upload with huge, tiny, and unsupported files, to find out where error messages are missing

Bad charters

• "Click around the whole app" (too broad, with no natural end)
• "Find bugs" (no angle, so you repeat the same actions every time)

How to Spend the 90 Minutes

Always set a timer. Past 90 minutes, focus fades and you start repeating the same actions.

Keeping Records: Three Kinds of Notes

Keep your notes in three separate buckets so they stay useful later.

1. Bugs: reproducible defects, with steps and a screenshot
2. Questions: things you cannot tell are a spec or a bug. Ask the owner afterward
3. Issues: what you could not test, ran out of time for, or lacked an environment for

How many bugs you found matters less than how far you got. If the Issues bucket is full, it becomes the source of your next charter.

Common Failures and Fixes

• Chasing the root cause of a bug you just found: that is the developer's job. Write down the steps and move on
• The same person always tests the same screen: rotate assignments. Newcomers and non-engineers happily do the things veterans instinctively avoid
• Reports stop at "something looks off": without the screen and the flow of actions, developers cannot reproduce it

Putting It into Practice with Bugoon

Reporting a bug on the spot keeps the memory fresh. If you embed the Bugoon widget in your test environment, you can capture a screenshot, annotate it, and record the steps that led there, all on the page. Reports are registered as GitHub Issues, and you can follow their status on the kanban board.

Being able to tag a whole session's reports together and review them per session would make the results of exploratory testing even easier to trace. For now, a practical approach is to put the session name in an Issue label.

Summary

Write a one-line charter, set a 90-minute timer, and split your notes into bugs, questions, and issues. Those three habits alone change how many unscripted bugs you catch. Try it on a single screen before your next release.