Why test automation isn’t happening like it should – and what can be done about it
The case for automated testing is well worn and the benefits are clear. In order to maintain pace with the latest technologies, testing needs to be done as fast as development. And this means automation.
There’s a fundamental truth that developers are wasting a lot more time than they think (or need to) on rework. The most savvy firms already track and try to minimise the effort in this area, but in a manual testing environment bugs are simply found too late, which results in lots of rework. Automation helps developers find problems much earlier in the development cycle, and being able to integrate automated testing throughout the SDLC speeds things up exponentially – improving quality and ultimately user experience, at every stage.
But, if it’s a no brainer to automate test processes, then why is it that so many companies simply aren’t doing it? The statistics say that automation is currently underexploited in Quality Assurance (QA) and testing, and whilst it’s certainly on the rise, less than 16 percent of test activities are being performed with automated technologies.
So what is the holding organisations back? Some of the lag is simply because getting automation right in your test environment is harder than it appears. In most cases the problem is not in implementing test automation, but in implementing it in an effective, efficient and scalable way. It is hard to create, maintain and scale the automation that a team needs – and even harder to achieve in a legacy project.
Overcoming the challenges
How do developers overcome some of these adoption challenges? There are a number of elements that need to be in place to get it right.
In the days when separate developer, tester and QA teams were the norm, testing would be something ‘for someone else’ to deal with. And while this has shifted, teams today are simply not putting enough budget, resource or time into optimising the testing process. If automation is to work, this must change. Testing needs to be viewed as an equal citizen to development – and of course, test driven development is the holy grail.
For many, this is a big shift. Collaboration between teams needs to be prioritised and a commitment to upskilling teams is crucial. Underpinning all of this must be strong leadership, stringent setting of KPIs and the commitment to continuous self-evaluation. Diverse teams and personas call for leadership as a unifying force, and a leader’s active role in affecting change is the key to success.
In addition, to get testing right and to move to an automated process, teams must treat testing exactly as they do production code. An automated test is code that runs for the purpose of testing. There’s no real difference between this and production code. Therefore, test code needs to be designed, created, versioned and maintained – just as it is for any piece of code – with the same rigour when it comes to ensuring quality. No longer should testing be seen as secondary to writing application code.
To effectively automate testing, teams must have the right tools in place. There’s a lot of choice in the market, so this means working with trusted partners, evaluating providers and tools against your objectives, and perhaps even looking at hybrid options to fit your needs. Importantly, this must be an ongoing process, where teams are able to evaluate and re-evaluate systems and providers, to ensure that they’re always able to take advantage of new developments.
There are lots of moving parts in the quest to achieve automation, and it’s perhaps this complexity which prevents automation being embraced as fully as it should. To address this, and help to simplify the process, there are continuous testing blueprints which further break down the steps needed in order to get to a skilled automated testing suite. The process is split into four phases; blueprints take the team through this step by step.
The first step is to prepare the infrastructure, making sure the DevOps stack, the lab, the CI and the deployment are integrated. Step two is to choose a small number of tests which are high value, and performed on a regular basis, and automate these. Start small and prove the use case, and the mindset shift we talked about will start to happen. If teams are using these tests regularly, and relying on them, it’s easier to move on to step three: scaling automation.
In the third step, as well as scaling the number of tests, teams must put fast feedback capabilities into place to analyse and record the tests effectively on a big scale. It’s a common mistake not to put fast feedback loops in place and then teams drown in data. There’s no point in automating hundreds of scrips it they’re not effectively analysed.
The final step is putting together a process on how to maintain these tests and keep them valuable at the same time.
By following these steps, teams will be well on the way to effective automation and to reaping the rewards that an automated, streamlined, test strategy can deliver.
So, in a hyper competitive digital environment, where speed and quality are make or break for organisations, the idea of test automation is nothing new – and we all know that there are significant benefits if you get it right. It’s well documented that automation vastly increases test coverage, as well as the depth and scope of tests and ultimately helps improve software quality.
Whilst automated software testing has long been considered critical for big software development organisations but too expensive or difficult for smaller companies to implement, now is the time for everyone to benefit from test automation. With the right tools, the proper processes, and by forming partnerships with experts in the industry, there’s no reason why all companies can’t overcome the automation challenges, and be able to enjoy the rewards.
Bradbury Hart, VP and Chief Evangelist at Perfecto
Image Credit: Christina Morillo / Pexels
source : www.itproportal.com