Whose job is it to boost Software Automation?
Software automation is a crucial software project in itself. I have had the pleasure of working with dozens of R&D teams, driving them towards continuous deployment pipelines. Often, external guidance is sought when problems regarding SW automation are so substantial that they start to impact the productivity of the whole R&D organisation.
In my opinion, one of the most essential parts of the pipeline is test automation. Far too shaky test automation is a common challenge, which slows down the entire SW Release cycle.
When asked why teams are not yet where they would like to be with software automation, the most typical answers are:
- Lack of time: We are too busy doing the actual product code
- Lack of people: We don't have anybody to do this work
- Lack of competence: We don't know how to make it work
- Lack of vision: Unclarity on the status and lack of vision where to aim
The fact is that most R&D teams have been assembled and budgeted for creating the actual SW product or service. There are Scrum masters, SW Engineers, Test Engineers and perhaps a UX designer and an architect. But very little, if any, attention is paid to the automation pipeline and its key part, Test Automation.
A critical SW project
Simple web application projects can be managed with e.g. a GitLab pipeline, unit tests and some Selenium based UI test cases. But in larger development projects with backend, mobile applications, accessories and custom firmware, it is important to realise that automation is a critical SW project.
It is not always entirely clear whose responsibility it is to enable software automation. Test Engineers might not have the skills or interest to develop the automation system, whereas Developers don't see the importance of automation, or for example refuse to help because there is the word "Test" in "Test Automation" and working on something related to "Testing" would seem like a step down for them in their career.
How is your team performing in SW automation?
Fixing the problem in the wrong way
One common mistake is to hire external help to "fix" the situation, perhaps remotely, with an expert sitting in a different room, building or even country.
The expert surely can fix the pipeline and write new test automation cases, but if the rest of the team continues working just as they have in the past, what happens when the expert leaves?
Even the best automation does not run itself forever. You might need to start from scratch again with a different toolset if nobody masters the techniques. There is a risk that the R&D team ignores the automation results. They might be too busy in product development, not understanding automation goals.
How do successful teams solve the challenge?
Everything starts from concrete goals that are measurable. Developers usually want to have a short feedback loop, whereas product owners want to have a short release cycle. Keeping this in mind, we could define the goals for example as:
- Regression pipeline ready in 5 minutes after git commit in any branch.
- 75% of features covered by automated acceptance testing in 2 hours.
- Ensuring it is possible to know the reason for a failed test case in 1 minute. This means that automation must store the call stacks, traces, protocol dumps, screenshots, videos or any other artefacts necessary to serve as the "black box". This way long debugging and re-running of the test case is not needed.
The whole team needs to commit and understand the goals – and understand why all this is done. The team also needs to follow the status and take automation so seriously that when it breaks, the first job for _everybody_ is to fix the automation and only after that continue with normal work. One practical tip is to have the automation as a topic during retrospectives.
You don't need to label "DevOps" or "Test automation" resources. An architect with a developer and testers can do wonders. The automation system might be more interesting in the SW solution than the "real" software you are developing! But time needs to be allocated, follow-up is necessary, and automation efforts are not free. In my opinion, successful modern teams can allocate up to 30% of their efforts to the automation pipeline.
Finally, outside experts with practical experience can provide valuable help. They can boost your automation to a new level and save you from months of trial-and-error experiments. But you and your team need to take responsibility both for creating the automation vision and following up that it actually transpires in daily work.