Understanding Exploratory Testing In Agile
What is exploratory testing in agile?
Exploratory testing is about discovery, examination, and knowledge. As the name indicates, it’s about testers examining the application to observe possible edge cases. The testers must comprehend the several personas that are likely to utilize the application. This will enable them to enforce the exploratory tests with more success.
Exploratory testing is the coincident process of test design and test execution. Various scripted testing, it doesn’t restrict the tester to a predefined set of teachings. This shouldn’t be seen as a lack of practice but rather as a procedure of not constraining the tester.
The Agile method is based on the core principles summarized in the Agile Manifesto. They revolve around adaptive planning, early delivery, and consecutive improvement, intending to be able to accept to alter quickly and easily. Some exploratory testing tools are Testpad, PractiTest, Digivante Direct, Rapid reporter etc.
“It’s a simultaneous process between learning, specifying, and running tests.” — James Bach
Taking into account the thinking advocated by James Bach, this type of test suggests that you should spend more time running the tests than putting together a test plan with predefined scenarios.
This is also a way to find other types of problems that might go unnoticed at other stages of development.
The person who is performing the exploratory test decides what they will do with each action instead of following a previously created checklist, which helps in increasing the variety of scenarios. Because in this way, it is possible to create several variations according to which the tester gets to know the environment.
Even with so much freedom to decide what and where to test, at least one basic structure must be made.
Exploratory testing in software testing
Although we don’t recommend creating a complete test scenario with a predefined plan and test cases, we do recommend minimal preparation so that the test does not become an ad hoc and thus is complete without a real purpose.
1. Mission: A title that describes (without needing much detail) what will be tested inside a timebox.
2. Resources: It’s the environment that we test for the requirement of any setup (database records, access to other services, etc.).
3. Timebox: A timeout for running tests. This is an important point to focus on fulfilling the scope of the mission without distractions.
4. Problems encountered: Quick and succinct description of problems encountered. It is worth mentioning that they can be bugs, UX problems, doubts, among other points that are relevant to mention in the test session.
5. Notes: Any relevant information that could generate ideas for new tests or comment on what was found in the session.
Scope of mission
As we mention the importance of having a good testing mission since it is necessary for an idea of what will be done. Whereas we need to avoid some problems, such as:
Very specific missions: In this mission example, the scope of the test is specific in some conditions of a text field, which would not justify doing a testing session for this, since it would have very little to explore in this situation.
Very comprehensive missions: In this case, have a mission that seeks to evaluate all kinds of problems. With this scope, the focus will be difficult to maintain, which impairs its efficiency.
Very objective missions: In these examples, the missions are more objective, but at the same time offer freedom in the decisions of who will take the test. For these cases, the mission has to be thought to fit in a timebox, no matter how long it is.
To increase variation and generate new ideas in exploratory tests, the use of heuristics is quite interesting.
James Whittaker proposed in his book “Exploratory Software Testing” that:
Your system is like a tourist town and that you can visit several places from several different paths.
Money Tour: This heuristic is more focused on exploring the main features of the system; that is, those that make the user pay for your product. Although there are other features, the focus is on keeping these core streams dedicated to finding issues and inconsistencies that already exist.
Back Alley Tour: It is the opposite of the Money Tour, and the least used areas of the system are explored, such as configuration options. A little-used area can also be an interesting source for encountering problems.
Landmark Tour: Useful when any area of the system has some predefined step to be done. The idea of this tour is to change the order of how things are done. This also means increasing the variety of possibilities and going out of the way of “happy” functionality or what a set of them suggests to be done.
Intellectual Tour: This tour seeks to find problems in cases where you make the system “think”, such as when making a filter that returns many results or some other heavier processing. It is also an interesting option to see how the system behaves with a lot of data.
Obsessive-Compulsive Tour: As the tour name suggests, the focus is to try to simulate cases where users are obsessive/compulsive. Such as when filling in some field too fast or when you have the habit of clicking a button multiple times. This tour is interesting to catch these kinds of problems that at first may not have been thought of.
- Useful when there is little or no documentation
- Help cover other situations (increase variation)
- Generate new ideas for testing
- Encourage critical thinking
- Its efficiency depends on experience/skill
- They need some experience in the field
- Should not be taken as the primary test approach
Exploratory testing example
The test design and test performance activities are accomplished in parallel typically without formally documenting the test conditions, test cases, or test scripts. This does not suggest that other, more formal testing techniques will not be used. For instance, the tester may decide to use boundary value examination but will think through and test the most significant boundary values without certainly writing them down. Some notes will be composed during the exploratory-testing session so that a report can be created afterwards.
Exploratory tests are very valuable to find problems that could go unnoticed. This is in addition to improving the creativity and critical thinking of those who will take the test since it is the action of the tester himself to execute variations of test scenarios.
Even with this freedom, a minimum level of structure and planning is required to have more focus and efficiency when running a test session.