Exploratory testing, as opposed to “scripted test cases,” allows the tester to explore an application without rigidly defined boundaries. That being said, it does require some amount of structure and discipline. At STAREAST 2012, Agile consultant and trainer Bob Galen
Requires Free Membership to View
will be speaking about session-based exploratory testing (SBET) on Agile projects. We
find out more about what SBET is and how it’s used in today’s Agile
environments in this Q&A.
SSQ: Can you briefly tell us exactly what "session-based" exploratory testing is all
about?
Bob Galen: That’s a hard question to answer briefly, but I’ll try.
Exploratory testing is a technique where testers ‘explore’ an application and keep notes regarding their ‘travels’ and ‘findings.’ One of the challenges with exploratory testing is how do you focus or bound the testing so that you’re focusing on a specific area or component of an application—rather than simply bouncing all over the place.
To combat this, Jon Bach created the notion of charters that ‘bound’ your exploratory testing exploration. For example, if you were decomposing Microsoft Word for exploratory testing, then you would establish a set of charters that might bound testing for text attributing, editing and reviewing features.
A part of decomposing into charters is the session length or the amount of time you time-box for your exploration. I typically time-box my sessions for 90 minutes, so that comes into play when you decompose—meaning you want to allow sufficient time for someone to fully explore their charter within the session.
At the end of the session, you typically debrief your findings with others. I often will run SBET in a team format where a whole-team executes multiple charters while working in pairs. It’s this team-based view that I believe aligns incredibly well with Agile methods and teams.
SSQ: I haven't heard about SBET until now. Is this a common way to do exploratory testing? In what situations would you recommend using SBET?
Galen: Jon introduced SBET as a mechanism to improve the management and reporting of exploratory testing. That’s probably an over simplification, but I think it a fair characterization.
At this point, I think if any team engaging in exploratory testing, then they’re a solid
candidate for applying charters and sessions around their exploratory testing.
SSQ: Can exploratory testing be automated? For example, if an exploratory session is recorded
with a record/playback tool and a bug is found, can the playback of the recording be used for
regression testing? Do you recommend this practice?
Galen: I don’t think that automated is the right view. To your point, exploratory testing is enhanced with the use of any desktop tool that allows for application context capture and facilitates logging of your session.
So, ‘playback’ as a means of reproducing a bug for repair is relevant and helpful. But trying to record exploratory testing sessions for ultimate automation design and development extends the technique beyond its original intent. I don’t think it particularly helpful.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
For comprehensive conference coverage, see our Software Testing Analysis and Review conference page.
Bob Galen is the author of the book Scrum Product Ownership – Balancing Value from the Inside Out.The book addresses the gap in guidance towards effective Agile product management.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation