- An Elusive Bug
- Analysis
- Exploratory Testing on Agile Projects Can Be a Good Fit
- Exploratory Testing Is Highly Adaptive
- When To Apply Exploratory Testing
- For More Information
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When To Apply Exploratory Testing
Recently, exploratory testing has gained more exposure in the agile world. Some proponents have focused on using it as an end-of-iteration ritual in which the whole team and the customer are involved. This is a good idea, and I've used it much more than this on agile projects. I have done exploratory testing throughout development, from the first moment I have something to test, until we deliver the software.
The feedback I've had from other team members is that they love good exploratory testing when done by a skilled tester. Skilled test-driven developers have literally told me, "We love your exploratory testing." Exploratory testing helps provide them with rapid feedback, test idea generation, and supply more confidence in what the developers are delivering and the customer is receiving. Thinking about testing from an exploratory testing point of view helps provides feedback using diverse testing techniques. Sometimes the off-the-wall testing ideas find that tricky bug or expose potentially costly hidden assumptions. Most importantly, the interactive nature of testing in this way facilitates using the most powerful tool we have at our disposal: the human mind.
Developers frequently ask me to do exploratory testing during development. They might be partway through a story, and want some feedback on usability or whether the code they've developed matches the intent of the story. They'll ask again after they've developed a story: "Make it break. We want to find out where we have missed tests." At other times, I'll do integration tests by installing a build taken from a continuous integration environment into something close to production, and running integration tests or system tests. These exploratory testing sessions frequently help us find flaws that the unit tests couldn't catch. One particularly useful area has been in tracking down sporadic bugs, as I described earlier in this article. Agile teams can have unique problems with sporadic bugs because the team is moving so quickly and the code is changing, and the developers often don't have time to investigate these sporadic bugs thoroughly. Testers think about these kinds of problems all the time, and a disciplined exploratory tester can help gather information on these sorts of bugs.
I have also done exploratory testing at the end of an iteration prior to releasing software, and during pair testing sessions with testers, developers, and customers. Sometimes, a developer and I will do exploratory testing during test-driven development. Once the developer has a design in place with tests passing, we pair and run tests interactively against a testable interface in the code. We keep some of the ones we wanted to repeat, recording them as automated unit tests. On several projects, I've found exploratory testing to be a good complement to agile testing practices such as test-driven development and user acceptance testing.
Exploratory testing can be done in a highly disciplined way, utilizing the intuition and reasoning skills of a skilled practitioner. In the example in this article, exploratory testing helped identify hidden assumptions and provided good information on areas we had missed when testing during development. The philosophies behind skilled exploratory testing and agile projects tend to be congruent. If you're working on an agile team, I encourage you to learn more about applying exploratory testing throughout development, from beginning to end. There is enormous potential for diverse testing on agile projects; knowing more about exploratory testing will help tap into more of that potential.