Exploratory testing for mobile apps: a session worksheet

To run an exploratory testing session for a mobile app, choose one risk, record the phone and starting state, then let each result guide your next check. Keep short notes as you test and capture unexpected behaviour before resetting the app. Use the worksheet below to keep your observations, evidence and follow-up questions together.

What makes a session exploratory?

You decide what to try next using what the app just showed you. If a message draft survives an app switch but loses its attachment, investigate the attachment's state: does it still have a thumbnail, can you open it, and what happens if you send the message to a test recipient?

That feedback between learning and test design is central to TMAP's explanation of exploratory testing. You can start with ideas or a checklist and change direction when a result raises a better question.

Keep repeatable checks for agreed behaviour too. Once you understand a failure, its reproduction sequence can become a regression check. A session may also uncover a missing product decision that needs an answer before anyone can write a meaningful pass condition.

How do you write a useful mobile test charter?

A charter states what you want to find out. Choose a scope you can investigate on the available build and phone. “Test messaging” leaves too many directions open. A more useful mission is:

Investigate whether an unsent message keeps its text and image when the user leaves the composer and returns. Start with a signed-in test account and a local test image. Look for lost work, misleading previews and accidental sends.

This is a fictional app example. Assume its agreed rule is that an unsent draft keeps both text and image when the user switches apps, until they send or discard it. Link your own requirement or ask the product owner to confirm the rule before calling a difference a defect.

Reserve 45 minutes for this first investigation and ten minutes afterwards to review it with a peer. These timings are a starting suggestion; shorten the scope if setup or bug investigation uses most of the session.

Record the actual build number, device model, OS, environment and account state. Note whether this is a clean install or an upgrade with an existing draft. If you're choosing coverage across several phones, use the mobile device test matrix separately and assign each session a specific configuration.

Prepare a test recipient, harmless image and reset instructions. Confirm you can reach the composer before the session starts. Otherwise, an expired login can consume the time you meant to spend investigating drafts.

How should you choose the next test?

Start with an ordinary successful attempt so you know what the app displays. Type a draft, attach the image, switch to another app and return. Check the text and attachment, then deliberately send to the test recipient and inspect what arrived.

Follow any difference you observe. Here are illustrative notes showing how one result can shape the next experiment; they aren't findings from a tested product.

What you observe	What to try next	What to record
Text and image survive one app switch	Repeat with a draft saved before upgrading the app	Previous and current builds, draft contents and upgrade steps
The thumbnail remains, but the recipient gets text only	Repeat the same sequence with a fresh local image	Image source, actions before sending and the recipient's result
Leaving the composer prompts you to discard the draft	Check the agreed rule for navigating back	The prompt, chosen action and question for the product owner

Change one relevant condition when narrowing a failure. If you switch phones, accounts and image sources together, you won't know which difference affected the result. Keep the original sequence alongside each variation.

If the session raises a separate risk, jot it down for later. A draft investigation may suggest checking notification replies, but that deserves its own charter if it would take you away from the current question. The mobile interruption checklist offers more starting ideas when returning to the app is the risk you need to explore.

What can you copy into a session worksheet?

Keep this beside the phone. Use elapsed times or timestamps consistently, and write enough to retrace your actions without transcribing every tap.

Mobile exploratory testing session

Question / risk:
Agreed behaviour / reference:
Tester / date / session length:
App version and build / environment:
Device model / OS:
Install or upgrade history:
Account state / test data / reset steps:
Starting ideas:
Work reserved for another session:

Running notes (repeat as needed)
Time / starting state:
Action / input:
Observed result:
Evidence reference:
Next check and why:

Review
Behaviours and configurations checked:
Findings / issue links:
Questions / person who can answer:
Setup problems / time lost:
Risks not investigated:
Next session / owner:

For example, a note might read: “12:08 — attached local image A to new draft; switched to Settings and back; thumbnail remained; sent to test recipient; text arrived without image. Next: repeat with image B on the same build.”

How do you turn an unexpected result into a bug report?

Capture the failing screen before restarting or clearing data. A screenshot can show a missing attachment; a short recording can show the app switch that led to it. Use test data and check the evidence for private messages or notifications before sharing it.

Write a separate issue with the build, starting state, steps, expected result and actual result. For the attachment example, include both what the sender saw and what reached the recipient. Record whether the failure repeated, including unsuccessful attempts to reproduce it. If it happened once, say so and keep the evidence.

Keep observations distinct from explanations. “Text arrived without the image” is an observation. “The app lost permission to read the file” needs investigation. If the expected behaviour is unclear, record the question and who will answer it.

Link the issue from your worksheet. TMAP's charter and test-log guidance similarly keeps defect references beside the session's observations and conclusions. The bug report template generator can help format the finding for handoff.

What should you review when the session ends?

Read through the notes with a peer while the sequence is fresh. Check whether someone else can follow the most important finding, which questions need a product decision and what to investigate next. A session report is also part of session-based test management.

State the limits of the work. “New drafts retained their attachments after app switching on this Android build; upgrade drafts and iOS weren't checked” tells the next tester where to start. If setup consumed half the session, record the obstacle and arrange another run. Leave with an owner for the unresolved question or the next charter, even when you found no bugs.