Exploratory testing in Agile projects
In Agile projects there is often a lack of time, which means, there is no room to prepare requirements, develop test cases, perform test design and go for test execution.
One of the best approaches to overcome such an issue is the exploratory testing technique, where test design, test execution and learning occur at the same time.
When to use exploratory testing?
Exploratory testing is an important part of your toolkit when testing stories, features and the system as a whole. This approach is used in combination with other methods such as experience-based techniques and risk-based techniques.
When there is limited budget for testing, in case of lack of time, when a project that doesn’t justify too much time spent on the writing process, when there is not enough or out of date documentation, or when there is a project management method that allows for quick development and release times, the exploratory testing technique becomes the best approach.
Some examples in practice…
…when you need to explore a problematic area and scripts are not needed.
…when there is no documentation about the project.
In this kind of situations focus on the functionalities and paths that are important, creating flow charts and simply test the application as the user would.
It is also possible to use exploratory testing when playing the role of ´the bad user´, trying to break the system in order to determine its weaknesses.
How to guide Exploratory testing?
The non-existence of scripting and requirements, doesn’t mean no planning. Exploratory testing requires preparation and execution in a specific time-box.
How to guide an exploratory test session is just creating a test charter where the test goal and all logs are captured during an uninterrupted test session of maximum 120 minutes. During this time the tester:
- Learns how it works: gets familiar with the product under test.
- Evaluates the functionality or characteristics: it is a good practice exploring with personas, that means different end users; creating different flows and executing them in different sequences, also called tours; using the story acceptance criteria; identifying architectural risks, etc.
- Identify different scenarios, interactions and corner cases.
The test charter should contain the relevant information for test execution, such as date, project data, tester’s name, setup environment, findings, references, priority, etc. Depending on the information needed I have prepared a useful test charter that contains all the information required for my test sessions, keeping as simple as possible:
Remember that exploratory testing can complement other testing methods that examine systems in different ways trying to answer the basic question:
Are we building the right thing?