How I do Session Based Exploratory Testing (SBET)
In the recent mobile testing workshop I did, I was asked how I do Session Based Exploratory Testing (SBET) and also whether it will be a good approach for start-ups and people who work in fast paced environments? Here are quick thoughts on SBET and how it is really useful to get quick feedback on your application.
What is SBET?
SBET time boxed uninterrupted testing sessions focused on a particular goal (module, feature, scenario). There are different approaches and templates used for this,
Advantages of SBET
This can be used within any domain, project or application, and is especially good for start up environments; where you can get quick feedback on the application instead of writing detailed test cases. You get more flexibility in exploring the product and get to use your creativity within the boundaries of the goal of the session.
How I do it?
I personally have had a lot of success by pairing up with another tester/developer and we both execute the same scenario in different devices/environments and discuss our observations. For example - Say, if I am testing a mobile web application, I will have my colleague test the web app on an Android Tablet and I may have Apple phone. Then we both execute the same scenario and discuss the observations. Just by doing this you can uncover lot of rendering issues, inconsistencies and unexpected behavior.
Structure of SBET?
45-90 min Time Boxed sessions
Have Charter/Goal document to guide the session
Note test ideas/scenarios
Paraphrase/Debrief
Discuss Observations
Post Defects
Everything is contained within the Charter Document. So everyone knows what was tested, how much time you spent on the session and it can be attached to a story or any repository you use for your test artifacts
It sets the stage for doing automation
Doing a number of SBET sessions helps to
Get a better idea about the product features
Types of bugs uncovered after doing SBET
Identify high risk areas
Identify mundane tasks in manual testing which are time consuming
Having set of smoke test cases based on experience testing the application
Then, I can invest in automation. It is good to have SBET and high level automated tests running in parallel, this will give 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, skill set, cost vs value proposition, timeline and what tools/framework you are using.
I would say after a month or two of getting to know the product, then you can do some time boxed experimentation with different tools that are available for automation to see what fits your needs.
Once you do the above, you have set the stage for more possibilities and more testing.