Exploratory testing combines learning, test design, and test execution into one test approach.
We apply heuristics and techniques in a disciplined way so that the actual testing reveals more implications than just thinking about a problem.
As you test, you learn more about the system under test and can use that information to help design new tests.
Exploratory testing should start with a charter of what aspects of the functionality will be explored.
It requires critical thinking, interpreting the results, and comparing them to expectations or similar systems.
With exploratory testing, each tester has a different approach to a problem, and has a unique style of working.
However, there are certain attributes that make for a good exploratory tester.
A good tester:
- Is systematic, but pursues "smells" (anomalies, pieces that aren't consistent).
- Learns to recognize problems through the use of Oracles.
- Chooses a theme or role or mission statement to focus testing.
- Time-boxes sessions and side trips.
- Thinks about what the expert or novice user would do.
- Explores together with domain experts.
- Checks out similar or competitive applications.
Good post, but I would suggest you not limit these attributes to only exploratory testers. These bullet points could and should be applied by all testers, whether they're exploratory, manual scripting or automating.
ReplyDeleteGlad you liked the post Chad.
ReplyDeleteI agree that the bullet points are not unique to exploratory testing, but also apply to manual testing, atuomation, scripting, GUI testing, scenario testing, use case testing, and so on.
Some bullets are spot on, some are not (for me):
ReplyDelete* Systematic - Yes
* Oracles - Yes, if they can be all unconscious, or named 'experience'
* Themes - I would prefer prulal, a great exploratory tester has many missions, themes and roles at the same time; many of them, again, unconsciously
* Time-boxing - No, there are many exploratory testers that do their best the full day, that takes the amount of time deemed necessary, and sees interruptions as being of service + inspiration
* Think about users - Yes
* With domain experts - Good thing, but not necessary or possible. What if the tester IS a domain expert?
* Competitors - Yes
If you want to expand the list you could add something about communication and "understand what's important".
Thanks for your comments Richard.
ReplyDelete"Understand what's important" is vital! And it's all context dependant.
A couple of your blog posts remind me of my blog posts, here's another: http://tinyurl.com/yjtnp3e
ReplyDelete