Exploratory Testing has been around for several decades now. Every tester has been knowingly or unknowingly practicing it in their daily testing activities. There are various definitions and methodologies surrounding this testing approach. One of which is session based exploratory testing (SBET). Some confuse this testing approach with Ad-hoc testing without realizing it is way more powerful and structured. Here is a formal introduction to this testing approach and how to use it in your daily testing activities.
What is SBET?
SBET are time boxed uninterrupted testing sessions focused on a particular goal (module, feature, scenario). There are different approaches and templates used for this approach.
Advantages of SBET
This can be used within any domain, project or application; where you can get quick feedback about the application instead of writing detailed test cases (scripted testing). You get more flexibility in exploring the product and get to use your creativity within the boundaries of the goal of the session.
How to do it?
I personally have had a lot of success pairing up with another tester/developer and we both execute the same scenario in different devices/environments and discuss our observations. For example – Say, I am testing a mobile web application; I will have my colleague test the web app on an Android Tablet and I may have an Apple phone. Then we both execute the same scenario and discuss the observations. Just by doing this you can uncover lots of rendering issues, inconsistencies and unexpected behavior.
Structure of SBET?
SBET usually follows the below structure. They are-
- 45-90 minute Time Boxed sessions
- Have Charter/Goal document to guide the session
- Note down test ideas/scenarios
- Paraphrase/Debrief the observations
- Discuss Observations with a developer/business person
- Log Defects based on the discussion
All the session notes are contained in what is called a Charter Document. This is a document that contains all the details about the session including the goal of the session, necessary resources used in the session, task breakdowns containing time spent on performing different tasks during the session, session notes containing helpful information along with the test ideas and observations, issues uncovered during the session and any screenshots (if necessary).
So 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.
Doing a number of SBET sessions helps to
- Get a better idea about the product features
- Uncover bugs that would be otherwise hard to find with scripted/automated testing
- Identify high risk areas
- Identify mundane tasks in manual testing which are time consuming, which are good candidates for automation
How it fits into automation?
Doing SBET helps to set the stage for automation. It helps to learn about the application and think about different scenarios to automate. It is good to have SBET and high level automated tests running in parallel as it gives you good coverage of the application. The time you invest in automation depends on your context i.e how many people are available to do automation, the skill sets, cost vs value of doing automation, timeline and what tools/framework you are using.
After a month or two of getting to know the product by doing SBET, you can start doing some time boxed experimentation with different tools that are available for automation. Then you can practically see what fits your needs. Once you identify the tool, you can start automating the different scenarios.
How SBET fits in Agile Projects?
Given the flexibility SBET provides, the next question that quite often comes to mind is – When is the right time to do SBET? The answer is it depends on the context of the project. If you are just the lone tester or have only 2-3 people in the testing team, you can start doing ET sessions on each user story. Once you get a fair understanding of the functionalities of the application, you can start writing high level test cases and pick out scenarios for test automation based on the knowledge gained from these sessions.
If you are working in large scale agile projects and have a big test team, then you could follow the below approach-
- For each story, discuss the acceptance criteria. Based on that discussion, identify scenarios that can/cannot be automated
- For those scenarios that have to be tested manually, figure out the risk and impact associated with the story. For example – If the story is about implementing the payment functionality of a banking system, then there are high risks and huge impact to the customer and the organization, if the feature is not implemented correctly and we do not get proper test coverage. On the other end, if a story is about increasing the font size on the web page from 12 points to 15 points, the risks and impact to the customer are lot lesser. Do customers really care if the font size was not changed correctly? The answer could be Yes; but the impact is minimum as the customers would still be able to perform the required transactions in the application. But if the payment system is not working, then customers cannot make a payment which is a huge deal
- Once we identified the story as high risk and impact, we can write high level test cases covering the acceptance criteria and some edge cases. This can then be supplemented by one or more ET sessions to explore certain aspects of the functionality in more detail
Once an ET session is complete, all the documentation generated from the session (which usually would be ET charters filled with information) can be attached to the specific story for better traceability and letting stakeholders know the details about the ET session including the different issues uncovered. This way, everything is documented and available for future reference.
During regression testing phase, one or more of these ET charters could be reused to perform additional sessions. Some of the scenarios from the ET session can be converted into high level test cases or automated test cases. Thus, ET sessions can start right from the story testing phase and can extend all the way till acceptance testing phase.
Remember, SBET is NOT a replacement for scripted test case execution but is performed COMPLEMENTARY to it. It is an approach that helps in exercising the creativity and experience of the tester to get more information about the product. As a result, stakeholders can make informed decisions.
