3 Misconceptions about Test Automation

— Adam Satterfield, Vice President of Testing Services for KMS Technology, discusses how you can avoid common test automation mistakes.

The move towards a continuous delivery model of software development has contributed to the growing popularity of automated testing. DevOps has also encouraged the breakdown of barriers between traditional roles. Testers with coding skills (which is what automation testers really are) fit nicely into this new paradigm.

Test automation offers many potential advantages, including increasing efficiency and providing an effective way to solve complex testing issues. Automating tests also introduces more consistency, allowing for more efficient use of resources during off-peak hours. However, test automation is not a panacea. To realise the potential of test automation, it’s important to be aware of three common test automation mistakes.

3 Misconceptions of Test Automation

1) Automation will replace testers

The idea that you can take a tester with critical thinking skills, classically trained testing ability, and investigatory powers and get rid of them by putting code in their place is a fallacy. Scripts are not going to think critically or perform deep-dive investigations into your software. The scripts you employ are only as good as the tester who writes them.

We no longer see the industry as made up of manual and automated testers.  We have testers with coding skills and those without – all contribute in different ways. Trained testers will always have a place because of their ability to think critically, beyond a script.

Until we have powerful and affordable artificial intelligence, where the scripts are writing themselves, automated testing is just another tool in the box. It’s also worth noting that we fundamentally write software for humans to use, so a tester’s perspective will always be valuable.

2) You should automate UI tests first

This is a common misconception. In today’s DevOps and continuous delivery world, automating through the UI first is a recipe for disaster. The UI is brittle. It is in a constant state of flux as it evolves based on the needs of the client and the market. If you start test automation with the UI, then be prepared for your automation team to spend the bulk of their time rewriting UI tests.

UI tests typically take a very long time to run. What you want to do is focus on lower level or component-level tests first.  Not only are these the tests that are going to run more quickly and with every build, but lower level component, unit and integration tests tend not to change as frequently. Your scripts can validate that your base functionality is working and then you can employ manual exploratory testing to validate the UI.

UI tests are easier to write, but if you end up with a lot of UI tests and very few unit and integration tests, then you have an ice cream cone instead of a test pyramid. You’ve built a massive test repository that’s unmanageable and your automation team is going to be bogged down in rewriting test cases.

3) Automation testers just script manual test cases

The term ‘automation tester’ is restrictive. The last thing you want to do is confine a tester with coding skills to scripting manual test cases. Let them think outside the box and use their coding skills creatively.

For example, let’s say you have a tester working on RegEx functionality and they need to create 500,000 documents in a user’s Google drive to validate that functionality.  Instead of spending days creating the documents, if you give them the freedom, they might just spend a day or so using Google APIs to create a reusable script that generates the docs on demand.

Mocking or stubbing test data is an important part of testing. You don’t want testers waiting for developers to create mock environments/data with the right dependencies before they test. If they have coding skills and they are empowered to solve problems for themselves, then they can easily be self-reliant. If they spot an opportunity to boost efficiency through the creation of a simple tool, then they should be free to build it.

The same logic that is driving the DevOps movement applies to testers with coding skills. Blurring of roles can lead to new insights that harness your employee’s skills. This can improve the quality of the software currently under development, but also improve your entire set of development processes.

Test automation is an important part of modern software development. Just make sure that you take the time to formulate a solid strategy to get the best out of it.

About the Author: Jordan Platt

Source: Software Testing News