Exploratory Testing – What & Why its noteworthy

Exploratory testing is an approach / type of software testing. This testing type if not a traditional scripted one and takes more time than scripted.

Such testing is there from quiet some time, but was formally brought in by software testing expert Cem Kaner in his classic book, Testing Computer Software.

For the such testing, the tester needs to acquire good domain, application knowledge and is tender on the fly. This needs a tester to think, execute, listen and report.

What is the significance of this?

In today’s need of continuous integration and delivery speed of delivery is important.

Often traditional test cases were write down by following user requirements defined through BRD / user stories.

Edge case scenarios were often lost, during this process of adopting speed and lack of proficiency among testing team.

Such testing encourages experimentation, creativity to discover hidden flaws of defined workflow.

• It is an approach rather than a technique.
• This avoids structured approach of test cases defined based on already defined user stories / requirements.
• It helps testers to identify major discrepancies with respect to real world user requirements.
• This helps testers to build better functional test cases by understanding application in a  better manner.
• It allows testers to think out of the box and come up with the cases which might not be embedded by traditional cases.

Here are some statistics, shows how such testing helps.

• On an average, exploratory testing discovers 11% more defects than scripted testing.
• For defects that ought to be quickly self-evident, such as a missing button in the UI, exploratory testing discovers 29% more vs. Scripted.
• When it comes to “complex” bugs which requires three or more user actions, it jumps to 33%.

When do we require exploratory testing?

• To understand how the application works, what functionalities available, how they interact.
• To application under test is critical enough.
• Provide evidence of the capabilities in terms of functionalities the application intended for.
• The testing consists of most skilled & proficient testers.

When to say no for such testing?

• Lack of proficient testers on the team aboard.
• Testing is compliance based and compelled to follow required checklists. For example, accessibility testing where several laws govern the testing protocol and there are standards that need to be passed.

Exploratory testing supplement existing test strategy. When combined with other testing types it increases test coverages. The goal of such testing is to find bugs hidden beyond defined workflow.

For example,

You are testing a POST API, for instance the structure of an API is defined below as per requirement.

URI: /api/users

Body: 
{
    "name": "xxxxx",
    "job": "xxxxxx"
}

#name: Allows Aplhabets and Special characters
#Job: Allows alphabets

Traditional scripts include scenarios like,

• Valid response code.
• Verify using Alpha Numeric values.
• Validate using empty values.

In this case, exploratory testing includes scenarios like,

• Change sequence of keys.
• Delete keys and post request.
• Add additional key such as empid, department etc.,

Here you are trying to analyze and break POST API.

In another scenario, on an eCommerce site payment details proceed to the payment gateway.  Edit amount to be paid using inspect the elements and verify whether actual amount is passed on to a payment gateway or edited amount.

I took the example of Amazon,

Fig.1

Fig.2

Fig.3

Fig.4