Exploratory Testing (ET) is a risk-focused testing method in which testers explore systems to identify areas of risk, in addition to checking expected functionality. As testing reveals risks, the tester uses what they have learned to inform the next tests that they should perform. This continues until all areas of risk in the application are explored and addressed. Exploratory Testing works well with agile projects because it improves testers' ability to interact with the system and allows them to create effective tests quickly. It also encourages testers to be creative and discover bugs that other testing methods, like using defined test scripts, cannot.
Exploratory Testing is most useful when it complements tests for expected behavior, but it should make up the majority of the manual testing on any project. If possible, it is also recommended to use ET in conjunction with other testing methods, like Automated Testing and Performance Testing, to ensure full code coverage.
Exploratory Testing can:
Exploratory Testing should be performed as part of agile sprints to ensure that each sprint results in fully tested software. While Exploratory Testing typically occurs after functional testing, it can occur at any point in the sprint (e.g. during development, peer review, or regression testing).
When and how to test should be decided early in the project and should be included in the team’s Definition-of-Done documentation. All user stories should be Exploratory Tested, especially those flagged as high-risk during sprint planning.
Examples of When to Exploratory Test
One way to use ET is to hold a Bug Bash where the team dedicates time to Exploratory Testing. This can focus on testing an entire application or specific pieces of functionality and can be done at any point during development or as a way to prepare for Go-Live. Doing so will catch bugs in the application which may have been missed during development.
ET can also be conducted after Sprint Demonstrations so stakeholders can also participate. The benefit from this practice is that stakeholders can simulate their real-world roles on all available devices (PCs, tablets, cell phones, laptops). Results from these sessions provide quick feedback and build trust in the system.
Any available project resource can perform Exploratory Testing . Often the development team is used to perform ET, since they have intimate knowledge of the functionality and code being tested. If possible, use all available resources including stakeholders (in UAT, for example) to help conduct ET.
Regardless of when a team decides to Exploratory Test, following the guidelines outlined in this section will ensure that the tests are specific and well-documented.
In order to make tests specific, testers should design test charters to guide their tests. Test charters should be broad enough to allow for exploration, but specific enough to ensure that they can be tested deeply and fully. Each test charter should include three features:
Example: Explore paging grid functionality with various paging/sorting/filtering combinations to discover problems with grid saves and data refreshes.
When testing charters, if an area of risk is found when testing one charter, create another charter to discover bugs within that area of risk. This should continue until all areas of risk have been tested and the tester is comfortable with the results.
If a team develops with design documents, test charters can be included along with the design and reviewed with the team before development begins to ensure alignment and fuller test coverage.
It is helpful to timebox your testing to reduce redundancy and maximize development time. The allotted time should be based on testing complexity and can be an estimate. Generally, testing should be finished when the tester is confident that they have tested every risk that has been identified. If the tester has not used up the time allotted for testing but feels that new tests would be redundant, they should stop. Likewise, if the tester has used up the time they originally allotted but still feels that there are areas of uncertainty in the functionality, they should continue until they feel comfortable that they have tested thoroughly.
If timeboxing testing is new to a team, it may be useful to track the estimated time required against the actual time taken to test to determine whether estimates are good and adjust as necessary.
The following heuristics are named and outlined by Elisabeth Hendrickson in Explore It! Reduce Risk and Increase Confidence with Exploratory Testing¹. These are techniques for testing an application in an exploratory manner. Each testing heuristic includes one or more examples illustrating how it can be used in an Appian context. While testing, think of other ideas or patterns you can try to disrupt, using these heuristics as a baseline.
1. Hendrickson, Elisabeth. Explore It! Reduce Risk and Increase Confidence with Exploratory Testing.Dallas: The Programmatic Programmers, 2013.
© 2024 Appian. All rights reserved.