What is Exploratory Testing?
Exploratory testing is widely defined as simultaneous learning, testing design and execution. Generally, a tester knows what to test but is unaware of how to test and perform tests on-the-fly. Exploratory testing does not rely on scripted testing and pre-defined test cases. It defines testing as a thinking activity that depends on the individual tester's skill, creativity, personal freedom and responsibility.
I hope you guys are familiar with displacement and distance travelled from high school physics. Think of displacement as scripted testing. It's straight, pre-defined to measure only the difference between two travelling points, and never deviates from it. Now, think of distance covered as exploratory testing. It's the total distance a moving object covers while travelling between two points. Your primary goal is to travel from point A to point B, but without a pre-defined path, you can move anywhere you like and take any turn you want before reaching point B.
Exploratory testing was often called 'ad-hoc testing' until software testing expert Cem Kaner formally introduced the word in his book "Testing Computer Software" in 1988.
Types of Exploratory Testing
Freestyle Exploratory Testing
You can understand freestyle exploratory testing as an ad-hoc approach. There are no specifications, rules, or processes for freestyle exploratory testing. It solely depends on the tester's thinking and needs. It is often performed with a quick walk-through of the application to investigate the bug or verify the work of other testers.
Scenario-Based Exploratory Testing
Take a specific real-user scenario for an application. Now, test according to the scenario in all possible ways to match the possible behaviours of the end user. To ensure complete test coverage, the goal is to test as many situations as possible.
Strategy-Based Exploratory Testing
This test can be carried out once you are familiar with the software or application. This testing often tries to break down the app using risk-based techniques and identify the more challenging bugs.
When to Use Exploratory Testing?
You cannot always rely on exploratory testing. Yes, it is an investigation technique that helps you explore out of the box, but doing so helps only after you are completely confident on previously prepared scripted tests or your instinct and skill as a tester.
Use exploratory testing when:
- A new member is added to a running project.
- Test coverage needs to be increased.
- Writing test cases for new products in the initial iteration.
- The application is critical.
- There are experienced QAs.
- The tester is confident and familiar with the software or application that needs to be tested.
Value of Exploratory Testing in CI/CD
Exploratory testing always helps in expanding the test scenario coverage beyond scripted tests. Since several experts are working on software or an application, not everyone could know about proper scripted testing other than QA engineers. In such cases, exploratory testing is convenient because it opens testing to all team members, not only professional QAs.
It is also not always obvious that there is a written specification for every feature or function of the software. There is always a possibility of a feature being added in the middle of the development cycle. Exploratory testing comes in handy in this case of partially available or unavailable required documents.
In CI/CD, exploratory testing enhances the scripted test strategy used by the QA teams as it is an investigative approach and consists of several testing sessions to find flaws and issues that have not yet been found.
Automation in Exploratory Testing
Is automation possible in exploratory testing? I must say yes to some extent because automation is always, to a certain extent, only when the tests are not well structured and scripted. The main purpose of exploratory testing is to investigate the software and mimic the unimaginable and unplanned user behaviour to identify bugs. Well, computers are not smart enough to imagine and plan themselves, so I suggest that a real person performs exploratory testing.
Difference Between Structured and Exploratory Testing
Structured Testing | Exploratory Testing |
---|---|
Is directed only by software requirements | Is directed by software requirements and exploration during testing |
Follows the complete scripted test process | Completely on-the-fly testing without any scripted test scenarios |
Test cases are pre-defined | Test cases are defined during testing |
It is a defined testing technique | It is an investigation approach |
Slower feedback with the ability to reproduce tests | Faster feedback and may or may not be able to reproduce tests |
Totally depends on scripts and is like reading a speech from a draft | Totally depends on the tester's mind and is like making an impulsive conversation |
Challenges of Exploratory Testing
Insufficient Product Knowledge
One of the major uses of exploratory testing is to go through the product to gather knowledge on that particular product, mostly by new team members or other team members except for the QA engineer. Members performing such exploratory testing are the ones who need quick knowledge or feedback related to the product.
However, this particular feature is also a challenge from a QA engineer's perspective. If a QA does not properly understand the product, there is always a chance of overlooking some crucial circumstances. If you are a QA engineer, your purpose in performing exploratory testing differs from that of other team members. So always keep the utmost knowledge of the product you are working on.
Traceability
Exploratory testing is often carried out on-the-fly, and we do not follow any pre-defined test plan, strategy or scripts. Since exploratory testing has progressive documentation, it lacks traceability and becomes challenging.
Let us suppose I discovered a bug during exploratory testing. If I do not document the process I followed before discovering the bug; it will be challenging to trace it back. So, you either need extraordinary memory power or progressive documentation of exploratory testing to overcome the traceability challenges.
Exploratory Testing in Agile
Agile methodology's primary goal is to produce high-quality products rapidly. Development is carried out in many short sprints in agile development. Short sprint means faster testing, and fast testing means exploratory testing, which is why exploratory testing fits so well in agile.
Exploratory style testing enables testers to acquire knowledge while evaluating the product and give quick feedback, which is crucial in an agile environment.
Let's read on to an example to define how exploratory testing fits in agile. According to the agile approach, it's critical to adapt fast to changes and accept needs adjustments even when they come late in the development process. So, this unique testing technique allows testers to swiftly test newly added features or functionalities. As a result, it enables teams to respond to changes on-the-fly.
Closure
Your manager often asks you, "Is the build ready?".
Being a QA engineer, I understand that we cannot always provide 100% confident answers, but the 100% responsibility of the app falls on our shoulders.
So while replying to the question, you can always buy a few hours to quickly test the most vulnerable parts of the software on-the-fly by making use of exploratory testing.
Exploratory testing seems like it will handle the overall testing of the software. However, it is not a good practice, no matter how skilled a tester is. Being in the IT industry means following a continuous development process but not some fancy ad-hoc approach. So, use exploratory testing only to investigate the possible out-of-the-box scenario that might affect the functionality of a software.
Let me know if you found this article helpful by leaving a comment below. Subscribe for more!