Blog

Exploratory Testing

codefuse Uncategorized Leave a Comment

A rather vociferous debate kicked off on LinkedIn Test Discussions over the last week about the pros and cons of exploratory testing. Two camps developed, (1) the traditionalists wanting to stick to a strict design -> test -> report model and (2) the explorers who were happy to design, execute and record simultaneously.

Of course the best choice is going to be context specific. There may be very good reasons for staying traditional. It may be that you are legally bound to follow a certain way of working. It could be that you need to be absolutely sure that all scenarios are covered, in which case you probably need a heavier up-front design process.

But in many, possibly most, situations exploratory testing would seem to be the best option. It puts more emphasis on the testing, rather than anything else.

Many of the arguments against it seem to centre around documentation and reporting. These may be good arguments IF your documents and reporting are delivering value in some form.

I should add that exploratory testing does involve documenting, it is just less heavyweight.

Critical questions as to whether your design documentation is of value are – does anyone else use it? Does anyone else read it in its full form? Does it get updated?

Critical questions around the result documentation are – does anyone read it? If they do, what actions do they take based on it? Do they need all of it?

It is possible that when you really drill down, summaries of testing are all that are needed and abbreviated reports. And good exploratory testing delivers that.

Leave a Reply

Your email address will not be published. Required fields are marked *

Exploratory Testing

31 Dec 2015

A rather vociferous debate kicked off on LinkedIn Test Discussions over the last week about the pros and cons of exploratory testing. Two camps developed, (1) the traditionalists wanting to stick to a strict design -> test -> report model and (2) the explorers who were happy to design, execute and record simultaneously.

Of course the best choice is going to be context specific. There may be very good reasons for staying traditional. It may be that you are legally bound to follow a certain way of working. It could be that you need to be absolutely sure that all scenarios are covered, in which case you probably need a heavier up-front design process.

But in many, possibly most, situations exploratory testing would seem to be the best option. It puts more emphasis on the testing, rather than anything else.

Many of the arguments against it seem to centre around documentation and reporting. These may be good arguments IF your documents and reporting are delivering value in some form.

I should add that exploratory testing does involve documenting, it is just less heavyweight.

Critical questions as to whether your design documentation is of value are – does anyone else use it? Does anyone else read it in its full form? Does it get updated?

Critical questions around the result documentation are – does anyone read it? If they do, what actions do they take based on it? Do they need all of it?

It is possible that when you really drill down, summaries of testing are all that are needed and abbreviated reports. And good exploratory testing delivers that.

Leave a Reply

Your email address will not be published. Required fields are marked *

READY TO GET STARTED

Complete the form below and we’ll be in touch to discuss how we can help