Testers begin their journey as explorers.
Why is that? It’s because exploration is how you truly find bugs. You must first venture into the system not knowing what to expect and try everything you can to break it. Only then can you find where the bugs are and start writing automation tests to check for them in the future.
That’s exploratory testing in a nutshell. In this article, we’ll show you how to do exploratory testing effectively, and what tools can assist you in the process.
Exploratory testing is an unscripted, manual software testing type where testers examine the system with no pre-established test cases and no previous exposure to the system. Instead of following a strict test plan, they jump straight to testing and make spontaneous decisions about what to test on the fly.
Prior to the testing phase, they might list down some concepts or areas to explore, but the essence of exploratory testing still emphasizes the tester’s personal freedom and responsibility in simultaneous knowledge acquisition and quality checks.
In a way, exploratory testing is similar to an exciting adventure where testers don’t really know what lies ahead of them, and they must utilize certain techniques to uncover those mysteries.
During exploratory testing, testers explore the software by interacting with it, trying out different features, then observing its behavior. They may even intentionally break the software, input unexpected data, or explore edge cases to uncover potential issues. As long as testers get to understand the system’s workings and can suggest strategies to test the system more methodically, they have accomplished the task.
There are 3 styles of exploratory testing:
Exploratory testing plays a crucial role in software testing, especially Agile projects, where automation testing has taken precedence. Automation testing admittedly brings a wide range of benefits to QA teams, but it is impossible to ignore exploratory testing and more broadly manual testing.
A recent research compares exploratory testing (ET) with test case based testing (TCT) in terms of their effectiveness for catching software defects. Results show that:
Take a look at this table to better understand what we meant. The data shows that for the defects that ET revealed, the proportion of defects that were difficult to detect was higher. In the defects revealed by TCT the proportion of the obvious and straightforward defects was higher.
In other words, exploratory testing helps testers catch bugs that automated testing would have missed.
Why this happens? Because automation testing can only catch bugs that we know may happen (we can only create test scripts for something we know about), while exploratory testing catches bugs that we don’t even know to be existing in the first place, tapping in the Unknown Unknown region of our understanding.
Exploratory testing and manual testing in general expands the test coverage to blind zones of automation testing, pushing product quality to a new level.
Exploratory testing is free-style and not as rule-based as automation testing, and this characteristic opens up a lot of room for creativity and innovation. If a tester individually performs exploratory testing, they need to apply their domain knowledge, intuition, critical thinking, and even user-centric thinking to interact with the system and uncover potential issues.
An even better approach to exploratory testing is applying the pair programming principles, which involves 2 people - 1 driver and 1 navigator. In a time-boxed period, the driver performs the actual testing while the navigator observes, provides guidance, and takes notes where necessary. Sometimes called Crowd Exploratory Testing, this approach maximizes the level of creativity and subject expertise of both testers while encouraging knowledge sharing and collaboration between team members.
In the words of Cem Karner who coined the term for this testing type: “[exploratory testing treats] test-related learning, test design, test execution and test result interpretation as mutually supportive activities that run in parallel throughout the project.” As exploratory testing requires minimal to no planning, it can be conducted almost whenever we want, giving us the autonomy we need to learn about the product while also performing quality checks, saving time and resources.
In this era, the entire Quality Engineering industry is moving towards shift-left testing and continuous testing where testing is performed in synchronicity with development. Shift-left testing allows testing to happen earlier, leaving ample time for troubleshooting while improving the project’s agility.
Read more: Agile Testing Methodology: A Complete Guide For Agile Testers
There’s no better example of doing exploratory testing than this YouTube channel: Let’s Game it Out!
The guy behind the channel is Josh, and Josh really embodies the experimental spirit of exploratory testing. He pushes games he plays to their absolute limits. Sometimes he broke the system. Sometimes he discovered interesting bugs that the devs could never have thought of.
Check out how he's breaking the game Raft:
Exploratory testing can be applied throughout various stages of the Software Development Life Cycle (SDLC) thanks to its versatile and spontaneous nature. For example, at the Requirement Analysis stage where you need to gather information on the system for test planning, exploratory testing can provide a lot of valuable insights.
One of the remarkable aspects of exploratory testing is its flexibility in terms of timing, as it can be conducted at any moment, even if there are only 5 minutes available, by virtually anyone with software access.
Although it does not require initial planning, findings from exploratory testing sessions must still be carefully documented for future references. Therefore, the process of exploratory testing revolves around the documentation and interpretation of testing activities, including 4 major stages:
Bug taxonomy is the categorization of software bugs based on their attributes, characteristics, and criteria. Any bugs with similar attributes can be grouped into predefined classes to provide a structured framework for better understanding, analysis, and management. Here is a list of basic bug categories that you can consider:
These taxonomies can be organized in a simple Google Sheet, but when the project scales, QA teams may need a dedicated bug management and tracking tool for this part.
Read more: Agile testing methodology: A complete guide for agile testers
A test charter is a high-level document that outlines the goals, scope, and approach of a specific testing session. It is similar to the test plan in terms of purpose but more narrow in terms of scope. A test charter specifically created for exploratory testing should include the following basic items:
A free-style exploratory testing session would not need a test charter, but scenario-based and strategy-based sessions would definitely benefit from one to improve collaboration between members. This test charter also includes the taxonomies defined in the previous step for better management of newly discovered defects.
The “Time Box” sets a specific time limit for exploratory testing activities. It helps them stay focused and prevents them from spending excessive time on a single aspect of the system. This maximizes their testing efforts within that time frame to identify the critical bugs and pinpoint major areas for improvement.
In this time box, if a bug is found, testers will record and describe it in great detail using the taxonomies, then submit it to a bug management system where the status will be set to “New”. The developers will then investigate and try to reproduce the bugs locally before fixing it.
Testers can then evaluate the test results by comparing them against testing metrics, including customer feedback, usage statistics, and system performance data. This evaluation enables them to gain a general understanding of the test effectiveness, identify system defects, and gain valuable insights into the strengths and weaknesses of the product. It also serves several other purposes:
Technically there are no “exploratory testing tools”, since exploratory testing is simply a mindset and approach to testing, and therefore there is no tool dedicated to it. However, there are testing tools that improve the exploratory testing process. These include:
Other than these tools, testers may also need cross-browser testing tools if they want to explore the application behavior on different combinations of browsers - devices - OS without having to invest into physical machines supporting those environments.
Exploratory testing is just a small part of the larger testing process, which is why many leading testing tools are built to support several testing types and testing activities, not exploratory testing solely, to ensure that QA teams are supported throughout the entire STLC.
Katalon is a comprehensive quality management platform supporting test creation, management, execution, maintenance, and reporting for web, API, desktop, and even mobile applications across a wide variety of environments, all in one place, with minimal engineering and programming skill requirements.
For exploratory testing specifically, Katalon can:
The Record-and-Playback feature of Katalon essentially records all of the actions happening on your screen and stores them as automated test scripts that you can re-execute across a wide range of browsers and devices. In a way, this feature helps you simultaneously document the test, manage it in a centralized repository, and re-test it in the future.
All of the elements (buttons, form fields, etc.) captured during these Record-and-Playback sessions are stored as Keywords (essentially code snippets) in the Object Repository. Testers can easily drag-and-drop them to construct a new test script without having to code anything. It allows testing teams to quickly move from manual testing to automated testing at a low learning curve. In addition to all that, the Smart Test Reporting features give teams advanced test analytics for more informed decision-making.
Download Katalon now and start testing with ease
Ad hoc testing and exploratory testing have many similarities, but they are not at all interchangeable terms. Exploratory testing involves a certain degree of spontaneous planning, while ad hoc testing involves absolutely no planning beforehand.
Criteria | Ad hoc Testing | Exploratory Testing |
Definition | Testing without predefined test cases or formal structure | Testing approach with simultaneous test design and execution |
Test Planning | No formal test planning | Planning done on-the-go during the testing session |
Structure | Unstructured and unplanned | Small degree of planning involved |
Test Coverage | May have limited coverage depending on tester's knowledge | Can achieve comprehensive coverage based on tester's skills |
Documentation | Minimal documentation | Documentation is encouraged and captured during testing |
Test Design | Not focused on specific objectives or areas of the software | Focuses on specific objectives, risks, and areas of the software |
Test Execution | Ad hoc and based on tester's intuition and expertise | Systematic and guided by tester's skills and knowledge |
Time Management | Time is flexible and not predefined | Time boxed with specific durations for testing sessions |
Skills Required | Intuition and strong understanding of the System Under Test to guess potential areas with errors | Creativity and intuition, but deep understanding of the system is not required |
It is important to note that scripted testing is not just automation testing. As long as the testing approach is systematic, structured, predefined, and test cases are documented in detail beforehand, then it is scripted testing. Even manual testing with proper documentation can also be categorized as scripted testing.
Exploratory Testing | Scripted Testing | |
Approach | Ad hoc and flexible | Planned and structured |
Test Design | Minimal or no pre-defined test cases | Detailed pre-defined test cases |
Test Execution | Tester explores the system while testing | Tester follows predefined steps and expected outcomes |
Creativity | Encourages creativity and critical thinking | Limited scope for creativity and flexibility |
Test Coverage | May uncover unexpected issues and edge cases | Emphasizes known scenarios and specific test coverage |
Documentation | Minimal documentation, focus on real-time note-taking | Detailed documentation of test steps, expected results, etc. |
Skill Set | Requires skilled and experienced testers with good domain knowledge | Can be executed by less experienced testers with proper guidance |
Use Case | Ideal for early-stage testing, requirement exploration, and bug hunting | Suitable for repetitive and predictable scenarios |
No, Exploratory Testing is black box testing, not white box testing. White box testing is a testing technique where the tester has knowledge of the internal structure, design, and implementation of the software being tested. Exploratory Testing does not rely on knowledge of the system’s internal workings.
Exploratory Testing is primarily a manual testing technique. Some aspects of exploratory testing can be supported by automated tools, but the core essence of exploratory testing relies on human exploration and judgment. Test scripts for bugs found by exploratory testing should still be created for regression test runs to verify that they have been fixed. You can leverage the GPT-powered test case generation feature in Katalon to quickly achieve this.
Since it is just an approach, exploratory Testing can include both functional testing and non-functional testing.
Exploratory Testing is well-suited for Agile projects due to its flexible and adaptive nature. Agile projects often require fast feedback and continuous testing to accommodate frequent changes and iterations, and exploratory testing is perfect for that.