First I must admit that I have not yet read any of these resources and hope to inform myself better in the near future. With that said, it occurs to me that in the context of the two forums where ET was being touted so highly that it is much in common with Agile Development as a term. There are both good and bad usages of the term, it can mean many things to many people, and it can be used as either the excuse for poor, undisciplined process or properly applied, the only sane way to spend your testing resources.
What exploratory testing should not mean:
- Unplanned random walks through an application in hopes of stumbling across an undiscovered defect
- Randomly chosen data values (some of which make no sense) tossed into input fields in hopes of blowing up the application
- License given to a tester to explore at random whatever corner of functionality reveals itself from blindly clicking the app forms putting in minimal data
- Upon finding a defect, the tester can ignore the "steps for reproducing" part of the write-up of what happened
- Removing the tester's obligation to document or record their test results as an accounting of what and how they tested the application
Exploratory testing to me is just another term that akin to risk-based testing that all testing efforts should employ. Below are a few things that immediately come to mind as ways to be very careful to spend your testing resources wisely and not just trying to cover the waterfront of all possible parts of your application. As we all know, exhaustive testing is not cost effective or even possible in today's extremely complex systems.
- Start by testing the architectural risks of your application -- defects here require major redesign
- Test application areas of complexity in the new release (assuming multiple releases exist) -- defects here require design changes and possibly lengthy rewriting phases
- Test application areas where high concentrations of defects have been found previously -- defect riddled code is very difficult to reuse or modify without defects occurring
- Using static analysis tools, test application functionality that uses objects that are identified as knots and tangles -- these areas are core parts of many operations
- Test application areas using interfaces to legacy and external systems -- functionality may not be fully understood or clearly documented
Once these ideas were articulated as a "risk reduction" strategic way of testing an application, the burning need to support exploratory testing seemed to be reduced to a comment about "Oh yeah, that's what I wanted to see". In any case, the risk based testing support in RQM seems to be adequate to address this issue.
In summary, I need to read more about exploratory testing to make sure I haven't missed anything that could help distinguish our testing tools from others in the marketplace. At least, it seems there is enough synergy of discussing risk based testing that it quelled any concerns about the RQM feature set.
As always, comments or discussions are welcomed.