Discussing the requirements and expectations with customers,
developers and other stakeholders is a testing activity, but surely
such discussion is not a test. Yet, such a discussion could potential
retrieve critical information about the product.

Thinking about how to create a test of some feature or component is a
testing activity, but surely thinking is not a test. I suppose
thinking is not likely to retrieve information about the product, but
it might reorganize information previously retrieved into a more
useful form.

In agile software development, for the acceptance criteria of each
iteration to be that exploratory testing reveals no defects is a
moving target that make iterative development much more difficult
without any benefit to the final delivery. Every defect that
exploratory testing finds should either indicate missing tests for the
agreed upon acceptance criteria of the iteration (in which case add
those tests) or missing requirements (in which case, add the
requirements to the backlog).

From this point of view exploratory testing does not discover defects
in a work in progress, it discovers discrepancies between where we
think the project is and where it really is. Those discrepancies are
then addressed as missing tests or missing requirements.

After we think the project is really completed, then those
discrepancies would be defects of the software, but not while we think
the software is a work in progress.

If you are attempting to do "agile testing" for a non-agile project,
then perhaps the traditional definitions hold.

Steve

On Mon, Mar 23, 2009 at 11:19 AM, Joao Rodrigues
<joao.rodrigues@...> wrote:
>
>
> --- In agile-testing@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
> ....
>
>> In the context of
>> software development, exploratory testing does not test software.
>
> It surely does. Exploratory testing is not an example, it is not a Test Case
> or a Test Idea per se, but it is part of testing activity, because it
> actually tests the software. It retrieves (or has the capability to
> retrieve) useful information about the product.
>
> You might think this is just an irrelevant language detail, but it is
> interesting to notice how developers tend to neglect details like this,
> while testers tend to overestimate the details. Often bugs are born on
> details...
>
> Joao Rodrigues
>