Skip navigation.

Exploratory testing

Could a novice tester do Exploratory Testing?

exploratory testing
I think that the question is wrong itself. The question is what a novice „should”. I do believe that for most of the novices this is not the best way to learn testing art/skills, but it depends on a person. However! To learn testing by following scripts (I mean detailed instructions for manual testing) written by others is even worse, much worse!

ET thoughts: The Seeker (CKA) heuristic

exploratory testing | heuristics

Some people are more into mnemonics than others. I can recall walking along with James Lyndsay one day. This in itself was unusual because we are normally on opposite sides of the earth. We were discussing how there are many great mnemonics for test ideas, but neither of us was able to recall the items, just the mnemonics! I think this strongly influences our exploratory testing approaches. Alan Richardson has blogged about this here . Because it is general, It doesn’t really need a mnemonic, but I will give it an acronym. Seeker, CKA, Challenge Key Assumptions. While any tester can do this, the experienced tester will be more skilled at identifying key assumptions, and be more effective at using it. If you have less experience, or can remember mnemonics (!), maybe try the standard ones! You’ll find some links by searching for “test ideas” at my testingspot.net site

Discovery vs. Confirmation

exploratory testing | perspectives | test driven development

When I hear debates about scripted vs. exploratory testing... or even debates such as "automate all tests" vs. "you can't automate all tests"... I don't think I'm hearing the real debate.

I think the debate that I'm hearing is "testing is about confirmation" vs. "testing is about discovery".

This distinction in the underlying intent of a given approach seems to not be emphasised in these discussions.

In simple terms, I think of the intent behind testing as having two facets:

  • Confirmation - Does the system do what we anticipated it should do?
  • Discovery - Does the system do (or not do) anything we did not anticipate it would (or should do)?

Ad-hoc vs. Exploratory Testing

exploratory testing
In various discussions I've been having lately I've tried to help people distinguish between ad-hoc testing (or as some people say - having a play) and exploratory testing...

Ad-hoc testing in comparison to exploratory testing is like the difference between someone who only runs when they are late for their train and a professional athlete that competes in 100 metre sprints.

The person that runs for the bus simply runs instinctively - yet the professional athlete, with the sports-science consultant, studies ways to optimise their running, trains and practices to improve both their power and technique (such as with the Pose method).

The minute you even read about exploratory testing, you are stepping away from ad-hoc (having a play) testing. The mere fact that you appreciate that it isn't only instinctive but realise that there is a method to what may at a glance seem easy to do is the day you are no longer just "having a play".

Do you keep notes about “the first below the line” tests?

exploratory testing
We can’t test everything. So it would be logical to divide tests into must and may (if time permit)” test. To have some tests reserved... Nevertheless, in continuous integration projects I have “it’s now or never” rule as testing new features. I may postpone whole feature testing, but specific test ideas – never. I’m not sure if I’m right – that’s why I’m writing this.

How do I know when I'm done... (again)

exploratory testing | extreme programming (XP)
In the context of an XP-style Story/Acceptance Test Driven Development process, that uses exploratory testing to generation intra-iteration feedback... The question “how do we know we are done” is often asked and I'm not sure I always give or get the best answer. One of the problems is that there is so much context... so, here's one way you might know (based on my better experiences)...

That sweet check-in...

ET thoughts: Prediction and the all players all-in poker bug

ethics | exploratory testing | perspectives
One of the key aspects of exploratory testing is Prediction. By background research (specialist knowledge, interviewing others or looking at specifications, etc) or by observing software, we understand the models involved and can predict other behavior based on a model or model interactions. While some of this involves predicting positive behaviors, a skilled exploratory tester is often able to leverage failure models to find bugs. Once a bug is found, further investigation may lead to other variations of the bug often with a higher impact.

Test Case Review

exploratory testing
For years I was wondering why we disagree with people about exploratory testing. Recently (working close with them) I’ve realized part of their thinking: To review test case you have to document it. You have to document it in advance to test execution; otherwise you will run unapproved test cases. You can’t review test cases in exploratory testing because there are no test cases written in advance to test execution.