Selenium.

Where Selenium fits on a long engagement.

Selenium's durable advantage is that it is a standard rather than a product. WebDriver is implemented by the browser vendors themselves, bindings exist for every significant language, and a suite written against it is not dependent on one company continuing to maintain a tool. On an estate expected to run for a decade that is a real consideration.

The trade-off is that it gives you less. No auto-waiting, so synchronisation is the test author's responsibility and badly written waits are the leading cause of flaky Selenium suites. No built-in tracing, so a CI failure has to be reproduced to be understood. Modern frameworks removed these problems; Selenium expects you to solve them.

What an assigned team does with Selenium.

Most Selenium estates we inherit are large, slow and partially trusted, with a set of tests everyone knows to ignore. The productive first step is establishing which tests are meaningful rather than migrating the whole suite to something newer.

That assessment is test-strategy work rather than automation work, and it is where an assignment should start. How scope is agreed before anything is rewritten is described in how an assignment runs.

What we use Selenium for.

• Maintaining a large existing suite Stabilising what is there and retiring what is not trusted, before considering a migration.
• Language flexibility across teams Tests in the same language as the application, which is what keeps them maintained.
• Grid execution across environments Distributed runs across browser and OS combinations, including hardware a cloud service does not offer.

How Selenium capacity is assigned.

Selenium capacity is assigned under outsource qa testing, starting from an assessment of which tests carry signal rather than from a rewrite.