Courage in Exploratory Testing

Exploratory Testing takes software testing skill. It also requires the tester be courageous. Let me explain.

Exploratory testing is an approach, not a technique. Exploratory Testing is simultaneous learning, design and execution. What information we learn about a product, helps dictate our tests providing us with information that we can share with people around us.

Exploratory Testing is tester centric, meaning the tester is central to the testing taking place. The tester has the autonomy and the responsibility to make decisions about what to test, how to test, how much to test and when to stop. This may seem blatantly obvious to some, but its surprising the number of test teams where this is not the case.

Its all powerful stuff, generating an environment where the tester must constantly reflect upon the changing project and product environments, enabling the tester to be engaged and mindful as they test.

I honestly can’t think of a better approach to software testing.

But there is a catch. Exploratory Testing also demands great courage.

When you start to take responsibility for your testing it’s not done in isolation. Testing requires interaction with many different people such as developers, project managers, scrum masters, product owners, customer support and business people. We share information that’s not always good news. Its in the form of bugs found and the possible impact of this information on business. The resulting consequences of the information we share often leads to delays in releasing, changes in work load, context switching and revising strategies.

In scripted testing, testers have artifacts which they measure and count giving an illusion of of certainty but really this is smoke and mirror reporting and generally offers little genuine information. “We have reached 78% test coverage, with a DDR of 85%”

Exploratory Testing doesn’t have ‘dutch courage’ to rely on. It requires us to have conversations about our information in potentially hostile environments. Sometimes we can feel like the lone fish swimming against the tide of the silent majority. It can be tough and as testers we need to learn to develop how to speak about our testing, how to tell a story (James Bach and Michael Bolton have both written on this). courage in Exploratory Testing

Here’s a list of ways that have helped a quaking knock kneed tester like myself discover her backbone:

Speak to someone you trust about your concern. Vocalisng a fear helps to make it tangible and sometimes gives strength when you discover its a shared concern.

Be coached or mentored on how to speak about testing with confidence

Take small steps. Speak to people sympathetic to your cause, sound out ideas. See if other people can help.

Try not to lose faith, be persistent. Keep your eyes on the goal, even if sometimes you fail to speak out.

Emotions are your toolbox. Anger and frustration can be very useful emotions! Use your emotion to give you courage to speak out. (I learned that at PSL this year..thanks to Jerry, Johanna & Esther)

Sometimes you need help. Be humble enough to know that sometimes change is out of your capabilities. See if you can find help through the testing community or see if you can bring someone in to help affect the change.

But mostly, its about practice. Courage breeds courage. Standing up to little things helps give you courage to stand up to greater things in the future. Be brave. Be strong.

What drives me most of all is that I want to be able to walk away from a situation with my head held high in the knowledge that I may not have changed the world, but I’ve had my say.

Now that’s a good days work.

 

 

 

 

5 Comments

  1. We generally collaborate with project sponsers to decide what to test, when to test and when to stop testing since they are paying for it. I’m not sure placing all of that responsibility on the tester is a good idea.

    Anne-Marie: In Exploratory Testing, the tester is responsible for making sure they understand the project sponsor.

    Also, it doesn’t sound like you’ve had a lot of experience in ‘scripted testing’. Test design, test execution, and test reporting are seperate activities. You judge ‘scripting’ because of ineffective reporting of metrics.

    Anne-Marie: I have a degree in Electrical Engineering, with twelve years experience in testing under IEE829 in a scripted environment.

    I’m not really sure what value lies in comparing a technique to a methodology as you have done.

    Anne-Marie: Its not a technique, its an approach.

    If by ‘scripted’ you mean following a set approach without taking into consideration changes in your environment, then that makes sense. But you can work with test scripts and use them in an exploratory nature. Do not confuse the two.

    Anne-Marie: Yes, of course you can. Most experienced testers don’t follow a prescribed test to the step. It doesn’t make sense.

    I’m not confused at all. I’ve studied both approaches in detail.

    Reply

  2. Thanks AMC.

    @John – “We generally collaborate with project sponsers to decide what to test, when to test and when to stop testing since they are paying for it.”

    I’m wondering what type of information you’re providing the sponsors to help them decide, specifically about stopping? Can you share some examples?

    I’m also interested in this one…

    “Test design, test execution, and test reporting are seperate activities.”

    Have you never combined these? So, perhaps having a developer at your desk and undertaking some paired testing which wasn’t previously scripted?

    @AMC – This is key in our line of work. You need to have courage in testing at the best of times, but when trying to introduce a ‘new’ approach you need it ten fold! Having credible information to back your story will only assist in gathering the courage required to tackle the sticky situations. So I think your testing story and reporting are key.

    Anne-Marie: Yeah, thats a valid point David.

    Reply

  3. The statement “Exploratory testing is an approach, not a technique” really intrigued me. I’ve always thought that within ET you can apply various techniques to enhance the change of finding quality deviations. But to say that ET itself is not a technique is interesting statement.

    Nice article though..

    Reply

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>