top of page

Session-Based Test Management (SBTM) in Agile Development

Exploratory testing is one of the most effective and powerful methods of testing. It combines different activities such as test design, test execution, and test documentation; it focuses on learning the application under test. Exploratory testing is one area where applying different ways of thinking is especially beneficial. As a result, whoever uses this method of testing will have to employ a variety of thinking processes, including conscious, logical, and calculating. Above all, he needs strong intuition to know when, how, and where to dig deeper during the testing process.

We can say that testers are knowingly or unknowingly using it in their daily testing activities. one of the methodologies that are very common for this testing approach is session-based exploratory testing (SBTM). This methodology is based on the idea of creating test missions focused on a particular goal, exploring it without interruption for a specific period, recording the results, and following up with a debriefing session.

An SBTM session can last from 60 to 120 minutes but there is no real rule on the time spent for testing, it all depends on the Goal we want to achieve in a particular session and its complexity. After the session is completed, each session is debriefed and shared to allow relevant stakeholders to understand the session results, provide feedback, and provide the tester with ideas on how to improve in future sessions.

Here is a formal introduction to this testing approach and how to use it in your daily testing activities.

From Wikipedia:

Session-based testing is a software test method that aims to combine accountability and exploratory testing to provide rapid defect discovery, creative on-the-fly test design, management control and metrics reporting. The method can also be used in conjunction with Scenario testing. Session-based testing was developed in 2000 by Jonathan and James Bach.

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 discuss observations/insights at the end of the session.

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

  1. Create Time Boxed session (60-120 minutes)

  2. Set the goal to guide the session.

  3. Create the scenarios you want to execute.

  4. Debrief the observations.

  5. Discuss observations with the relevant committee.

  6. 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, resources used, but also the main observations and issues uncovered during the session. Recording this information will allow everyone to understand why we running this session, the time it takes, and what are the main findings.

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.

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 fit also to 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:

  1. For each user story, brainstorm the acceptance criteria, identify business flows to test (Manual and Automated).

  2. For those scenarios, determine the risk and impact associated with the story.

  3. Once we identified the risks and business flows, it is time to create the technical test flows that will be used as an input to the SBTM process.

  4. Once an ET session is complete, all the documentation generated from the session can be attached to the specific story letting the team the details about the ET session including the defects and issues uncovered.

30 views0 comments