Practical tips how to reach software and test automation goals
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:
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.
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.
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.
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:
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.