How can we help developers understand the value of exploratory testing?

🗄️ Archive
1

We all have different ways to working together, at the minute lots of us are working from home and maybe re-evaluate how we do work together as a team - how we can communicate value, have you gained some new insights or things you’re going to try?

Let’s talk about helping devs understand the value of exploratory testing. We asked on twitter and Linkedin and got some great replies:

Pair with them

Make them responsible for all of their own testing.

Pairing & mob testing are great tools for this. While doing this, I like to go slow and explain why I’m exploring a certain part of the product so they can (hopefully) pick up on my thinking and begin to use those ideas to test on their own.

Just do it and file your bug reports with a note “Discovered during an exploratory testing session” or have a label for this.
If you find nothing, send a message to say you are now confident about the feature or this part of the product tested!
Make it visible!

In my experience: just teach it to them. Most developers actually like it and when you show them how they can integrate it into their daily work, they do it.

Why just developers? I think it applies to all (testers included).
Exploratory testing provides valuable exposure without following an ac to the letter or in times when you are in a more agile sprint it shows its real merit. Throughout my career exploratory testing has exposed issues that would have been missed if the ac’s were followed / exposed late in the sprint by which point it blocks the sprint / delays it’s delivery. Exploratory testing should be adopted by more as a positive not a negative and could be considered the first stage whilst awaiting the completed sprint being delivered into test.

Developers aren’t stupid, and it’s not a difficult concept to grasp. If they’re not buying it, I doubt it’s because of a lack of understanding.

  • Maybe they don’t care because it’s “not their job” and they’ve got enough on their plate as it is.
  • Maybe there’s a strong testers-as-gatekeepers culture, making it seem like you’re moving the goalpost when you test things that weren’t asked for.
  • Maybe the testers are in the habit of winking and smiling rather than showing their work.
  • Maybe there’s an antagonistic relationship between developers and testers (due to dysfunctional KPI’s, for example).

Users are not always logical or use software as intended. Exploring helps to identify those scenarios that haven’t been coded for or specified in the ac. No one really knows how software works until it is used. Test ideas lead to new ideas.

What can you add? It is something you’re thinking about? Is there an aspect you’ve not considered before?

2

The scale of exploration when doing testing can vary a lot. (https://www.developsense.com/blog/2014/07/sock-puppets-of-formal-testing/)
The testing skills of the testers vary a lot. The exploration skills vary a lot.
The understanding of the exploratory scale by the testers can vary a lot.
The environment/context for those testers and devs can vary a lot.
Developers can have a varying understanding of the exploratory testing.

Generally to help them, yourself, the product, the stakeholders…you have to excel at things, and impress them.
With some you make that impression in a few weeks. With others it takes months.

3

Since all testing is exploratory, you can reverse engineer their testing thinking process and show it’s already an exploratory activity.

1 Like
4

I’m wondering if we can help with visual models? I’ve seen some good ones on the Dojo. What visuals can we use to start up conversations with devs about why they should learn and do exploratory testing?

5

The best success I’ve seen with devs learning ET skills was when the development managers added levels of ET competencies to the skill matrix for their own career advancement. That gave them permission to take time to learn, that made them eager to pair with us and participate in workshops. Once they got traction in it, they saw the value.

6

Step one, understand developers!

  1. If you read James Bach’s “Test Cases Are Not Testing”, he makes a case for many folks (management and devs) thinking that test cases are like code. A step by step resource to know how to test something.
  2. I talked with a couple of lead developers. When developers get a User Story, they cannot decide which part or how much to do. There is no “smoke coding”.

So deciding what to test, and how, and how much… This sounds weird. This sounds very hippy “can’t possibly be ‘real’”.

Next is demonstrating what exploratory testing can do. It’s all about credibility.

  • Find bugs! Identify risks!
  • Test “deep” - philosophical problems aren’t found by clicking randomly (usually)
  • Risk base your exploration - “Wow, I didn’t think of that” really sells exploration
  • Find critical problems even if they say “you don’t need to look there”
  • PMs have confided that they doubted the worth of testing “everything” but noticed when they let us, we found bugs in things they were sure were fine - and that convinced them