Exploratory testing is one of the most effective and powerful methods of testing. It combines activities such as test design, execution, and documentation; it focuses on learning the application under test.
Furthermore, exploratory testing involves a lot of thinking and hence is incredibly beneficial for the person who is undertaking it. As a result, whoever uses this testing method must employ various thinking processes, including conscious, logical, and documentation; it focuses on learning the application under test.
We can say that testers are knowingly or unknowingly using it in their daily testing activities. One of the widespread methodologies 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 that the tester wants 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.
Here’s an amazing free online tool- QR Code Generator that helps you create random QR codes easily.
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.
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.
HTML to Markdown Converter makes it easier to save and distribute Markdown code.
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.
A PX to REM converter is a tool that converts pixel (px) values to root em (rem) values.
Oldest comments (0)