Raise your Exploration Game!

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?

Image Source- xenonstack.com

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!

3 thoughts on “Raise your Exploration Game!

  1. Hi Nishi, great article on exploratory session structure.

    I have a question regarding the Test Charter Picture.

    It seems that you tried to provide an example for Bach’s Session-Based Test Management. If this is the case, then charter heading and area are not proper examples.
    Proper example in this context would be:
    Charter: Find all data flows.
    Area: Login form, release 1.1.2.

    From where did you get this charter example?

    Thanks!

    Regards, Karlo.

    Like

  2. Hi Nishi, thanks for the clarification. Do not forget about one important learning technique: the questioning source of information. It takes more time but is very valuable in recapping what you read/learned. Comparing software testing help article and Bach’s original article on Session-Based Test Management is a great practice opportunity.

    Regards, Karlo.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s