Sub Menu
Exploratory Testing
Exploratory testing is the most efficient and effective approach to testing software. It produces useful results from the first hours of testing, and finds the biggest bugs faster than any other approach. Furthermore, it finds bugs that other approaches won't find at all.
What is Exploratory Testing?
The definition we prefer is
Exploratory testing is simultaneous test design, execution and learning.
How is that different from structured testing?
Structured testing, as promoted by certification bodies such as ISEB, is designed to verify that the software under test meets the specified requirements. This is not the same as verifying the quality of the software. Testing is directed and constrained by the design specification and test plan, both of which may have been created before a line of code was written.
Exploratory testing is not constrained in this way. The objective is to expose information that is of value to stakeholders and assess the quality of the software, of which compliance with the specification is only one factor.
Emergent Behaviours
Exploratory testers are always looking for what we term 'emergent behaviours', which are behaviours that could not have been predicted prior to the start of testing.
Structured testing focuses on expected behaviours, so emergent behaviours remain entirely untested. It should not be a surprise that this is often where the biggest bugs are found.
Learning
We sometimes run tests just to learn about an aspect of the application's behaviour, and each test provides information that allows ever more powerful tests to be devised. This knowledge is invariably lost in structured testing projects.
Rather than ask does the application meet this requirement
, we ask questions like what happens if...
Adaptability
The exploratory tester starts with an outline test plan in mind, but can adapt it in response to changing contexts. If one part of an application is not yielding bugs, it may make sense to test in other areas instead. Alternatively the tester may consider using different test techniques in the same area.
Documentation
Our aim is to produce only as much documentation as is required for testing purposes and by other stakeholders. Depending on the context, this can range from a great deal to none at all.
We often do not need to have the functional specification in order to test an application. We find our own oracles, compare the behaviour with similar applications and draw on our experience of hundreds of previous projects.