Exploratory Testing

Even outside of the Agile arena I use exploratory testing. Its a great way to discover the workings of software and how to break it!

An agile tester is often told that they should only think about exploratory testing when testing outside of the basic user story acceptance tests. All other testing is covered by unit and integration testing. But how often is this the case? Agile development is never perfect, and to find a project that has a fully functioning, good quality CI implementation that executes all unit and integration tests is not as easy as some seem to think. So, as a tester we need some rules to allow us to implement exploratory testing only when it is really necessary. The following is a set of guide lines that I use to identify exploratory test opportunities.

• Always use in conjunction with planned tests on high impact stories. Cover as much as you can!
• Use when trying to reproduce system failure.
• Use when defect clusters have been identified. This will flush out even more defects.
• Always use when you have a good technical understanding of the system architecture. You will already be aware of what usually breaks certain systems.

And when executing exploratory testing:

• Demonstrate a plan of action. Even a quick outline of what you aim to achieve by carrying out certain actions will give confidence in your actions.
• Write down all tests that are performed. I use a test short hand that describes navigation/action/result in just one sentence. This enables you to create more tests further down the line.
• Let the system risk analysis guide you to critical areas of the application. This is where exploratory testing pays off.
• Sit near to, or with the development team to enable quick solutions to problems and questions.
• Never rely on just doing exploratory testing.

Remember - Completely unplanned random actions on an application is not exploratory testing, but rather, bad testing.