Editor’s Note: In the spirit of the famous advice columns of the past, one of our Tricentis Tosca experts has started their our own column: Dear Dr. Tosca. Have questions for Dr. Tosca? Send them our way in the comments!
Dear Dr. Tosca,
I’ve been a manual tester for many years but am looking to branch out into exploratory testing and have a couple questions:
First, exploratory testing has many forms; why do we choose session based testing over the other forms?
Secondly, can you give me an idea of how to get started and tell me if there is a way of freestyling my exploratory tests without the stress of re-creating my steps?
Timid [Testing] Explorer
Dear Timid [Testing] Explorer,
What most manual testers don’t realize is how the rigidity of manual testing can actually hinder your testing outcome. Applications are never implemented one-to-one according to their specifications. There needs to be flexibility when testing applications – that is where exploratory testing comes in. At the same time however, having complete freedom in testing can likewise become an obstacle.
As M. Bolton once said: “Session-based testing can be thought of as structured exploratory testing”. It makes exploratory testing plan-able, and therefore applicable for large-scale implementations (e.g. multiple agile teams). As a result of its structured character, it is one of the only techniques that can be reasonably supported by any tool to do exploratory testing. All this can be attributed to its core object: The session.
A session allows you to easily identify a starting point for exploratory testing. A session, according to Jonathan Bach, is a basic testing work unit: an uninterrupted block of review-able, chartered test effort. Each session is associated with a clear and concise mission, stating what we are testing or what problems and/or opportunities we are looking for in a given pre-defined time-frame (e.g. 60 to 90 minutes). Ideally the session will have no significant interruptions – no emails, meetings, chatting or telephone calls. A report or test summary should also be produced that can be examined easily by others and provides information about what happened during the testing, what was achieved, what got in the way of good testing, and what still needs to be done.
In regards to tracking your steps, you are correct – the hassle of documenting and/or remembering every key stroke and click can make exploratory testing a challenge. The answer is to have the right tools. Tricentis Tosca’s Exploratory Testing Assistant for example, is designed to alleviate this struggle by automatically capturing every click, keyboard interaction, and environment data across different technologies and platforms. Once you’re done, you can get a fully detailed report on your ‘testing exploration’ to share with engineering, helping to close the feedback loop to your business and development.
Using session-based testing along with a tool such as the Exploratory Testing Assistant provides a high degree of flexibility and freedom to the user. The constraints of session-based testing create a manageable scope in which comprehensible goals, achievable in a short time-frame, can be defined, while the right tools take the hassle out of the documentation process.
Want to learn more about Exploratory Testing?