6 Tips For Leading A Test Strategy Retro

Phil Wells
Sep 5, 2018 · 8 min read

Writing tests, that’s my happy place. I’m most comfortable tapping away at my desk. Checking test case boxes. Turning coverage reports green. Public speaking makes me sweat through my shirt.

Alas! Test professionals need to be able to step up. We have to lead software teams into the light, warm embrace of positive testing culture. Sometimes we need to separate ourselves from the nuts and bolts work of testing and turn instead to a leadership role.

In this agile age, test professionals have a complex job. One duty is to make sure that everyone on the team is doing some of the work required to support a healthy test culture.

To improve the test culture, you’ll need a strategy. You’ll need to gauge the test culture’s current nature to define a strategy for improving tests with your team. One great tool for this is the Test Strategy Retrospective (or “retro” if you’re into the whole brevity thing.)

Put on your leadership boots, strap on your career development helmet, and darn those team-building socks. It’s time to retrospect.

The Test Strategy Retro

Before you continue on, learn what a Test Strategy Retro as defined by Katrina Clokie.

One of the best resources about this topic is Clokie’s the excellent book A Practical Guide to Testing in DevOps.

This article will lay out tips for leading the Test Strategy Retro as defined in Chapter 1 of that book. She’s also laid out the framework for this retro in a blog post here. Give it a look!

Read that definition. This article is about that definition. If you haven’t read that definition, now is the time to read that definition.

I’ll wait.

About My Team

I’ve had some success running this event with my own teammates, so here’s a description of my team. We are a growing team of web developers. The team’s members range in experience with testing from “lots of experience” to “almost no experience.”

Our Test Strategy Retro highlighted our team’s various experience and comfort levels with testing. We felt safe talking about these topics. We also felt confident that we’d be able to help each other out following our discussion.

1. Pick a sprint

In typical Scrum, a team will end a sprint with a retrospective. Teams use this event to isolate good and bad happenings during the sprint so that they might improve the way they work in the next sprint.

The Test Strategy Retro is not going to describe what happened during the previous sprint. Rather, it’ll encompass the testing culture of the team over the course of a lot of previous sprints.

It might benefit the team to line up the Test Strategy Retro to follow a sprint where a normal team retro wouldn’t bear as much fruit.

Find a Feature-Light Sprint

Teams often work through sprints where the release at the end of it isn’t a big blockbuster.

  • tech debt sprints
  • sprints spanning holidays or a lot of team members’ having time off
  • team offsite events

These things happen.

These kinds of sprints offer opportunities to schedule a retro that focuses on bigger-picture stuff. Luckily, test strategy is that kind of stuff!

2. Ask Engaging Questions

Your role at this retro is to direct traffic and gather evidence. You are not on trial. You do not need to validate your existence. You need to hear where your team is at with regards to testing its product for quality.

The Test Strategy Retro article (you did read the article, right?) provides great questions to guide the discussion part of the event. Ask them!

Don’t answer your own questions

Resist the urge to answer those guiding questions yourself. Providing what you believe the right answers to be will turn this whole thing into a seminar. Let your teammates talk about the state of testing on the team as it currently is. You’re helping yourself identify areas for improvement and clarification.

If it’s all about you, you’ll learn nothing new.

Don’t interrupt

You eat, breathe, and sweat test ideas all day every day. You will be able to articulate these ideas. Someone who has until now considered testing as a tangential part of their own job may struggle.

Let your teammates breathe. If someone needs time to put their ideas into words, give them that time by not talking while they do it. Encourage everyone else to give them that time as well.

There are no wrong answers.

This is a diagnostic process, not a trivia game. Members of your team don’t know what the team’s test processes are. Great! They have given you a valuable chunk of insight. Use misunderstandings and knowledge gaps to let you know what things you’ll need to clarify for the team after this event.

Answer process questions if they come up, but otherwise be a fly on the wall. Be Uatu, the Watcher.

3. Listen!

I’m flogging a dead horse here. The whole point of this exercise is to get the information out of your team’s minds and into the open. You are a sponge, soaking up the state of your team’s test culture in real-time. You will need to be a sensitive listener to pick up the signal and the noise.

