Navigation Layout: Stacked Header Style: Light

Create a Team Test Automation Strategy

You don't have to be an expert in test automation to facilitate a team test automation strategy. Here's a fun workshop you can run with any team.

Create a Team Test Automation Strategy
Photo by anthony mcgee / Unsplash

You don't have to be an expert in test automation to help facilitate a team test automation strategy. Using common test automation patterns combined with an ethos of experimentation, you can encourage a team to define an approach that works in their context.

Discussing test automation is a natural place for any quality coach to start when working with a new team. Many software engineers naturally gravitate to test automation. If you want to find common ground, this will likely be it.

The following workshop is designed for a quality coach to facilitate a test automation strategy the team can begin to adopt and own.

Test Automation Workshop

Workshop Duration: 90 minutes
Intended Participants: The whole Product Team
Format: Online

1) Explain the purpose and value of a test automation model. Explain that many models exist and that models have evolved over the years. This is because context matters. Explain the workshop's purpose: to create a team version of a test automation model. We will discover our shape!
Recommended Timebox: 5 minutes

2) Begin the workshop by discussing the four common considerations of a test automation model: speed of tests, reliability of the test, cost of the test, and purpose. Ask the team to rank their top four criteria.
Recommended Timebox: 10 minutes

3) Ask the team to list the test automation types they currently perform. Stress that this is not the one they think they ought to have but the one they do. They can list as many as they like. Suggest they include manual or exploratory testing in the mix if it's performed.
Recommended Timebox: 10 minutes

4) Reminding the team to think about current practice, not aspirational, ask the team to rank the testing type according to purpose, reliability, cost, and speed. If they get stuck, point them to the original prioritisation.
Recommended Timebox: 20 minutes

💡
If the team has many test automation types you may need more time. Consider breaking the workshop up into two sections to allow time for this discussion as it's important


5) With current practice in mind, ask the team to evaluate the effort a testing type takes by comparing it against the other testing types. They can do this on the template by lengthening or shortening the horizontal lines. Outline the shape. Is it a recognisable object?
Recommended Timebox: 15 minutes

6) Close off the workshop with a discussion and next steps. How do people feel about the existing shape? Show them examples of other test automation models. Is there a model they aspire to? Where are the gaps? What do they want to prioritise? Use the questions in the template as prompts for discussion. Agree on the next steps and when you will reconnect.
Recommended Timebox: 20+ minutes

And that's it! The following section describes some tips and tricks you may find helpful.

💡Tips and Tricks

The following are some tips and tricks I've picked up over the years.

Tackling Imposter Syndrome

The team may ask you questions outside your sphere of knowledge or experience. Rather than fearing this, use the opportunity to learn more about test automation. You might not be the technical guru you feel you need to be, but you know more about software testing than most. No one can be an expert on everything.

Be open about your current knowledge. Let them know you will find out and get back to them. Make a point of following up; it builds trust. Offer to pair and learn together.

Ground the discussion

The workshop aims to describe current practices, not aspirational ones. Ground the workshop by asking for examples. If there is no example, it's likely to be aspirational. Put the concept/idea into the parking lot and refocus the session on the original question.

Software Testing and Test Automation

While you may view software testing as a risk mitigation exercise, the team may not see it that way. They may view test automation as reducing test execution time and increasing confidence in the build. How you address this difference is down to personal choice. I prefer to take teams on a journey of self-discovery. In time, they will begin to understand the many nuances of test automation. You may like to address this difference head-on. Tailor the workshop to your preferred style. I provided some options if you want to go deeper with the team.

Test Coverage

In my experience, many software teams attempt to automate everything. At some point, you could do a second workshop on risk and test automation that helps use risk to be selective on test automation. Sam Connolley does a great workshop on this.

Tooling

No matter how hard you try, the conversation will rapidly shift to tooling. Have a parking lot to collate their thoughts and concerns. These will be super useful later, but right now, you want to focus on

Pressure of delivery

Teams working under intense pressure may not feel they have the luxury of thought and may pressure you to "tell them what to do." Most people under stress have little capacity to take on new things. Give them small experiments, using their retrospectives to reflect on their learning. Kata's may be a helpful approach.

Keep it simple

Some test automation models are criticised in the software testing community as too simplistic and not reflective of good testing practices. These are valid criticisms. No model is perfect, but that doesn't mean they are not helpful, especially as a starting point. Nuance comes once there's a solid grounding of experience.

The fine line of coaching

As a quality coach, your role is to balance helping the team see what good looks like with enabling them to have agency over their test automation strategy. This can be a fine line to negotiate. Too much direction and the team loses agency and decision-making; it becomes your test strategy, not theirs. Too little direction will cause the team to struggle to assemble a meaningful plan.

Coaching is a skill, and I often struggle to strike the right balance. Be kind to yourself. You are learning, too.

Test Automation Model References

Testing Pyramid: An Evolutionary Tale
Change is ubiquitous in software development. New languages and frameworks are invented, old ones toppled. The one thing unwilling to move is Testing Pyramid.
The Testing Trophy and Testing Classifications
How to interpret the testing trophy for optimal clarity
Using the Testing Trophy Heuristic
The Testing Trophy is a heuristic for making choices about test automation. Read ahead for answers about how and where to test your…
The Practical Test Pyramid
Find out what kinds of automated tests you should implement for your application and learn by examples what these tests could look like.
Testing Pyramids & Ice-Cream Cones
Just Say No to More End-to-End Tests
by Mike Wacker At some point in your life, you can probably recall a movie that you and your friends all wanted to see, and that you and y…
Your automation testing strategy: pyramids, triangles and beyond
If your team struggles with automation testing, don’t feel alone. This post is about figuring out where to start and establishing a solid base you can build on.

Test Automation Strategy Template by Anne-Marie Charrett is licensed under Creative Commons Attribution-ShareAlike 4.0 International

Thanks Irja Straus for feedback on this workshop.