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.
