Barriers to Test Automation in Agile Teams

DEVELOPERS' ATTITUDES TOWARDS AUTOMATION

To understand developers' attitudes toward automation solutions, we need to look at how they see automation in traditional environments, where separate QA teams do all the testing work without involving developers in the testing process. The direct result of this environment leads developers to become less involved in the testing process (why bother with testing if there are dedicated QA teams to do the work for us).

In addition, the waterfall development process is built with different phases for development and testing, which makes testing even more remote to developers who do not need to do much after the completion of their stage as they usually have already moved on to the next project.

There is no separate QA department in an agile environment that provides a safety net for developers. The agile development team must ensure the quality of the product, and developers must become involved in all aspects of the testing process, from the unit testing level to system testing.

Developers must change their attitude, mindset, and culture to allow the team to succeed in an agile working environment. Developers who fail to do this will impede the team from delivering on their commitments.

Key Takeaway: Developers who expect a separate QA team to catch problems stay out of testing, and an agile team only succeeds when developers change that mindset and own testing from the unit test level to system testing.

UNREALISTIC MAINTENANCE COSTS

The main goal of automated frameworks is to boost the team's ROI while increasing the test execution, build creation, and overall process. So if we think about it, one of the main goals of using automated frameworks is to free engineers from performing manual work to focus on other aspects of the project.

But what happens when the team selects the wrong automated framework and uses poor test design that consumes most of their time to maintain and stabilize the written tests? This leads to an unrealistic situation where the team spends hours and days of manual work on frameworks that were supposed to free up their time.

A classic example of this scenario that I often see is agile teams that do not want to spend time on user-interface (UI) testing. The first thing they do is develop or purchase a third-party vendor capture tool to record their tests, expecting it to solve all their automation problems. Well, this will not work. The creation of thousands of lines of UI test scripts that (usually) don't follow code practices will create a situation where, over time, no one knows what they are supposed to do or why they were written at all. This leads to unrealistic maintenance time on tests that are maybe no longer relevant.

To overcome this barrier, the team must choose the proper framework for the automation they want to achieve. Someone capable of seeing the big picture must invest time in great test design and the future roadmap, and the team must use the relevant code practices that will make the code readable and easy to maintain over time.

Modern frameworks cut part of this maintenance load, but they do not remove it. Playwright and Cypress ship auto-waiting and retrying assertions, so a test fails less often for timing reasons alone. Recorders now generate locators for you, and some tools repair a broken locator at runtime. A repaired locator is still a guess, so the team must review every repair in code review. Treat these features as a way to reduce noise, not as a reason to skip test design.

Key Takeaway: Automation frees up time only when the team picks a framework that fits the goal and invests in readable test design, because recorded UI scripts and auto-repaired locators still have to be reviewed and maintained.

PREVIOUS BAD EXPERIENCES

One prevalent barrier among engineers is fundamental, and that is a previous bad experience in automation projects that didn't pay off. There are many challenges in automation projects, and, therefore, more opportunities can cause teams to fail, such as poor design, unstable automated frameworks, and many others. In this case, the organization must analyze the failures and ensure they will not recur in future projects.

Key Takeaway: Engineers who went through a failed automation project resist the next one, so the organization has to analyse what caused the earlier failure and make sure the same causes do not return.

LEGACY CODE

This is a simple fact: most engineers prefer to write their code rather than getting legacy code that other programmers wrote. When writing automated tests, we have another layer of testing, making it even harder for a developer to succeed with the project. The first barrier is the code itself. If a developer needs to work with code that they did not write or help design, it may be hard for them to understand the code itself and what tests should be created to provide good test coverage. The second barrier is legacy code that isn't designed for testability, making it almost impossible for an engineer to create automated test scripts without refactoring the legacy code.

Key Takeaway: Legacy code blocks test automation twice, because engineers struggle to test code they did not write, and code that was not designed for testability often needs refactoring first.

LETTING TESTERS DO THE WORK

If I need to select one reason that will lead to failure, again and again, I would probably say that it lets testers write the automated tests when they do not have the necessary knowledge and experience in the coding field.

This is just one classic example of how all team members of an agile team should be working as a single unit without separating between programmers and testers. Otherwise, the entire project can fail by letting the testers know that they have nothing to offer if they cannot handle basic test scripts in the agile world.

In the opposite direction, a robust and agile team will not let testers do this job without a supporting framework from the rest of the team. The team must understand that any automation project is the team's problem, not the responsibility of the testers just because they were responsible for quality in the old traditional environment.

Key Takeaway: Making testers who lack coding experience write the automated tests alone is a common cause of failure, because an automation project is the whole agile team's responsibility.

JOB SECURITY

Agile teams contain testers that, in many cases, were added to the team as a legacy from the previous environment. These testers often do not have coding experience and therefore focus on manual testing, which is less suitable in an agile environment. These testers may reject the idea of using automation processes for testing for fear of it making them less relevant in the future.

Key Takeaway: Manual testers carried over from a traditional QA department may resist test automation because they fear automation will make their own role less relevant.

FEAR OF FAILURE

Due to challenges inherent in automation projects, automation projects can be scary to engineers, from determining the goals to the implementation itself. As I learned over the years, programmers may know to write excellent production code, but once they focus on writing automated tests, they will face many logical and technical issues that they do not have in their day-to-day work.

