Modern browser testing is no longer just about clicking a button and checking whether the next page loads.
Frontend applications now contain animated route changes, Shadow DOM components, dynamic validation, session refresh logic, AI-generated interfaces, visual transitions, and increasingly complex release pipelines.
At the same time, AI is making it easier to generate both application code and automated tests. That sounds like it should simplify testing, but it also creates a new problem: teams can produce more code and more tests without necessarily improving confidence in their releases.
I recently went through several articles that explore these problems from different angles. Here are some of the ideas that stood out.
Some failures only happen when the browser actually renders the page
A test can pass repeatedly and then fail when a layout shift causes the browser to recalculate the position of an element.
That is particularly frustrating because the selector may be correct and the element may technically exist. The failure happens because the page is moving while the automation is trying to interact with it.
This guide on looks specifically at failures that happen during these transitions.
The important lesson is that waiting for an element to exist is not always enough. Sometimes you need to wait for the interface to become stable.
Green CI does not automatically mean a release is safe
Most teams still treat automated tests as a binary signal:
- Green means release.
- Red means investigate.
That model is useful, but it becomes less reliable when applications and tests are changing quickly.
A passing test suite might still miss a visual regression, an untested AI-generated code path, or a risky frontend change that deserves additional review.
.
This does not mean every release needs a complicated scoring system. It means the release signal should reflect the actual risks of the application.
AI-generated pull requests still require human judgment
AI can generate a working frontend feature surprisingly quickly. It can also generate tests for that feature.
But generated tests often focus on the most obvious path. They may not cover interrupted workflows, existing user state, permission differences, session expiration, validation errors, or interactions with older parts of the application.
compares the two approaches in that context.
Maintenance is another major factor. A code-first framework can offer a great deal of flexibility, but the team must own the framework, integrations, debugging process, reporting, infrastructure, and long-term updates.
for teams choosing between an AI-assisted platform and a code-first browser automation library.
For checkout testing, the requirements can be different again. Redirects, conditional fields, dynamic totals, third-party payment pages, and changing validation messages can make a simple purchase flow surprisingly difficult to automate reliably.
looks at the practical requirements behind these scenarios.
Internal tools have similarly complicated workflows. A request may need to move through several users, roles, and approval states before it is complete.
discusses what teams should evaluate when choosing an automation approach for these workflows.
This will probably become a more common testing pattern as AI features are added to existing SaaS products.
What does “automating tests with AI” actually mean?
AI testing is becoming an increasingly broad category.
It can mean:
- Generating test code from a prompt.
- Creating tests from natural-language instructions.
- Repairing selectors after an interface changes.
- Identifying visual differences.
- Suggesting missing test cases.
- Analyzing failures and logs.
- Executing browser actions through an agent.
These capabilities solve different problems and have different costs.
covers how this approach works, what it can be used for, and where it fits alongside traditional Playwright tests.
I also recently published a video comparing Playwright and Selenium in the current testing landscape:
The Playwright-versus-Selenium debate is often framed as a battle between an old tool and a new tool. The reality is more nuanced.
Both can automate browsers. The larger differences usually involve architecture, ecosystem compatibility, team experience, maintenance expectations, and how much supporting infrastructure the team is prepared to build.
The recurring theme: test automation is a system
The common thread across all of these topics is that browser automation libraries are only one part of the solution.
A reliable testing process also depends on:
- Application stability.
- Test data.
- Browser infrastructure.
- Debugging evidence.
- Reporting.
- Permissions.
- Release policies.
- Team adoption.
- Long-term maintenance.
AI can help with many of these areas, but it does not eliminate the need to design the overall system carefully.
The teams that get the most value from automation are rarely the teams that generate the largest number of tests. They are the teams that create a dependable feedback loop and keep it useful as the product changes.
SOCIAL SHARE CARD GENERATOR