Obviously! – But often where we fail to do this as testing professionals. We get caught up in terminology discussions, application of standards and obligations and who gets to do the work – that we forget to align with the business side of things. And thus the beatings continue until morale improves – if you don’t align you test strategy to the business*.
The business side can be hard to read. Also coming from the back story that testers long for objectivity – and “just” want to state the facts for the decision makers. I know, I’ve fallen into that trap many times.
We need to be able to read the business strategy and prepare the test strategy accordingly... and business decisions first.
How to Read the Business
Recently I was at the 99-minutes workshop on: Leading a Test Automation Strategy on the Ministry of Testing. (If you’re interested, it’s being rescheduled – but requires a paid MoT membership). In the workshop I was reminded that a strategy is the path towards a goal or vision.
Wardley maps allow the representation of visibility of value on one side and evolution of components on the other side. These elements allow the relative positioning of elements, like on a real map – and allows you to discuss and project changes and paths in the landscape of the business.
How to use Wardley Mapping to understand how you deliver customer valuehttps://medium.com/dan-stories/how-to-use-wardley-mapping-to-understand-how-you-deliver-customer-value-43abdad264cf
Wardley mapping have been used for the following, to name a few:
- Business technology decisions
- Microservices: Preparing for a future Microservices journey using DDD & Wardley Maps
- Security: Using Wardley mapping for Security Strategy and Architecture development by Mario Platt
- Team topologies (Stream aligned, Enablement, Platform…)
- Maturity Mapping: Using Wardley Maps and Cynefin to create context specific maturity models,” Lean Agile Scotland 2019
Preparing a Test Strategy
To me there’s more to a test strategy than the model of testing, and there is more to a test strategy than to pick test charters, test coverage strategy, test automation strategy and the visualization of pipelines. .. it’s a path towards a business goal.
Previously I have looked into how Wardley maps can be applied for preparing test strategies: Visualize the Test Strategy, Making a Map of Risks, Broaden the scope of the SUT – let’s look at how we can align the business and test strategy in one map.
We can easily arrange our vertical dimension to be the visibility to the decision maker – not the user as in the default Wardley map. Using the decision maker as anchor on the map, we can now position elements relative to the value for the decision maker and use that to explore the context of the system under test. The decision maker is mostly interested in things that drives the business, secondly perhaps what kind project or delivery it is – and only after that is the testing activity relevant to consider.
Readers of the DevOps handbook will recognize the core chronic conflict of pursuing both: responding the rapidly changing competitive landscape and providing stable, reliable and secure services (introduction xxv).
With the above Wardley map – and perhaps a bit more context and data about the specific situation – I can see and start a discussion on how the test strategy aligns with the business strategy and business map.
(*: Headline from Keith Klain: the beatings continue until morale improves)