Key Takeaway: Writing automated tests exposes programmers to logical and technical problems they do not meet in day-to-day production code, so even strong developers can find automation projects intimidating.

LACK OF SUPPORT AND KNOWLEDGE

I think that every engineer who has common sense about automation's benefits will want to use it to simplify work. But what happens when this engineer has neither the knowledge nor the time to invest in creating this framework? How can they free up time, in an already stressed environment, to learn new tools such as automated frameworks and design practices such as test driven development and refactoring?

To allow the team to gain the knowledge they need to master this area, the organization must provide the necessary coaching. An external expert is a great option to help the team get set up and save time. Coaching is needed in both the theoretical and technical aspects of automation practices. It is more important to free the team from learning and adopt this new approach in their day-to-day activities.

AI coding assistants have changed what this coaching must cover. An assistant can draft a test file in seconds. The scarce skill is no longer writing the test. It is judging whether the generated test asserts anything useful. Teach the team to check the assertion, the test data, and the cleanup step before a generated test is merged. A test that always passes hides a defect as well as no test at all.

Key Takeaway: Teams need coaching and protected time to learn automation frameworks and practices such as TDD, and that coaching must now cover checking the assertions, test data, and cleanup step of AI-generated tests.

FLAKY TESTS AND THE LOSS OF TRUST

Several of the barriers above share one technical cause. A flaky test passes and fails on the same code. Datadog defines a flaky test as one that shows both a passing and a failing status across multiple test runs for the same commit. Flakiness is a barrier because it removes the one thing automation is supposed to provide, which is an answer the team can act on. Google reported in 2016 that about 1.5% of all its test runs returned a flaky result, and that almost 16% of its tests carried some level of flakiness.

The damage shows up in how the team reacts. The same Google analysis found that about 84% of the pass-to-fail transitions its continuous integration system detected involved a flaky test. When most red builds are noise, engineers stop reading them. They re-run the job instead of opening the failure. Real defects then sit inside tests that the team has learned to dismiss. That experience is what creates the previous bad experiences and the fear of failure described earlier in this article.

Treat flakiness as tracked work rather than background noise. Record which tests flake and how often, so the team argues from data instead of memory. Playwright marks a test as flaky when it fails on the first run and passes when it is retried, so enabling retries produces a signal and not just a green build. Quarantine is the next step. Google described tooling that moves a test off the critical path once its flakiness gets too high and files a bug for developers to work on. Quarantine only helps if someone drains the list. A quarantine list that nobody works through removes coverage without anyone deciding to remove it.

Key Takeaway: Flaky tests destroy trust in automation because engineers re-run red builds instead of reading them, and Google found that about 84% of the pass-to-fail transitions its continuous integration system detected involved a flaky test.

CAN AI AGENTS REMOVE THESE AUTOMATION BARRIERS?

AI agents lower some of these barriers and leave the rest untouched. The clearest gain is on maintenance. Agent based tools reason about what an element is for rather than matching one stored selector, so a renamed button or a moved field does not automatically break a test. Natural language test authoring also lowers the entry cost for the manual testers described in the job security section, because a person who cannot write code can still describe a flow. A recent arXiv review of AI driven test automation groups the reported gains the same way, around test generation and maintenance rather than around judgement.

The limits matter more than the gains when you are trying to remove a barrier. A self healing agent cannot create a test oracle that was never written, cannot decide that a changed requirement is correct, and cannot tell a real regression from an intended change. A governance guide for self healing suites makes the same point and recommends that healing require human approval on critical flows such as payments, authentication, and checkout. An agent that quietly rewrites a locator on a payment test has not fixed the test. It has hidden a change.

So the barriers AI genuinely reduces are the mechanical ones, which are script maintenance, locator churn, and the first draft of a test. The barriers it does not touch are the human and organisational ones, which are developer attitudes, legacy code that was never designed for testability, and the up-front investment. Treat an agent as a way to cut the cost of the mechanical work, then spend the time you win on the barriers that no tool removes.

Key Takeaway: AI agents reduce mechanical barriers such as locator maintenance and first draft test generation, but they cannot supply a missing test oracle or judge a changed requirement, so every heal on a critical flow still needs human approval.

AN INVESTMENT THAT WILL NOT PAY OFF RIGHT AWAY

The team will need to invest time to create, plan, and design automated solutions that will reduce the manual work in the long term. But although the benefits are clear, we need to remember that even with the entire agile team working on the automated solution, it still requires a significant up-front investment that will reduce their ability to deliver functional PBIs in the first few sprints. This can be a big problem in an agile environment.

There is a huge psychological barrier that agile teams and the organization run into when they understand the investment they need to make at the beginning of the automated project, which will not pay off right away. Both the team and the organization must know that it takes time to decide which processes and tests should be (and can be) automated and which frameworks to use.

As I've seen in almost any automated project, the team must show senior management how automated solutions will help the organization increase the ROI. Although they will not see an increase in ROI in the first few iterations, without knowing the benefits, there is no chance that the organization will allow the team to invest the time they need to succeed with their automation challenges.

Key Takeaway: Building an automated solution reduces the team's ability to deliver functional PBIs in the first few sprints, so senior management will only fund that gap when the team explains the long-term ROI.