A strategy is a general plan to achieve something. Achieving a goal does not always require a strategy, but it is helpful, especially 1) if there is a target date you want to meet, 2) if the resources to achieve it are limited, or 3) under conditions of uncertainty. More often than not, at least one of these applies, and so we have learned to appreciate having a strategy, at work as well as in at least some of our private matters.
But have you noticed that, where Automation in Testing (AiT) is concerned, what is called ‘strategy’ does not usually result in automation being perceived as successful? Quite likely, especially if you have been in IT for as long as I have. This not only applies to the business but also in development teams. Why is that?
Part of the reason is often the goal that is selected. Why would anyone expect automation to generate real and recognisable business value unless the goal directly relates to business value? The whole point of having a goal is the guidance it offers when making decisions. Just like when you are travelling and arrive at a crossroads. Silly automation goals, such as ‘automate the regression test’ or ‘find more bugs’, however, are of little help when making choices, especially the strategic and tactical ones. A motivation such as ‘we do Scrum,’ or even ‘everyone does it,’ is even worse.
So let’s consider some aspects of AiT strategy, aspects that go beyond the obvious topics, such as automation architecture. I will list them in the form of questions you can ask yourself, using the well-known categories of Benefits, Costs, Opportunities, and Risks.
Benefits
- What goal for automation has clear value to the business?
- How can progress be measured (in a meaningful way)?
- What more detailed objectives can be used as stepping stones to the goal?
Costs
- What training should the development teams receive?
- What expertise should be hired and for how long?
- What additional test environments will be needed?
- What additional features will existing test environments need? (Think of testdata and service virtualisation.)
Opportunities
- How should (or might) the scope change over time?
- How can automation artifacts be shared effectively between teams?
- How can the automation technology be (re-)used for purposes other than the automated execution of functional tests?
- How often will tests be run, and how will test execution results be reported and shared?
Risks
- What lifecycle will manage the project / business risks of the automation? (Think of Proof of Concept, tool selection, pilot project, etc.)
- How are strategic and tactical decisions made?
- How is adequate support for the automation effort ensured?
- What roles are identified and who perform them?
- What education is needed for the relevant people outside of development teams?
- What cooperation between teams is needed to support automated integration and/or acceptance testing?
- What engineering practices will ensure a sustainable solution?
These are not all of the relevant questions. But you must have noticed that the risks section is the largest. This suggests that a proper strategy, rather than merely a suitable tool, is needed for success. AiT touches many existing activities and introduces some of its own, and it is easy to overlook something important until it is quite late (or, often enough, too late).
But knowing that all of these questions can be important to ask is a great help. Once you determine which of them are indeed relevant, you have a checklist to work with. The answers to the questions will define actions that can be planned. Following the plan (and, of course, adjusting over time as needed) will bring you to your (business-oriented) goal. It all starts with that goal …
Leave a Reply