This is a guest post by Nishi Grover Garg.
Exploration is an integral part of testing. Exploring the application is a great strategy for learning about how it works, finding new information and flows, and discovering some unique bugs too!
Many testers perform exploratory testing as a matter of course, and agile teams may make it an integral part of their tasks. But how can you up your exploration game? Simply going around the application and looking or clicking here and there surely cannot be called creative exploration.
What do you need to do to bring structure to your exploratory tests and get the most useful information out of them?
Here is how you can enhance your test strategy and improve your exploratory testing game.
Designate time for exploration
As we get into the flow of agile and its fast-moving sprints, we focus on testing tasks for each user story and are constantly thinking of what needs to be done next. But with minimal documentation and limited time to design tests, it is imperative to understand that just executing the written or scripted tests will not be enough to ensure the feature’s quality, correctness, and sanity.
Exploratory testing needs to be counted as a separate task. You can even add it to your user story so that the team accounts for the time spent on it and recognizes the effort.
Testers can use the time to focus on the feature at hand and try out how it works, its integrations with other features, and its behavior in various unique scenarios that may or may not have been thought of while designing the scripted tests. Having exploratory testing as a task also mandates that it be done for each and every feature and gives testers that predefined time to spend on exploration.
In my testing days, this used to be the most creative and fun aspect of my sprints, and it resulted in great discoveries, questions, insights, and defects!
Follow a structure
Exploration time needs structure so that you do not get lost in the vastness of your application and lose track of your original goal. You need to have a specific area or feature in mind that you would like to explore, which most likely should be the user story you are working on.
I also used to ensure that I had tested the feature using the scripted tests already and found the obvious bugs (if any) so that I had some existing understanding of the feature under test. Exploration time could then be used to take the knowledge further and learn more about the feature.
There also needs to be a time limit. I read that exploratory sessions must have a timebox of one to two hours. I tried a one-hour timebox and found that it was sufficient to run through any feature I worked with, but you could try up to two hours based on your domain and the complexity of the feature at hand.
Set aside a predetermined timebox and schedule it so that there are no interruptions like meetings, breaks or coffee chats. I would even set my status as “do not disturb” so that nothing would interrupt my train of thought during my exploration.
Note your findings
Even though it is not recommended to jump into logging defects immediately within your timebox, it is important to jot down things you find. Have a system set up and ready to take notes.
It could be your old trusty notepad and a pen, a blank document open and ready, or you can use TestRail to setup exploratory sessions and note your observations. Whatever your choice, everything you do during the exploratory session needs to be noted.
Let’s say you found a new way to exercise the feature—you would need to later add it to your tests. Or you found an action where you did not know exactly what the expected behavior should be—you would later need to check that with your product owner and the developers. Or you found a place where performance of the application may be of concern—you would need to inform your team and begin monitoring for performance tests in the next sprint. Or you found a defect that needs to be logged in the system—you would need to note the details of the scenario so you don’t forget them later.
Take down all your observations so you can revisit them with your team later. These notes also act as a great way to showcase what was really done during these exploration sessions, giving some visibility to the awesome job you are doing!
Set the right expectations
As a definition, exploratory testing is more about learning than testing, so the team’s expectations from it should be as such. It needs to be made clear that exploratory sessions may or may not result in defects being found, but it will surely increase awareness and knowledge of how the feature works and help to raise pertinent questions.
Have your team look at your findings from your past or ongoing exploratory sessions, and share your observations and notes to make them aware of how this activity is contributing in many ways beyond finding defects. This will help them realize the multifaceted benefits of exploration, as well as open your mind in various directions when exploring the system.
I hope these tips help you include more exploration in your testing endeavors and raise your exploration game to make the most of your efforts!
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
