The Hard Part of Test Automation Isn’t Writing Tests Anymore

A few years ago, creating the automated test was usually the difficult part.

You had to choose a framework, learn its APIs, build a project structure, write selectors, configure a runner, and eventually persuade the test to pass on a developer machine.

That work still exists, but AI has made the first draft dramatically easier. A developer can describe a flow and get Playwright, Selenium, or Cypress code in seconds. A no-code platform can record a journey or generate editable steps from plain English.

The bottleneck has moved.

The difficult part now is building a test automation system that still produces useful information six months later, after the UI has changed, the team has grown, the CI environment has become busier, and the person who created the original tests is working on something else.

That changes how I evaluate test automation.

I care less about how quickly a tool can produce a successful demo and more about what happens after the demo.

Modern web applications are not clean, predictable DOM trees

Many test automation examples still use pages where every button is visible in the main document and every element has a stable identifier.

Real applications are messier.

A checkout flow might contain a payment form inside a cross-origin iframe. A design system might use nested web components and Shadow DOM. Authentication, chat, analytics, consent, and support widgets may all be injected by third parties on their own schedules.

This is why I think a serious evaluation should start with the hardest surface in the application, not the easiest login form.

A useful checklist is covered in is a good way to think about this.

A useful failed-run package should connect the test steps with the surrounding state:

• the exact application version and environment;


• feature flags and user permissions;


• the locator selected by the test;


• fallback locators or recovery actions;


• screenshots, DOM state, network activity, and console errors;


• test data created or modified during the run;


• the point where a replay diverged from the original execution.

This is especially important when AI is making decisions.

I do not need a giant wall of synthetic reasoning. I need a concise decision trail: what the agent expected, what it observed, what alternative it chose, and how confident it was.

Good automation does not merely say that something failed. It helps the team decide what to do next.

Framework comparisons need a real workflow

“Which framework is best?” is usually too broad to produce a useful answer.

The answer changes when the workflow includes dynamic tables, inline editing, search filters, animated navigation, API setup, multiple browsers, or frequent UI redesigns.

For example, is interesting because AI changes the cost of producing code, but it does not remove the ownership model behind that code.

AI can generate page objects, helpers, fixtures, and assertions. The team still owns the architecture, reviews, dependencies, failures, browser infrastructure, and future rewrites.

Generated code is cheaper to create. It is not automatically cheaper to operate.

Use APIs for state and the browser for behavior

One of the best ways to improve browser tests is to stop using the browser for every part of the setup.

Suppose the behavior under test is whether an archived project appears correctly in a dashboard.

Creating a user, logging in, navigating through several screens, creating a project, editing it, and archiving it through the UI may add several minutes and many possible failure points before the test reaches the thing it actually needs to validate.

An API call can create the required state directly. The browser can then verify the user experience.

provides a useful model for testing both sides of a flag, rollout targeting, transitions between variants, and rollback behavior.

A feature-flag test plan should answer questions such as:

• Does the old experience still work when the flag is disabled?


• Does the new experience work for every intended role and account type?


• What happens when the flag changes during an active session?


• Are API contracts compatible with both versions?


• Can the release be reverted without corrupting new data?


• Do analytics and audit events identify which variant was active?

The visual transition between states matters too.

Animated route changes and CSS View Transitions can create failures that look like locator problems even though the element is technically present. A control may be moving, covered, duplicated temporarily, or attached to a document that is being replaced.

describes the part that is often overlooked: turning remote test execution into an explicit release gate.

The pipeline should wait for completion, retrieve an aggregate result, print a useful summary, preserve links to evidence, and return a failing exit status when the release should be blocked.

Triggering a test is easy.

Teaching the delivery system how to trust the result is the real integration.

Browser infrastructure has an ownership cost

Eventually, a browser suite needs somewhere to run.

At that point, teams often compare a self-hosted Selenium Grid with a browser cloud such as BrowserStack. On paper, the self-hosted option may appear less expensive because the software is open source.

The missing line item is ownership.

makes an important point: the ongoing maintenance tax matters more than the first week of automation.

This is where platforms such as Endtest become interesting.

A code-first framework can be the right choice for teams that want maximum control and already have people committed to maintaining the framework. But a platform with editable tests, integrated execution, self-healing, API steps, cross-browser infrastructure, and understandable run evidence can create a different ownership model.

QA can own more of the coverage directly. Engineers can still participate without becoming the only people capable of changing a test. The organization buys a working testing system rather than assembling every layer separately.

That broader view is also reflected in compares the two beyond the usual speed benchmarks.

For teams considering a higher-level platform instead, Best No-Code Test Automation Tools in 2026 reviews Endtest, Mabl, testRigor, Ghost Inspector, Reflect, and TestMu AI from a practical usability perspective.

Final thought

The first successful automated test is no longer a meaningful milestone by itself.

The real milestone is when the team can run the suite repeatedly, understand failures quickly, trust the release signal, and update coverage without starting a small internal tooling project every time the frontend changes.

That is why the most important test automation questions in 2026 are operational:

• Who will maintain this?


• What evidence will a failure produce?


• How will it behave on complex browser surfaces?


• How will data be created and cleaned up?


• How will CI interpret the result?


• Who owns the browser infrastructure?


• Can the suite survive normal product change?

AI can accelerate test creation.

The winning tools will be the ones that reduce the work surrounding the test.