Selenium WebDriver
The long-established standard for browser automation. Widely used in enterprise and legacy codebases across NZ.
Overview
Selenium WebDriver, first released in 2004, is the most widely adopted browser automation framework in history. It drives browsers via the W3C WebDriver protocol and supports more programming languages and browser versions than any alternative. Selenium 4 (released 2021) added CDP support, relative locators, and improved grid architecture.
In NZ enterprise environments — particularly banking, insurance, and government — Selenium remains the dominant automation tool. Organisations with large existing Java or C# codebases often stick with Selenium because migrating thousands of tests to Playwright is prohibitively expensive.
What it's used for
Selenium is the right choice when:
- Legacy system testing: Older web applications built on ASP.NET WebForms, Java Server Faces, or similar frameworks often have compatibility issues with modern tools.
- Multi-language enterprise teams: If your organisation has Java, C#, Python, and Ruby teams all writing automation, Selenium is the common denominator.
- Custom browser requirements: Selenium Grid supports more browser versions and configurations than any competitor.
- Extensive third-party integration: Decades of ecosystem growth means every CI tool, test framework, and reporting platform supports Selenium.
Pros & Cons
Pros
- Broadest language support: Java, C#, Python, Ruby, JavaScript, Kotlin
- W3C WebDriver standard ensures browser vendor compatibility
- Selenium Grid enables distributed execution across many machines
- Massive ecosystem: every CI tool, framework, and cloud platform integrates
- Free and open source with no vendor lock-in
Cons
- No native auto-waiting — explicit waits required to avoid flakiness
- Slower than Playwright and Cypress due to WebDriver protocol overhead
- Setup complexity: driver binaries must match browser versions exactly
- Test debugging is harder without built-in trace viewers
- Selenium IDE record-and-replay produces brittle scripts
Platforms & Integrations
Selenium runs on Windows, macOS, and Linux. It supports Chrome, Firefox, Safari, Edge, and Internet Explorer (legacy).
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | WebDriver, Grid, IDE, all language bindings |
| Selenium Cloud (Sauce Labs/BrowserStack) | $29-$199/mo | Managed grid, real devices, test analytics |
NZ Context
Selenium is still the most common E2E tool in NZ enterprise job postings. Large NZ financial services organisations and government agencies have accumulated years of Selenium investment — Java and C# suites that are actively maintained and not going anywhere. The Selenium project is actively maintained by the non-profit Selenium Foundation. NZ testers should know Selenium even if their current role uses Playwright — interviewers frequently ask candidates to compare the two.
Alternatives
- Playwright — Faster, more reliable, and better DX for modern web apps. The 2026 default for new projects.
- Cypress — Better for frontend developers who want debugging inside the browser.
- WebdriverIO — A modern JavaScript wrapper around WebDriver with better DX than raw Selenium.
When to choose Selenium
A quick decision guide for NZ teams evaluating ui / e2e automation options.
| Choose Selenium when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team already has 500+ Selenium tests in Java or C# and migration cost outweighs DX gains | You are starting a greenfield project — Playwright has faster execution, built-in waiting, and trace viewer with no extra setup | TestNG or JUnit 5 — structured test lifecycle, parallel execution, and reporting that Selenium lacks natively |
| You need to test Internet Explorer 11 or legacy Safari versions for a government or banking client requirement | Your app is a React or Vue SPA — Cypress gives your devs a fast feedback loop with time-travel debugging inside the browser | BrowserStack Automate — real device and browser matrix without managing your own Selenium Grid infrastructure |
| Multiple language teams (Java backend, Python ML, C# .NET) need to contribute to a shared automation suite | Your team is small and speed matters — Playwright's auto-waiting removes the explicit wait boilerplate that makes Selenium slow to write and maintain | Allure Report — rich HTML test reports with step-level screenshots and history trends that Selenium's built-in output lacks |
| Your organisation runs Selenium Grid on-prem because cloud execution is blocked by data sovereignty or security policy | You need to intercept or mock network requests — Playwright's built-in network interception handles this cleanly; Selenium requires a proxy like BrowserMob | RestAssured or Postman — pair Selenium UI tests with API-layer checks so a failing UI test can be quickly triaged as a frontend vs backend issue |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: Selenium is the right answer when your constraints — legacy browsers, existing test suites, multi-language teams, or on-prem Grid requirements — make it the only practical fit. When those constraints are absent, Playwright is the better starting point in 2026. Know Selenium well enough to maintain it; do not default to it for new work.
Interview questions
Questions you are likely to get if you list Selenium on your CV — with what interviewers are really testing for.
What is the difference between Selenium WebDriver and Selenium IDE, and when would you use each?
What they’re really testing: Whether you understand that record-and-replay is a starting point, not a professional solution, and that you have thought critically about tool choice rather than just used whatever was available.
Strong answer covers: WebDriver as the programmable API for building maintainable, code-reviewed test suites; IDE as a quick prototyping or exploratory tool only; why IDE scripts break on dynamic locators or JavaScript-heavy pages common in modern NZ SaaS products; and the maintenance cost of IDE-generated scripts at any scale.
When would you choose Selenium over Playwright for a new project, and when would you not?
What they’re really testing: Whether you can weigh real trade-offs rather than defaulting to the latest tool or blindly defending the legacy one — a signal of senior thinking.
Strong answer covers: Choosing Selenium when the team has an existing Java or C# suite (common in NZ banking like Harbour Bank or Southern Bank), when IE11 support is contractually required by a government client, or when a multi-language team needs a common framework; choosing Playwright for any greenfield modern-stack project; and explicitly saying you would not migrate a large Selenium suite to Playwright without a clear business case.
You’re contracted to a NZ insurance company running Selenium tests in Jenkins CI. Tests pass reliably on your machine but fail intermittently on the CI server — how do you investigate?
What they’re really testing: Whether you understand flakiness root causes in Selenium specifically (timing, environment, state) and can diagnose systematically rather than just re-running until it passes.
Strong answer covers: Checking for implicit waits masked by local machine speed vs. slower CI hardware; replacing any Thread.sleep() calls with explicit WebDriverWait conditions; verifying ChromeDriver version matches the Chrome version on the CI agent (a common NZ enterprise pain point when IT controls browser rollout); checking for shared test state or database fixtures not being reset between runs; and using headless mode consistently across environments.
How would you structure a Selenium test suite for a medium-sized NZ e-commerce platform with 20+ page types?
What they’re really testing: Whether you know the Page Object Model pattern and can articulate why structure matters for long-term maintainability, not just getting tests to run.
Strong answer covers: Page Object Model (POM) with one class per page encapsulating locators and actions; a base page class for shared behaviour like navigation and wait helpers; separating test data from test logic, especially important for Privacy Act compliance if the suite touches real customer records; grouping tests by functional area rather than by page; and using TestNG or JUnit 5 groups to allow selective runs in CI without re-running the full suite on every commit.
Your Selenium tests are taking 45 minutes to run in CI. What are your options for reducing that without removing coverage?
What they’re really testing: Whether you understand that speed and thoroughness are not opposites, and that you can apply engineering judgement to a real operational problem teams face daily.
Strong answer covers: Parallelising tests using TestNG parallel execution or Selenium Grid across multiple nodes; running smoke tests only on feature branches and the full suite on merge to main; replacing redundant UI tests with API-layer checks where the UI is just a thin wrapper (common on CloudBooks-style SaaS backends); switching to headless Chrome to cut browser startup overhead; and profiling which tests account for the most time before optimising — often 20% of tests consume 80% of CI time.