While almost all software companies see the need for automation and promote it in their strategies, few are actually getting it right in a way that supports rapid development and high quality at the same time. There are many solutions to this, which I’ve presented previously, but today I want to have a brief look at exactly why automation fails so often in companies and perhaps help make you more aware of an area where your company could do with some improvement in.
No Clear Direction
I think it goes without saying that the main reason automation doesn’t work for companies is because there is no clear plan or too much experimentation going on. There are a lot of different approaches to automation and fantastic tools out there, but unless you know exactly which direction would be best for you, it’s easy to stumble across the wrong ones or alternatively be left with too many to maintain. Rather focus on one specific automation framework for your company and adapt it to suit your needs. I understand it’s tempting to want to always jump onto the next big thing, but the next big thing is not always the thing for you. Having a well-defined framework and strategy in place alleviates this by easily determining what tool or technique best fits your overarching automation strategy and framework.
Poor Software Architecture
This is an easy one to fall into, especially for companies with legacy systems that are several years old and designed well before they planned for extensive test automation. One of the reasons why automation seemingly fails so often is because the underlying software or processes are not designed around the testing effort in the first place. Automation is not something that can simply be tacked onto and expected to fit current architecture and development processes but rather works best when these are designed around the most testable solutions. If this is you, unfortunately there is no easy way to solve this. While you can mitigate some of the risks through a well-architectured automation framework, you will always be on the back-step until you start to design everything around how you test.
Poor Automation Maintenance
Test automaton is not something you can simply write and expect to work forever. Software is constantly changing and so do your tests. Much like companies need to support their software, so they also need to support their automation framework and tests. Automation work should be planned for every sprint or release cycle in your teams. Not just for forward looking work but especially for existing tests and for updating the framework in general. A lot of companies might understand this principle but then write this work off as technical debt, which is a problem because quality should never be something you catch up on but rather be foremost of your development effort. Plan for your automation work and invest time in ensuring it is always operational and up-to-date. Things that require maintenance include updating old scripts, resolving conflicts between different modules, bug fixing, keeping firmware/tools and general enhancements. Work on your automation framework and tests never stop and maintenance work for this should always be prioritised.
Redundancy
Test redundancy happens in many ways. Teams writing a test that covers the same functionality across many different levels of testing. Teams using too many frameworks that end up writing the same functionality across each framework or even teams which aren’t maintaining their automation and are left with too many old tests that are no longer relevant. Redundancy means that your teams are doing the same thing multiple times which defeats the purpose of automating it in the first place and the excess tests also bloat your execution times and inflate your failures. Redundancy is unnecessary waste and should be addressed at all levels.
Automation Skills Development
Perhaps the most important reason companies struggle with test automation is because they are not resourced effectively for test automation. Test automation done right is a lot closer to a software development role than a traditional testing one and you need to ensure that you have the right people in place who have the skill-set to make it work. This means hiring highly-skilled coders as test engineers and also placing significant investment in your current testing teams to enhance their skills and incentivize them to improve accordingly. The down-side is that sometimes there is just too many people without the necessary skills to right your ship quickly and companies may need to slowly work towards phasing new skills in and old skills out to achieve the right balance in their teams.
Automation is not something companies should leave to guess work or over experimentation. It’s important to strategize correctly and make the necessary investment and sacrifices needed to change the way you work and build the right frameworks to your automation success. I hope everyone can use the year ahead to advance the automation efforts in their development pipeline and act if there are any stumbling blocks in place that might be threatening to derail automation and quality further. There may be no silver bullets to any facet of software development, but you can at least plan to avoid failure.