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.

In my article published at Testrail blog, I outline what do you need to do to bring structure to your exploratory tests and get the most useful information out of them?

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.

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. Continue Reading–>

Set the right expectations

Continue Reading–>

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!