Chrome updated overnight and the entire pipeline failed the next morning with a message about an unsupported version. Every test, every team. That is the recurring cost of Selenium's greatest strength.
Why this happens and nothing else has the problem. Cypress and Playwright download and pin their own browsers. Selenium drives the browsers on your machines, so browser versions move underneath you on someone else's release schedule.
Governance, in order of how much control they give you.
Pin browser versions in your infrastructure. With Docker Grid nodes, use tagged images (selenium/node-chrome:120.0) rather than latest. Now an upgrade is a deliberate change you make on a Tuesday morning, not a surprise on a Friday night. This is the single most valuable change most teams can make.
Disable auto-update on long-lived machines. If you run browsers on persistent VMs, auto-update is a scheduled outage you did not schedule.
Use Selenium Manager for local development. It resolves drivers automatically and removes the version-mismatch problem for individual engineers, which is where it is most annoying and least dangerous.
Test the upgrade before adopting it. Run the suite against the new browser image in a separate job. When it passes, promote it. When it fails, you have found a genuine compatibility issue with time to handle it.
Deciding the browser matrix.
The mistake is running everything everywhere. Base it on your actual users, which means asking for analytics rather than guessing:
Chromium engines (Chrome, Edge) are usually the overwhelming majority. This is your primary, running on every commit.
Safari and WebKit matter if you have any meaningful iOS traffic, and this is the engine that differs most.
Firefox is a smaller share and still worth periodic coverage.
Legacy browsers. If a large enterprise customer runs an old browser, that is a contractual reality rather than a technical preference. Selenium is frequently chosen precisely for this, and it may be the only tool that can do it.
The tiering that works:
| Runs | What |
|---|---|
| Every commit | Smoke, primary browser |
| Pull request | Core suite, primary browser |
| Nightly | Full suite, all supported browsers |
| Pre-release | Everything, including legacy and real devices |
The reasoning matches the other tracks: cross-browser bugs are real but rare and clustered in layout, formatting and platform features. Business logic does not vary by engine, so running your full business-logic suite three times buys very little.
Handling genuine browser differences. When a real difference exists, the wrong answer is branching inside the test:
if (browser === 'safari') { /* different steps */ }
Those branches multiply until the test only really passes on one browser. Two better options: push the difference into the page object or wait helper, where it is one place and documented, or write a separate test for that browser and say why in the test name.
Real devices. Emulation covers viewport and engine. It does not cover device hardware, real network conditions, or platform browser quirks. If mobile is a significant channel, a cloud device provider is the honest answer, and it is a budget conversation to have explicitly rather than a gap to leave unstated.
Remember this: pin versions so upgrades are deliberate, tier the matrix by user share, and never branch on browser inside a test.
Reference: Browser drivers.