logo logo

Top 10 Reasons Why Test Automation Fails

Top 10 Reasons Why Test Automation Fails

In this article, we will investigate the Top 10 Reasons for Automation Failure. There are several benefits to automation such as receiving fast feedback, increasing efficiency, saving time and effort. However, to obtain an accurate picture of automation, it’s necessary to understand the pitfalls. Some organizations focus solely on User Interface (UI) Testing although API Testing is important. Here’s a list of the Top 10 Reasons Why Test Automation Fails:

  1. Not Having A Plan For Automation
  2. Lack of Knowledge From Decision Makers
  3. Unrealistic Expectations
  4. Reinventing The Wheel
  5. Not Having Independent Test
  6. No Design Pattern
  7. Not Scaling Automation Undertakings
  8. Not Executing Test In Parallel
  9. Lack of Test Reports
  10. Not Selecting The Right Tool(s)

1) Not Having A Plan For Automation

Have you heard the famous quote by Benjamin Franklin that says “If you fail to plan, you are planning to fail.” I’m not sure of the details Benjamin Franklin was talking about, but the quote also applies to automation.

The test plan emphasizes what a respective team is aiming to accomplish. At the beginning, we must plan for several components regarding automation. A couple components are which test to automate and how to progress towards Continuous Integration (CI) pipelines. The considerations to decide if a test is a candidate for automation are:

  • Regression Test Cases / Repetitive Test Executions
  • Test Cases prone to human fault
  • Application functionalities unlikely to change
  • Test Scenarios that are time-consuming

I recommend starting with the simplest automation tasks then moderately work up to complex tasks. Gather feedback and gradually construct a CI pipeline.

2) Lack of Knowledge From Decision Makers

I’ve seen extreme cases where decision-makers have no clue what’s going on with their automation team and have no desire to find out. Not always true but sometimes. The decision-makers are happy as long as they see buttons automatically getting clicked and text fields receiving information.

It’s critical decision-makers gain knowledge of automation for 2 reasons:

  1. Understand the automation engineer(s) recommendations/concerns
  2. Recognize if the automation engineer(s) have sufficient skills

An example of insufficient skills is automation code with hard-coded sleep statements. A sleep statement waits for a specific time even if the next step is ready for execution. I recall a situation during demo day on a previous project. People outside of the automation team were excited to see the automation Test Scripts.

5 sprint teams demonstrated a few Test Scripts. Out of the 5 teams, 3 were successful and 2 were not successful. Needless to say, it was an embarrassment. The 2 were not successful because one execution was extremely slow and the other execution was flaky (Fail – Pass – Fail). A person in the audience without a filter (who likes to speak their mind) asked “Why is it running so slow” then commented, “I could have executed the same steps faster”.

Note: Automation Code Review was recommended but it never came to fruition.

3) Unrealistic Expectations

It’s virtually impossible to automate every function. There are some functionalities where human inspection is better than automation. One of the benefits of automation is to free up time so more time is performed via functional testing.

However, for the sake of making a good impression or unknowingly, an automation engineer will create a Test Script for something that is probably best left alone. Each Test Script he/she automate, may require an update. As a result, extra time is spent updating existing Test Scripts rather than using that time and energy towards creating new Test Scripts.

Also, it will take longer to execute all Test Scripts which is not beneficial for CI. The idea of CI is to receive quick feedback.

4) Reinventing The Wheel

Reinventing the wheel is another way of saying time, effort, etc. is spent developing something that’s already available. For automation, there are several licensed and open-source tools in the market. We can leverage an existing mature product that has community support. With that support and valuable time, an automation team has the luxury to focus on creating automation Test Scripts.

I remember a case that involved an engineer reinventing the wheel. At the same company but a different project, his team was restricted from using 3rd Party Tools. So they had to develop a framework from scratch although effective frameworks were available.

5) Not Having Independent Tests

Dependent tests are another common reason why test automation fails. As a general rule, tests run independently of each other. An independent test is a test that passes or fails on its own merit. The pass or fail result has no impact on a different test. A dependent test may fail because the previously executed test failed. This is an example of a cascading failure where 1 failure triggers another test to fail. It’s challenging to debug test results due to a cascading failure.

6) No Design Pattern

The purpose of a design pattern is to have a solution for a problem. It shows how to design our code so it’s maintainable. Many projects fail because codebases grow with an inability to maintain the codebases. Maintaining code using a design pattern takes less time to make a code change. Respectively minimizing the maintenance cost while providing a template for new Test Scripts.

