I am getting tired of fellow software testers telling, stating, writing that exploratory testers do not like structured testing, or that exploratory testing is the opposite of structured testing, or that exploratory testing can only be done based on experience or domain knowledge, and on and on….

Exploratory testing is, like ‘traditional testing’, not also based on risk analysis, requirements, quality attributes and test design techniques. It does not ignore or oppose these approaches. Exploratory testing just also reaches beyond that and is also based on modeling, using oracles, using heuristics, time management, providing stakeholder relevant information, and much more.

Exploratory testing doesn’t spent unnecessary time on writing specific stepwise test cases in advance. It rather works with test ideas which it critically investigates while keeping an open mind on what is observed during execution. Exploratory testing then uses the information to create new and additional test ideas, change direction or raise bugs. But it always aims to use the results to provide relevant information to stakeholders that enables them to take decisions or meet their targets. And that can be a verbal account or a brief note but is more likely to be stakeholder specific test execution accounts, showing test results related to achieving the stakeholders acceptance criteria, (business) goals and mission It accounts how much is done, could not be done and how much still should/needs to be done both in terms of progress and coverage.

Exploratory testing is no free pass to click around in the software. Exploratory testing is both highly structured and flexible and it is flexible enough to change along the way so it can provide the most value information possible to the stakeholders.

So…

Exploratory Testing is not the antithesis of structured testing

To do exploratory testing well you have to work structured, disciplined and flexible at the same time. That’s what makes exploratory testing hard to do but lots of fun at the same time.

You don’t just have to take my word for it. Many have written about it before, see some examples below, but the best way to get convinced is to learn and experience it. So I challenge you to go out and do it seriously and with engagement. If you don’t know how many colleagues or myself are more than happy to show you.

http://www.satisfice.com/articles/what_is_et.shtml
http://www.kaner.com/pdfs/QAIExploring.pdf
http://university.utest.com/exploratory-testing-the-basics/
http://www.developsense.com/blog/category/exploratory-testing/?submit=Search
http://www.slideshare.net/codecentric/exploratory-testing-inagileoverviewmeettheexpertselisabethhendrickson
http://lets-test.com/?p=2335

Best book:
https://pragprog.com/book/ehxta/explore-it

And just to prevent wrong ideas.
Test ideas can, depending on context, be more or less detailed and almost look like scripts even while their execution is not.
Also testers that prefer exploratory testing can use checklists or scripts if that better serves the need for information for the stakeholders. Although I think information transfer is better served by putting relevant detail in the reports and not in the test cases.

5 thoughts on “Exploratory Testing is not the antithesis of structured testing”

Thanks for an interesting post, But I feel you took it too far to the opposite direction –
While I agree with “Exploratory testing just also reaches beyond that”, I think the following examples are wrong as they serve also in scripted testing:
“and is also based on modeling, using oracles, using heuristics, time management, providing stakeholder relevant information, and much more.”

Now spending time on writing steps – is not always unnecessary – But in many cases writing steps for a sample of test cases allows you & the reviewers to get insights you would have not seen without it. (So 1 elaborated TC out of a family may be very helpful.

If ET test ideas are written in advance – they may serve as review to Requirements, if not – our feedback may be a bit later than it can be.

So ET is more about learning new test ideas as we test, rather than not documenting,
And we need to find the right amount of documentation (or as less as possible but) which will still raise issues as early as possible Before we even develop the SW.

@halperinko – Kobi Halperin

LikeLike

Arborosa

January 4, 2015 at 4:44 pm

Hi Kobi,

Thanks for the reaction.

I agree that models, oracles, etc. can and are used in scripted testing. In my experience however many that hold a narrow view on Exploratory Testing (ET) also often have a limited view on scripted testing and overlook these sources of test ideas and stick to what they now or readily have available.

I did not say testers that do ET do not spent time on writing test cases. I rather like to think that they do not spent unnecessary time on them. Meaning that occasionally writing test cases (including test steps) can serve a purpose. For example I regularly use one or two to describe new software or new functionality so that the missing information or unfamiliarity does not over influence the observation you intended to do with the test.

I think ET is about engaging with the software, about gathering information concerning the software and about learning how to test the software in different ways. You do that based on what you yourself have experienced and others do that based on the information that you have shared. In this I view software in the broadest sense from early design ideas to fully deployed software in production. So if documents are available then that would also include reviewing and creating test ideas based on those.

Regards,
Jean-Paul

LikeLike

Reply