Checking exploratory test results

While the input of exploratory testing is often clear – use all the new features, choose all the new options – checking its behavior may be obscure. If parts of the user interface haven’t been implemented yet, there may be no visible changes. The only available output might be database fields or log lines showing that the internal state has changed. If there are user-visible changes, they might be incidental – for instance, a changing interface that indicates that another change has occurred.

Sometimes, complete testing is impossible until some other change has been made. One part of the system is ready, but another part that uses it is not, for example. In that case, you can check whether the new functionality is ready and that it hasn’t broken any existing behavior, but full system testing will have to wait until all the elements can be used together. If so, you can complete some testing, and leave a task to complete it when the code is ready.

Early in the project, there may not be much documentation, or the specifications might not go into sufficient detail to describe the database implementation and logging output. Either way, you need to have a conversation with the developer to check what exact changes you expect to see in this code version. Only armed with that information can you be confident that not only are you exercising all the variables but that they also have their intended effect.

As well as the outputs the development team suggests, keep your eyes open for anything else that is strange or unusual. Be curious, both in the tests you run and in the checks you make. Curiosity is vital throughout testing, but especially in exploratory testing, as covered in the next section.