Test automation
Selenium
The WebDriver standard, and everything built on top.
Selenium in practice
The oldest browser automation tool still in serious use, and the only one that became a standard: WebDriver is a W3C specification, and the browser vendors ship the drivers themselves. That is why it reaches places newer libraries cannot, including the Safari that Apple actually distributes and the long tail of managed enterprise browser estates. It is a driver binding rather than a testing framework, so the runner, the assertions, the fixtures and the reporting all come from whatever a team assembles around it.
We reach for it when the binding constraint is the environment rather than the authoring experience. A client whose engineers work in Java or C# and will inherit the suite is better served by tests in their own language than by a faster tool nobody on the team will ever open. It is equally the sensible answer where grid infrastructure already exists and is paid for, where a browser outside the modern shortlist is in scope, and inside organisations whose approval process moves considerably slower than the JavaScript ecosystem.
Nothing waits on your behalf. Without explicit waits written by hand it manufactures intermittent failures, and the volume of that code inside a mature suite is not a rounding error.
It is slower in practice than tools speaking a debugging protocol directly, because each command is a round trip to a separate driver process. Over tens of thousands of steps in a nightly run, the difference becomes the reason nobody waits for the result.
It is not a framework and does not pretend to be. Parallelism, retries, reporting, fixtures and data setup are all assembled by you, and the quality of that assembly decides whether the suite survives its first year.
Request interception and browser-level events were never part of the classic API. The newer bidirectional protocol is closing that gap, and a team on an older stack should verify rather than assume it is available to them.
Driver and browser versions drift apart. Current releases manage the binaries themselves, though anyone maintaining an older suite will recognise the morning where a browser updated overnight and the pipeline went red for reasons unconnected to the product.
FAQ
Selenium questions we hear often
Is Selenium obsolete?
No, and the question usually comes from comparing authoring experience rather than reach. It is the only one of these built on a standard the browser vendors implement, it covers browsers the newer libraries do not, and very large suites run on it every day without drama. What is fair to say is that it would rarely be our choice for a greenfield web suite today.
Why is our Selenium suite so unreliable?
Almost always because of unstated assumptions about timing and shared state, rather than anything the tool did. Fixed sleeps, locators bound to generated class names, and several tests writing to one database will produce intermittent failures in any runner you choose. Moving to something with automatic waiting conceals a portion of that, which is a different outcome from repairing it.
Can we test on real Safari?
Yes, through the driver Apple ships with the browser, and that is the practical reason teams under a genuine Safari obligation stay put. Real iOS hardware is a separate question needing a device cloud or a mobile stack. Where Safari parity is contractual rather than preferred, raise it at the start, because it narrows the tooling conversation considerably.
Own grid, or a hosted browser service?
Operate your own where you already run infrastructure, need browsers inside the network, or cannot send application traffic to a third party at all. Take the hosted route when what you want is browser and device breadth with no operational commitment attached. The one poor reason to self-host is saving money, since a neglected grid bills you in engineering hours instead.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.