Top 5 Mistakes That Can Sabotage a Successful Test Automation Project

In a previous article, we had a look at how to effectively manage Appium-based test automation projects. While sharing many common characteristics with software development projects in general, test automation presents some unique challenges. This time we will be looking at the common pitfalls that can prevent a test automation project from succeeding, and how to avoid them.

1. Underestimating the impact of maintenance overhead

This one is particularly tricky. People often do not realize the cost of maintaining an automated testing infrastructure. If you are writing test scripts for a rapidly changing application, you should gather all the information that you need and then take some time to come up with an estimate for this overhead. Having a solid testing setup really makes the difference here: fixing broken tests is faster when you have clean, readable test scripts with little to no duplicated code. Following a pattern such as PageObject can help you build such a setup.

2. Writing and running your tests on a single device, expecting them to run reliably on all

While a decently written Appium test will work quite reliably on most devices of the same form factor and platform, there are several reasons for running your tests on multiple devices from day one. If, while in the process of writing your tests, you only run them on a single Android smartphone, you will probably be missing out on small details that might break them for both tablets and iOS devices. It’s better to invest more time at the very beginning and figure out where these pain points are, rather than wait until the whole setup has grown too much in size. Form factor and platform are not the only variables you will have to keep in mind: OS version and device manufacturer can also play a role in this situation.

3. Not fully leveraging test automation

Automation doesn’t stop at running decently organized Appium tests. Seeing how you will need to run your tests multiple times (if not continuously!) to verify their reliability, setting up a CI server will probably be a necessity. This will allow you to run your tests periodically or with one click, minimising the amount of time you need to invest in launching the tests themselves.

In general, everything that allows your team to avoid tedious tasks and save significant amounts of time should be a high priority for your team. Time has to be invested in figuring out the issues and getting more tests up and running, not in menial tasks that get repeated over and over again.

4. Losing track of the real test automation project status

Another very common issue is losing track of the actual status of a test automation project.

  • How many tests have been written, and how many are working reliably?
  • Which part of the codebase needs to be adapted after a new app version has come out?
  • Are all tests still relevant?
  • What developments are currently blocked and what is blocking them?

Having all this information up to date and visible at a glance is a fundamental prerequisite for good decision making. Setting up the right process might take time at the beginning, when your to-do list is probably at its scariest, but it definitely pays off when deadlines get closer and choices have to be made quickly.

5.Having inefficient communication

This is not something that’s specific to automation projects, and possibly not even software projects, but is still a major pain point in many cases. The speed at which information can flow throughout all the teams and organizations which are involved in your project is a fundamental factor that can determine whether your efforts lead to success or to failure. While the topic itself is not terribly complex, do spend some time thinking which software tools you are going to use and how to set up a process that allows quick and precise communication, both with other members of your team and with the customer. You don’t want to have to wait longer for tasks to be unblocked because you or someone else is busy parsing a 200-messages long email thread.

Written by

Giovanni Rago

Topics

Automated testingAppium

Categories