Summary

This chapter described exploratory testing – when it should be carried out and by whom. We saw where exploratory testing fits into the development cycle, and that it is a powerful tool to find issues soon after code has first been implemented because it is quick and requires little planning. However, it needs a senior engineer to do it well, is not widely reviewed, and doesn’t produce extensive documentation. It can be hard to judge the coverage that exploratory testing provides, and non-functional tests may receive little coverage. That leaves the risk of issues in real-world usage even after exploratory testing has passed. The aim of exploratory testing should be to understand the feature better so that you can prepare comprehensive test plans later.

This chapter has shown when to start exploratory testing, not beginning too early when the code is still in flux, and the steps to get the first test running successfully. We’ve seen the importance of curiosity and naivety at the start of the test process, both in choosing what to test and checking the outcomes. Finally, we learned how to map out a feature, ready to perform a miniature version of the complete test process.

The next chapter takes the experience from exploratory testing and applies it to writing a detailed feature specification that will guide all the subsequent testing.