What is browser automation?
Browser automation drives a web application through its pages by issuing the clicks and keystrokes a person would. It operates above the application's own integration layer, so it depends on the markup and the layout staying where they were. It is the method of choice where a system offers no supported integration at all.
Why browser automation is a dependency on somebody else's markup
The question that decides a browser automation programme is what happens on the Tuesday the vendor ships a redesign. Nothing in the automation is wrong, and every locator it depended on has moved. Teams that treat this as an incident spend the following year in incidents. Teams that treat it as a certainty engineer around it by choosing resilient locators and rehearsing against each new release.
- A browser automation inherits every change the application vendor makes.
- Locators chosen for convenience are the first thing a redesign invalidates.
- The automation sees what a person sees, which is also its only verification.
- Resilience here is a design choice rather than a property of the tooling.
How browser automation works
- A session is established with credentials retrieved from a vault.
- Elements are located by stable attributes rather than by position on the page.
- Each step waits for the application's own readiness signal before proceeding.
- The state after each action is verified against what the step intended.
- Page state is captured at each step so the action has evidence behind it.
- A failure releases the session cleanly, leaving the next attempt a known starting point.
How browser automation is evaluated
Browser automation is assessed on how it behaves when the page is slower or different than expected. Measure the following over live volume:
- step success rate against the application's response time
- failures attributable to a locator that no longer resolves
- proportion of steps verifying their own outcome
- recovery rate after a session is interrupted mid-task
- elapsed time to repair after a vendor release
Limitations, risks and common failure modes
- Locators tied to generated class names change with every vendor deployment.
- Fixed waits pass in a test environment and fail under production load.
- A step that succeeds visually leaves the record without proof that it committed.
- Captured screens contain personal data that nobody scoped for retention.