What gets in the way of creating a unified testing strategy across your organisation?

MoT Content Discussions
1

Check out @gina.chelton’s and my article “One team, one goal: The reality of introducing a unified testing strategy.”

In a large business, keeping alignment within a discipline can be a challenge in itself. Shifting business objectives, serving different user bases, and reckoning with software constraints can lead to drastic divergence in terms of strategy and day to day tasks for the test engineers involved. This can cause greater issues down the line, as well as disjointing the community.

Getting a testing community together to build a unified strategy and then rolling it out across a large business with multiple disciplines and products is also an arduous task, but one we feel was worthwhile to undertake. We’re sharing our story, successes and learnings, in the hopes it can inspire others or at least provide ideas to have the same transformation in your workplace.

What You’ll Learn:

  • How to roll out a new testing strategy across a business at scale
  • Some challenges you might encounter along the way, and how to meet them
  • Tips and tricks for getting stakeholders on board with the new strategy

After reading, share your thoughts:

  • Have you experienced any similar challenges in your workplace? How did you tackle them?
  • Do you have a unified testing strategy across your business? Is there anything you would’ve done differently were you to repeat the same process?
5 Likes
2

A challenging goal, in smaller teams where the testers are likeminded this is often easier but in larger groups where there is a large diversification of thinking around testing its a harder change.

The article is good and detailed but a couple of things stood out for me, as a testing strategy it did not really talk about the core values of testing, product risks, discovery, learning, experimentation or really the goals of testing.

@risenashes Would it be fair to say this was closer to an automation testing strategy rather than a testing strategy as a whole, the use of the automated pyramid tends to back that focus.

By narrowing it down a bit this can likely increase the chances of common agreement and may be a good strategy.

If it was a testing strategy you might find the strong advocates of the model have drowned out those who wanted a broad testing strategy that began with the goals of testing and the values it adds. They will likely just go with the flow but quietly make exit plans.

I’ve seen strategies where developers own all the automation including UI level, there are very strong arguments for this and those testers who favour a learning and discovery model of testing will also back this model. How would you feel if that was the strategy pushed, would it get your buy in?

I’ve at times found some bullet point principles easier to get alignment, they are flexible enough to adapt to the different teams, products, skills sets etc.

We are moving to a very holistic view of quality and testing, some are already there and others buy in in principle but not all projects suit. The breadth of it though does allow for those fundamental differing views on the value of testing and allows teams to optimise within it and around the principles. We do tend to get healthy disagreements on things, lots of individual bias’s and preferences there.

Anyway really good points in the article in general, goals and buy in from key stakeholders is key but be wary that some voices may not be heard.

3 Likes
3

Interesting points!

Yes, it would be fair to say that this strategy is focused on automation. That doesn’t mean that the more general aspects aren’t considered, but they are treated as more of a given and accepted thing amongst our testing community that don’t need to be given an explicit strategy document. The automation approach was always a lot more nebulous, open to interpretation and vulnerable to differences of opinion that didn’t really exist in terms the core responsibilities of a tester. We’ve already been over the journey of the goals of testing and the value of testing over the years and the business as a whole is aligned and bought in - that’s a done deal.

We’re quite against the idea of developers owning all the automation. Other than giving the developers more to do on their already rather full plates, they tend to have different priorities, considerations and perspectives to a tester. This is why we prefer a collaborative approach with shared ownership of automation across much of the pyramid. Admittedly, this is only possible because we only have test engineers as a business. Every tester is able and expected to do development and assist in automation, there are no exclusively manual testers. Of course, we’ll still have individual biases and disagreements but we just talk through them in our community catch ups and try to reach a compromise that most or all can accept.

I wholeheartedly agree that principles/guidance/flow charts are far more useful than hard, strict rules. The latter doesn’t allow for the required amount of freedom for teams to operate the way that works for them, both as people and with their different tech stacks. Hard, strict rules begin a slippery slope that ends in calling yourselves agile but not really operating as such.

3 Likes