In addition to code maintenance, a couple more benefits are code readability and code reusability. Code readability means the code is easy to follow. Code reusability helps when an automation engineer needs to reuse their code in multiple locations.

7) Not Scaling Automation Undertakings

For automation, scaling refers to empowering, enabling, and supporting growth to improve software quality. It’s difficult to create Test Scripts for multiple environments, browsers, and devices without a set of guidelines. An automation framework or cloud solution assists with managing different kinds of resources.

For example, a Data-Driven Framework separates data from the Test Scripts. We can conveniently execute tests against multiple browsers and environments using different data sets. A cloud solution assists with running tests on many devices, platforms, and operating systems. Scaling for automation helps reduce or avoid refactoring our code.

8) Not Executing Test In Parallel

Parallel Testing is a test type that executes multiple scripts at the same time. The benefit saves a lot of time compared to sequentially executing Test Scripts. Since our tests run simultaneously, we need to make sure they are independent. Multiple tests cannot run at the same time if one is waiting for another test to complete. When it comes to feedback, the results are directed to appropriate people in a timely manner.

9) Lack of Test Reports

The purpose of Test Reports is to analyze results. We get an opportunity to see if our tests pass or fail. If there is a failure then we can investigate each problem and solve the problem. Some automation endeavors fail because they do not have reports or neglect the reports. Either way, the automation team is overlooking a chance to identify what took place during execution.

10) Not Selecting The Right Tool(s)

There are many kinds of tools in the market for automation. We have codeless tools and tools that require coding knowledge. However, the market is short of tools that encompass code and codeless. The right tool is important because it produces an effect on our entire automation effort. Prior to selecting a tool, an organization must think about its application, requirements, expectations, and cost.

All tools have definite capabilities for automation. Sometimes a tool is selected because it’s the most popular. However, popularity does not mean superiority. It could be the best or may not be the best. That’s why an organization must carefully consider its needs for automation success.

My preferred automation endeavors/tools are:

  • Selenium WebDriver – automate web browsers for testing UI
  • TestNG – test framework with several assertions to verify results
  • TestProject – free end-to-end automation platform for web, mobile, and API testing
  • Rest Assured – library for testing RESTful Web Services
  • Appium – automate native, mobile web, and hybrid applications for multiple platforms (iOS, Android, Windows)
  • Jenkins – provide a way to set up a CI/CD environment

A Solution For Automation Failures

TestProject solves the automation failures that deal with creating Test Scripts, executing Test Scripts, viewing reports, and selecting a tool. The other failures involve planning and thinking through ideas. Some of the ways TestProject also helps is by integrating well with other tools such as Jenkins, qTest, and Slack.

  • Jenkins facilitates the automation of functionalities related to building, testing, and deploying software for CI/CD
  • qTest is a tool that manages projects, test cases, and track bugs
  • Slack is messaging platform to communicate with your team

TestProject provides an Agent and powerful OpenSDK for our automation efforts. The agent has all Selenium and Appium dependencies to create automation test scripts. We can make sure to not reinvent the wheel, create independent tests, establish a design pattern, and execute our test in parallel. Automatically test reports and dashboards are created after executing a test. We have the option of recording our test or coding our test via Java, C#, Python, or JavaScript. For collaboration and feedback, TestProject offers Addons to make test scripts reusable.


Automation is an effective way to improve software quality in a fast manner. Beginning with a plan all the way to viewing results from a test report. There are drawbacks but the benefits outweigh drawbacks when observing the Top 10 Reasons Why Test Automation Fails.

About the author

Rex Jones II

Rex Jones II has a passion for sharing knowledge about testing software. His background is development but enjoys testing applications.

Rex is an author, trainer, consultant, and former Board of Director for User Group: Dallas / Fort Worth Mercury User Group (DFWMUG) and member of User Group: Dallas / Fort Worth Quality Assurance Association (DFWQAA). In addition, he is a Certified Software Tester Engineer (CSTE) and has a Test Management Approach (TMap) certification.

Recently, Rex created a social network that demonstrate automation videos. In addition to the social network, he has written 6 Programming / Automation books covering VBScript the programming language for QTP/UFT, Java, Selenium WebDriver, and TestNG.

✔️ YouTube https://www.youtube.com/c/RexJonesII/videos
✔️ Facebook http://facebook.com/JonesRexII
✔️ Twitter https://twitter.com/RexJonesII
✔️ GitHub https://github.com/RexJonesII/Free-Videos
✔️ LinkedIn https://www.linkedin.com/in/rexjones34/

Leave a Reply