Quality assurance: to automate or not to automate?
Over the last five years, automated testing has significantly evolved. Many automation companies have appeared, developing tools and environments that make automation more accessible. Open-source tools and frameworks have emerged, supported by huge communities that provide answers and solutions to newly-discovered issues.
All this makes things so much easier and convenient for automation test engineers. But does this mean that we can automate everything we want?
Yes and no: very often, automation is easier said than done. Test scenarios that were impossible to automate a few years ago can be automated now, but often at the cost of significant effort, expertise, and maybe even the developer team involvement. These factors can make it impractical to automate all testing, hence the importance of determining what test cases can and should be automated, i.e. when it’s worth it. Indeed, for some types of projects, like short-term projects, automated testing just doesn’t make sense. However, it is the driving force behind continuous delivery and agile practices.
Which brings us to the next question — what added value does an automated test scenario provide? Will it actually save everyone time? Will it give us the confidence that the delivered code works and did not break anything? This is perhaps the most crucial consideration in defining and selecting what parts of a process should be automated.
Ideally, this decision should be made by the whole team, including business analysts and budget owners. We all know that creating automated tests, like maintaining a system, is not cheap; but if it’s important from a business point of view, then you will get the necessary support to implement it. Being agile in this process is crucial: when you see that something has gone wrong, stopping to re-evaluate in the early stages of a project will save you a lot of time, effort and money down the line.
Running all-automated tests and merely checking status reports after the fact is the dream of any QA engineer. But for now, it’s a pipe dream. Even in “fully” automated processes, with a bunch of tests, responsible developers personally check functionality and code before deploying; this is called manual testing. Maybe, one day, artificial intelligence will be able to find and even fix all issues and bugs in a tested app. But for now, it remains an interesting and challenging task for us mortals.
