Exploratory testing is probably one of the most confusing topics in the world of testing.
The most widely used definition of exploratory testing says that it is an approach to software testing that is often described as simultaneous learning, test design, and execution.
This approach is the perfect complement to performing any other type of testing and is, so to speak, the antithesis of automation. While automation focuses on checking, exploratory testing focuses on learning, experimenting, searching for improvements and more complex points of failure. Which does not mean that automation cannot be used when conducting an exploratory testing session.
Exploratory testing is the perfect complement to any other type of testing.
When we talk about exploratory testing, we must take into account 5 key aspects:
They are not tests limited to testers: Although the tester normally has special skills when executing exploratory tests and can fully exploit all their qualities (lateral thinking, critical thinking, etc.), anyone can (and should) perform them. Even at certain times, exploratory tests in groups allow the skills and knowledge of different roles to complement each other when executing them and obtaining results.
They are not random tests: although their name may lead us to think of a type of random testing without a specific objective, the reality is that it is a type of thoughtful and planned testing:
♦ We will set a specific objective, what do we want to achieve with our session?
♦ We will establish a maximum completion time (it is usually recommended that it does not exceed two hours).
♦ We have to be clear about what materials or tools we are going to use as support: where we want to write down the findings, how we are going to communicate the results, etc. Furthermore, in case of doing an exploratory testing session in a group, the rest of the people involved in the session must be involved in all of this.
Don’t focus on finding bugs: This is just one of the options. Finding bugs is something inherent to every software product. It will always be good to perform exploratory testing looking for bugs, especially in more susceptible areas of the application or where we have already found a good number of them. But here we would be testing with a too reactive approach. The final objective should be to help build a quality product, and to do so we can set much more productive objectives:
Learning: set the goal of learning a certain part of the application in which we are not experts. It is also a great technique to include in the onboarding process of any role that joins our team.
Risk analysis: This is a key objective of exploratory testing. Be able to determine the status of an application by analyzing the risks of each of its components in order to take appropriate measures.
Proposal for improvements: it is very interesting to put yourself in the shoes of a potential user of the application and detect potential improvements.
Share the results with the team/organization: As we have already mentioned, we must set an objective to achieve with our exploratory testing session. At the end of it, we will have certain results: It is important to include interested people, communicate the results and propose next steps. The key to exploratory tests having value will be communication between the people on the team and improvements can be applied according to the results.
DIFFERENT TYPES OF EXPLORATORY TESTS
When carrying out exploratory tests, there are different approaches. Let’s look at two examples:
Based on Personas
They are exploratory testing sessions where the tester puts themselves in the shoes of a potential end user. Imagine, for example, an online store selling sporting goods. We will have to ask ourselves questions such as age, gender, the sport practiced, aspects common to all sports such as sports nutrition, etc…
Imagine that we put ourselves in the shoes of a father of a 7-year-old boy who has started playing basketball. In this case, the first thing we will do is imagine a potential client and create our own hypothesis:
Father, 40 years old. No knowledge of basketball (but knowledge of other sports). Acceptable computer skills. It rewards the ease of obtaining the desired product over variety and price.
Given this potential assumption, how might we structure our session?:
Having acceptable computer knowledge, it will not be so necessary for the “Basketball – children” section to exist or be visible, but we will need the search engine to work correctly and for the results to be consistent. As he rewards ease of reaching the product, it will be interesting to have suitable filters. In addition, he does not have relevant knowledge of basketball, so it will be interesting to check if the language used is understandable, that too much jargon is not used and that the products have understandable explanations for users.
Based on all this, with this method suggestions can typically be made regarding the usability of the application.
Based on Tours
The concept is similar to tourism. What do we usually do when, for example, we visit a new city and how do we relate it to exploratory testing?
Trip preparation: the city we will visit, how we will travel, documents we need and how we will stay. Taken to the world of testing, what application we will test, how we will access it, what we will need to be able to work on it…
What are we going to visit: most famous/visited places, specific places based on our tastes, etc… That is most used parts of the application, specific parts that have a certain interest for our role, etc.
How are we going to document our trip: we will take a camera, we will use the mobile phone camera,… and extrapolate to our context, how and with what tool we will collect all the data from our session: we will make screenshots, videos, logs, etc…
How are we going to communicate about the trip with our close friends/family both during and after it: we will make a video call with our parents, post a story on Instagram, etc… That is, how are we going to include everyone interested in our findings: we will create a meeting, we will open a ticket, we will write a documentation page, etc…
Of course, we will almost always leave time to get lost in the streets without a specific destination, or in other words, browse the application simply to see what we find.
Typically, this technique is used to learn about the product or a specific part of it.
So that you can see in more depth what an exploratory testing session is like based on the concepts previously explained, we leave you the link to a video with an example of this type of sessions: