Some people assume that exploratory testing is a task with low-effort thinking, where the tester simply goes through the application and sees what comes up. While we shouldn't discount doing just that, because sometimes it does reveal some interesting bugs, there are techniques and patterns that testers can follow when exploring an application. Let's look at a two-step process to use in exploratory testing.
Imagine you have X-ray vision. Instead of seeing through walls, you can see the inner structure of programs, the bugs lying inside, and how to expose them. Anyone could execute the steps you gave them to reproduce the bugs. The difficulty in testing, then, is not in executing steps; it is figuring out what steps to take. How do you find those hidden bugs? We need to be the X-ray vision.
Everyone on the software team has the same goal of delivering the best product they can, so letting testers discover bugs is always good—the more bugs found, the better! But misconceptions often lead to testers getting the bad rap of "breaking" the software. It's a tester's job to think like a user. Developers and stakeholders might call that negative testing, but the result is a better product, and that’s all positive. Let's change the way we talk about testing.
There are a lot of misunderstandings about exploratory testing. In some organizations exploratory testing is done unprofessionally and in an unstructured way—there's no preparation, no test strategy, and no test design or coverage techniques. This leads to blinds spots in the testing, as well as regression issues. Here's how one company made its exploratory testing more structured.
Exploratory testers design and execute tests in the moment, starting with an open mission and investigating new ideas as they arise. But how do we know when to stop? The first step is to recognize that we can't know when we're done, because any approach to answering the stopping question is necessarily heuristic.
Forget what you thought you knew about exploratory testing. Dion Johnson is disturbed by its exploitation by those who wish to escape accountability and forgo up-front planning, but says that exploratory testing and scripted testing can work together to enhance quality practices.
Among the hardest things to explain is something that everyone already knows. We all know how to listen, how to read, how to think, and how to tell anecdotes about the events in our lives. As adults, we do these things every day. Yet the level possessed by the average person of any of these skills may not be adequate for certain special situations.Exploratory tester James Bach describes eight key skills that expert explorers possess, and how you can develop them too.
In this interview, TechWell speaks with Bart Knaack, test advisor at Professional Testing, and his partner at the Test Lab, Wade Wachs. Bart gave a keynote at STARWEST titled "The Survival Guide for Testers and Test Managers."
Matt Barcomb works at LeanDog where he is passionate about building collaborative cross-functional teams and finding ways to make the business-software universe a better place to work, play, and do business. Heather Shanholtzer talked to Matt about exploratory testing in an agile project.
The concept of exploratory testing is evolving, and different interpretations and variations are emerging and maturing. These range from the pure and original thoughts of James Bach, later expanded to session-based exploratory testing by Jon Bach, to testing tours described by James Whittaker, to the many different ways test teams across the world have chosen to interpret exploratory testing in their own contexts. Though it appears to be simple, exploratory testing can be difficult to introduce into a traditional organization where testers are familiar only with executing scripted test cases and where the concept of exploration and creative testing may be somewhat foreign. At the same time, organizations need to address the challenges of traceability and reporting, moving from traditional ways to a more exploratory approach.
Typical automated tests perform repetitive tasks quickly and accurately. However, with some creativity, you can leverage automation to dramatically increase its ROI. Doug Hoffman demonstrates how to employ test automation for testing activities that are impossible with manual testing.
Charters help you guide and focus exploratory testing. Well-formed charters help testers find defects that matter and provide vital information to stakeholders about the quality and state of the software under test. Rob Sabourin shares his experiences defining different exploratory testing charters for a diverse group of test projects. For example, reconnaissance charters focus on discovering application features, functions, and capabilities; failure mode charters explore what happens to applications when something goes wrong. In addition, you can base charters on what systems do for users, what users do with systems, or simply the requirements, design, or code. Rob reviews key elements of a well-formed testing charter-its mission, purpose, focus, understanding, and scope. Learn how to evolve a test idea into an exploratory charter using examples from systems testing, Scrum story testing, and developer unit testing.