Take notes

Don’t trust yourself to remember the details from this meeting. You may leave with the gist, the high-level idea of what fixes and communications you will need. But, you do yourself a disservice by neglecting to write down who said what. If some team members will need specific mentoring on specific topics, it’ll be evident when you look at your notes.

Restate what you have heard

A good way to make sure you’re understanding your team members to is repeat back what they have said (after they’re done, of course) in your own words. This is a good empathy move. It prevents crossed wires and helps you retain what they’ve said.

Ask for clarification

Don’t be afraid to ask someone to restate something that you didn’t understand the first time they said it. If it seems like there’s more to it, ask the speaker to explore part of their answer. This might get the group to a deeper discourse on the topic at hand.

4. Make remote participants feel welcome

Here’s a way to alienate remote users. Have them dial into a meeting. Then have them watch your team arrange their thoughts about work and how things are going using sticky notes. Put the sticky notes on a whiteboard that they can’t even see.

We expect the same level of professionalism and quality from our remote peers as we do from our on-site ones; we should extend the same back to them.

Provide a virtual whiteboard

One way to include remote participants is to use a virtual whiteboard and sticky notes. Have everyone, including people in the room, work on the virtual board from their laptops. This puts everyone on even ground. I’ve used Google Draw with little colored boxes for sticky notes and it worked fine.

Ask remote folks if they have questions or comments

Keep online teammates engaged by asking if they have some input at regular intervals. Particularly take care to do this before moving onto another topic, or asking another beefy, loaded question. It’s easy for a group discussion to box out remote voices. Make sure everyone gets heard.

5. Prepare as if for an interview

This event is not meant to find flaws with the work you, personally, are doing. Same for the test professionals on your team. Still, as the test professional leading this exercise, team members will call on you to answer some questions about how testing works on the team. You deal with testing every day. Still, make sure to take some time to review the processes and testing roles used by your team. If you’re caught without an answer the whole discussion could get stuck.

Answer questions about test terminology

Not everyone in software development knows what a smoke test is. For that matter, some people in test don’t know what a smoke test is! Teammates may ask you to define test vocabulary for them. You might also have to point out cases where the team has been using several terms for the same concept. Words matter! It’s important that the whole team agree on terms for what goes on within that team. Less important is whether the team is collectively using the “correct” industry terms.

Provide examples

Go through a software testing glossary before the meeting. Think of examples from your own team about each of the practices listed. People will grok test concepts much faster if they can relate them to something they’ve been doing as part of their own work.

6. Follow Up

Your Test Strategy Retro will shine a light on what your team is doing well and where there are opportunities for improvement when it comes to tests.

Now that the meeting is over, capitalize on your findings by following up.

Test Strategy Document

If your team has a Test Strategy Document published somewhere, use the findings from the retro to patch some holes and make some updates. It should reflect what you current best practices for testing are. It should not describe where things currently stand, It also should not state where the team hopes they’ll be in the future. This is an instructional document, not an aspirational one.

Survey

Ask your team how it went. You can send out an anonymous survey via email. Or, ask folks face-to-face, depending on your team’s culture. Don’t exclude remote folks from this step!

Schedule The Next One

You wouldn’t want to have a retro like this every sprint. Still, setting up a long-term follow-up retro could be helpful in measuring how far you’ve come. I plan on running these workshops once a year with my own teammates.

Conclusion

It’s easy to think of leadership as part of someone else’s job title. “I’ll need leadership if I ever manage a team,” you might say. But, like anyone on your team can improve the culture of quality and tests, so anyone on your team can take on some tasks that require a little leadership. You know more about software testing than a lot of people on your own team. Use that valuable knowledge to lead the team to a place of better understanding and, in the end, higher quality. The power is in you, even if you have to pry yourself away from the day-to-day work to flex it!

Let me know if you’ve run one of these Test Strategy Retros with your team, or if you plan to. Tweet at me!


Originally published at www.thephilwells.com on September 5, 2018.

Phil Wells

Written by

Father. Author of Dudesong. QA drone.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade