Let’s Explore – Think Beyond Traditional Testing Boundaries

Just Explore, Explore, Explore the application – these are words we commonly come across when a new tester enters into the team. Basically by exploring, testers are able to learn,discover and investigate the product while testing the same. In advance ET can be used for finding some critical bugs which are not found using scripted document.

One of the real-time examples we generally face during release time is ‘while playing with the product we are free to do what we are not supposed to do; we may get a critical bug which delays the product release that too after completing the last round of regression which was not a result of any documented test case. Here, Exploratory Testing plays a major role.

What exactly is Exploratory Testing?

The product should do what it is supposed to do and it should not do what it is not supposed to do.

Exploratory Testing is like playing Chess. A good chess player plays his next move depending upon the opponent’s move and the stage of the game. The focus of ET is more on testing as a thinking activity.

It is the most important part of test lifecycle. Limiting our testing boundaries makes us an incomplete tester. Most of the time testers think that their duty is over if regression testing is done and bugs are reported. But it is the moment when tester’s real job starts. In regression we only cover test scripts using the Scripted Test Execution but there are some situations where we cannot document each and every small scenario. By using ET we not only find defects but also provide confidence about the product quality. It also improves the tester’s analysis skills and enables the tester to become more innovative.

Most of us may think that Exploratory Testing comes under Ad hoc testing, but it’s not true. Ad hoc testing is done with a perspective that we know the product and its functionality, and randomly check its functionality.

Simply put, if an expert bike racer is checking his bike randomly, by applying full acceleration and brake simultaneously, it’s called Ad hoc Testing as he is somehow aware about the end result and knows how it works.

If a person who never rides a bike tries to check a racer bike randomly, he learns while exploring what is an accelerator and what is a brake, and then tries to apply both simultaneously, it’s called Exploratory Testing.

Who should perform Exploratory Testing?

Informal Exploratory Testing can be done by anyone in the team including testers, developers and business analysts. It is an excellent way to know both strengths and weaknesses of the product. The more we explore, the better it is as we then cover the product in every perspective and verify the defects. But for formal Exploratory Testing, we require a skilled tester who has the following qualities:

• Passion for testing
• Critical Thinking covering the out-of-the-box view
• Quick Learning
• Communication (both Oral and Written)
• Bug Hunting and Bug investigation

How to look at a product from different perspectives?

• Understanding the Customer: We need to check the purpose of the product. But how can we understand the customer’s point of view? Simple. We should think like the customer. Thinking just like a customer is not enough. We should think how different customers handle the product because no two customers who bought the same raw materials will prepare the same recipe as they have different mindsets.
• Mindset: We shouldn’t set any expectations when we start exploring the application as it stops our thinking to a certain limit. So open up and think beyond the expectations as every bug can’t be found by a scripted test.
• Know the Competitors: Everyone wants to have something extra for what they pay. As a tester, finding bugs is not our only responsibility. Our focus should be to make the product qualitative. So even if we cannot find something, we can definitely suggest a useful functionality we observed in a competitor’s product to make the product better.

Exploratory Testing is like a Crime Scene Investigation i.e., solving the case just by exploring clues. Moreover, it is better to test well enough in many ways than to test perfectly in just one or two ways.

(Vikas Donkeshwara works as QA Engineer at [x]cubeLABS. He has 3 years of testing experience in domains like Education,Healthcare and Finance.)