How do you sell testing into a project team?

🙋 Questions
, , , ,
1

@cakehurstryan ran a brilliant Masterclass Webinar. Thanks, Callum! :raised_hands:t2:

Selling Testing Into Project Teams: A Guide to Convincing Teams To Test

If you missed it then the recording will be available soon enough to all Ministry of Testing Pro Members. You’ll get access to that plus the entire catalogue of Masterclass Webinar recordings.

I like how Callum didn’t just say “You just have to tell people the benefits of testing!” It was more about demonstrating the value of testing through practical pairing sessions. More about advocating and inspiring non-testers to get involved.

I also liked how Callum shared that testing is about finding information, not finding bugs. And posed the question, “how do you ensure the testing information you share is useful?”

Defo one to watch/rewatch when the recording goes live. Will ping here when that happens.

The following questions were answered:

  1. As the person who becomes confident selling testing, how do you manage not becoming the only person people go to? — Simon Tomes
  2. Do you think “good enough” should be defined in a test plan? – Tammy M
  3. Do you ever show people the “Motivators for Change” diagram? — Simon Tomes
  4. Can you elaborate a little more on pairing with the dev when it comes to testing? What would be your approach? – Tammy M
  5. If the organisation ask us to be pragmatic but still they need us to think outside the box as a tester. Do we need to define the way of testing anywhere to feel satisfied as a tester? — Srimaye Nallamsetty
  6. What about where QA/testers are expected to stay in their lane or considered still under Devs? — Luke LR

We didn’t get to the following:

  1. How do you build trust with someone who has had bad experiences with previous testers? How direct can you be about their historical bias? — Simon Tomes
  2. What if you do not have the product to test but you want to do exploratory testing? Any suggestion? — Tammy M

How about you, what’s been your approach to “selling” testing?

4 Likes
2

We should analyse what a bad experience with previous testers could mean:

  • They didn’t listen to the team.
  • They didn’t provide useful feedback in a timely manner.
  • They set themselves up as “vs. dev” or as antagonist.
  • They weren’t being pragmatic and were testing to win (or for their own ego).

Teams need to know what we’re doing in order to have trust in us, we have to set out a plan for how we engage with, listen and feed back to the team. By setting out our stall, the team knows what they can hold us to account for and what to expect from us (then we have to follow through to not break that trust).

Show your pragmatism and that you’re a trusted advisor by discussing what good enough means for now and testing to meet that. If you find information that’s beyond good enough for now, address it as “this could be aspirational but we don’t need it now”. That’ll show you’ve listened to the team and are working with them.

Run a charm offensive with Charisma Testing to show you will highlight the good and not just the bad. Dan Ashby spoke about making a dev a cup of tea so they’ll owe you one, you can get the same goodwill by highlighting how awesome someone’s work is and vocalising it to others.

Sometimes teams lose faith in testers because of a lack of practicality and technicality. Show you’re a force to be trusted by backing up your words with good testing, share the outcomes of that and let the team know you’re awesome too. Push yourself to be really useful in the team by engaging in technical discussions, being vocal early to ensure we’re building the right thing and testing throughout the stack. Also, be up front if there’s an areas you don’t know about and ask for help (or to pair) to learn from the team.

1 Like
3

Exploratory testing is an approach we use to uncover the unknown by identifying risks, questioning them and gathering information. It’s not limited to just a full product or an end to end process, you can explore to uncover information about anything.

  • User stories and requirements - Test those by raising risks and asking questions about what’s needed (here’s a video about that and here’s a blog post about Triforce / 3amigos testing).
  • Risk storm against designs and requirements to gather information about what could go wrong!
  • Push exploration into services, APIs and code by analysing them for risk and experimenting to see what happens related to that risk.
  • Talk to developers in meetings and chats to ask what’s going on and explore ideas with what they’re building.

Here’s a blog post I’ve written about pushing your exploration early.

This does mean getting more involved with design, code and requirements analysis, so make sure to take small steps and woth with your team to help you to understand things.

1 Like
4

For folks who missed this most excellent Masterclass, check out the recording.

1 Like
5

Going to watch this when I get some free time, i promise i will. Been so time pressed lately with all kinds of pain at work, but one point stands out for me Bad tester experience because tester did not provide useful feedback in a timely manner . And have been taking that to heart this quarter, when under pressure it’s easy to tell the devs “I’ll test that when I get the chance later”, later is too late, eat that frog and find the big expensive defects as early as possible.

6

What I use:

Fooood :cake: . Everyone has to eat and most people like cake, so I sometimes bake something and bring it to work. The fact that they like you as a person is step 1 to being liked as a tester.

I work as a consultant so I often switch projects, so when you want to get things done, and the people are a bit stubborn. You can come up with new ideas BUT you cannot express it. That’s the whole part of change management, you have to feed someone else the idea so “they come up” with it saying like “But what if you/we do do X or Y?” and then you can make suggestions saying like “Yea we can also add Z onto ‘YOUR’ idea to make it even better, well done, nice suggestion!”

Works 95% of the time. They feel great because they came up with a new idea, you feel great because your idea gets implemented (often a struggle as an external employee). It only doesn’t really work because of the lack of knowledge, like if they have no clue at all.
If then they don’t listen to you, you have to become friends first with cake and ease it in.

1 Like