The Power of Session-Based Exploratory Testing

Mar 24, 2021 | Best Practices

software testing exploratory session

The field of software testing has changed significantly in the past several decades, but at least one thing will remain the same: Testers will continue to perform exploratory testing. Exploratory testing is a powerful approach that helps testers tap into their creativity and experience. It is simultaneous learning, test design and execution.

Historically, teams have performed exploratory testing in several ways using different tools and strategies. But if testers explore the product in an unstructured manner, it may be difficult to gather specific information to understand how this process fits with the overall testing effort, including automation and manual testing. Unstructured testing might lead to a misconception that an exploratory approach is not useful, particularly when teams already have robust test processes and strategies in place.

This is where session-based exploratory testing (SBET) can help.

What is SBET?

SBET uses uninterrupted testing sessions that are time-boxed, usually from 45 to 90 minutes, focused on a particular module, feature or scenario. During the session, testers document various information about their testing in what’s called a charter document.

This is a document that contains all the details about the session: the goal of the session, resources used, task breakdowns with time spent performing different tasks, notes containing helpful information along with test ideas and observations, issues uncovered during the session, and any screenshots.

With this document, everyone knows the details about the session and how much time was spent on it. The document can be attached to a story or any repository where you house your test artifacts.

When should you use SBET?

SBET can be used in various scenarios to cover edge cases and complement the existing testing effort. Startup companies that do not have any testing process can start doing SBET to learn about the product, test user stories, use the documentation from the session to create scripted test cases, and automate features.

Mid- and large-sized companies that have a formal testing process can use SBET at various stages of their development process, to test high-risk areas, and to evaluate features that are hard to automate. They can even use it in parallel to the regression tests they already do.

To release products faster, teams want quick feedback about the system. One way to do this is by using SBET before pushing builds to QA, to get more test coverage, to cover edge cases that people may not think of, and during user acceptance testing before pushing the feature to production.

All-in-one Test Automation

Cross-Technology | Cross-Device | Cross-Platform

How does SBET support automation efforts?

SBET is a great way to learn about different application features and which is a higher risk compared to others. Based on this, teams can start prioritizing automation features and will have a better idea of what to automate — and what not to. It also helps to gather test cases for automation, as all the effort during an SBET session is documented for future reference.

There are various tools available to document details of an SBET session and directly export the recorded documentation to test cases. This is a powerful approach to help new or less experienced testers pair up with more experienced ones to learn about an application while simultaneously testing it.

Remember, SBET is not a replacement for scripted test case execution; it is performed complementary to it. It is an approach that helps testers exercise their creativity and experience while getting more information about the product. As a result, stakeholders can make informed decisions, and the test team can better prioritize their efforts.

Related Posts:

Types of Automated Testing Explained

Types of Automated Testing Explained

Automated testing is a crucial part of software development. This guide helps you understand and implement the right types of automated testing for your needs.

API vs GUI: What’s the Difference?

API vs GUI: What’s the Difference?

APIs and GUIs have different functions and require suitable testing. Ranorex Studio’s test automation gives you the perfect testing program for APIs and GUIs.