Session-Based Test Management (SBTM) in Agile Development

How to run an SBTM session?

There are different ways you can explore and use, but if I rely on my personal experience I can say that I had a lot of success when pairing two testers or tester and developer who run the session together where each one runs the same scenario on different environments and they then discuss observations/insights at the end of the session.

If you want to stick with the usual SBTM session, you can follow this structure:

• Create time-boxed session (60-120 minutes)
• Set the goal to guide the session.
• Create the scenarios you want to execute.
• Debrief the observations.
• Discuss observations with the relevant committee.
• Log defects based on the discussion.

In addition to the steps above, I also recommended creating a session report containing the information that will be shared during the debriefing session. This doc should include basic information such as session goal, test environments, and resources used, but also the main observations and issues uncovered during the session. Recording this information will allow everyone to understand why we are running this session, the time it takes, and what are the main findings. Not all test management tools store session notes as first-class records, which matters if you want reports to live beside the cases they came from.

A typical session report may include the following:

• Link to feature/user story
• Date and time started
• Mission statement and goal.
• Testers/developer names.
• Task breakdown
• Test environments
• Test scenarios.
• Potential defects found.
• Test notes.

What Does a Session Charter Look Like Today?

A session charter is a short written brief that names the area under test, the resources available, and the mission a tester must accomplish before a timed SBTM session starts. Without one, a session drifts into unfocused exploration and the debrief has nothing concrete to measure against.

• Area: the feature, module, or user story the session covers, for example the checkout flow or a search filter.
• Resources: the tools, test data, environments, or devices the tester can use inside the time box.
• Mission: the single risk or question the session must answer, for example whether guest checkout still validates a promo code correctly, written as one sentence the tester can check against at the debrief.

Satisfice's original SBTM format states a charter as one line: explore the area using the resources to discover the information. This charter belongs at the top of the session report described above, so anyone reading the debrief later knows what the tester was trying to accomplish and why.

How does SBTM fit in Agile Projects?

Given the flexibility SBTM provides, we can use it for both small and large Agile projects. The team can start using SBTM on each user story to get a fair understanding of the requirements and functionalities of the product. At the end of these sessions, the team can start writing high-level test cases based on the observations and issues they generated. The same approach can also fit large complex Agile projects with small adaptions.

If you want to add SBTM into your Agile software development process, then you could follow the below approach:

• For each user story, brainstorm the acceptance criteria, and identify business flows to test (Manual and Automated).
• For those scenarios, determine the risk and impact associated with the story.
• Once we have identified the risks and business flows, it is time to create the technical test flows that will be used as input to the SBTM process.
• Once an exploratory testing session is complete, all the documentation generated from the session can be attached to the specific story letting the team know the details about the session, including the defects and issues uncovered.

If you’re looking to improve your Agile interview skills, check out our curated list of Agile interview questions and answers.

From session notes to shipped coverage

SBTM works. The problem is what happens after the debrief.

A tester runs a 90-minute session on the new checkout flow, catches three issues worth escalating, and records a screen capture of a Safari edge case. It all lives in a doc, a Jira ticket, and a video file nobody will watch again. Six weeks later, when the flow regresses in production, none of that context is in your regression suite.

That’s the gap TestMu AI Test Management closes.

Drop session artifacts into the platform, whether notes, Jira tickets, PDFs, screenshots, or screen recordings, and the AI turns them into structured, executable test cases linked bi-directionally to the originating story. Manual and automated tests live in one place, and execution runs across 10,000+ real devices and 3,000+ browsers, so the Safari-only bug gets caught on actual Safari.

Free tier includes unlimited users and unlimited test cases. One-click migration from TestRail, Zephyr, Xray, and QTest. That turns each session's findings into ordinary test case management, reviewable like any other case. The product is Test Manager, and the Test Manager documentation covers importing your first set.

Exploratory testing finds the bugs worth writing tests for. TestMu AI makes sure you actually write them.

Start free with TestMu AI's test management platform