Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Selenium is a family of open-source tools and libraries for automating web browsers in software tests. Use WebDriver when you need maintainable, coded tests; Selenium IDE when you want to record and replay interactions; and Selenium Grid when those tests must run remotely or in parallel across browser and operating-system combinations. Selenium does not replace your test framework or assertions: it supplies browser control that your language, runner, and reporting stack use.

What is Selenium in software testing?

The Selenium Project describes Selenium as “an umbrella project for a range of tools and libraries that enable and support the automation of web browsers.” In practice, a test sends commands such as navigating to a URL, finding an element, entering text, clicking, and checking the resulting page. The browser executes those commands as a real user-facing browser would, allowing end-to-end checks of web applications.

Selenium is not one standalone test runner. You normally combine a Selenium language binding with a test framework (for example, a unit-test framework in your chosen language), assertions, test data, and a CI system. The project’s documentation is the authoritative place to check current APIs and setup details.

Which Selenium component should you use?

Need Component What it does Main trade-off
Maintainable, coded browser tests WebDriver Programmatic, language-specific bindings control a browser. Requires coding, selectors, waits, and test maintenance.
Quickly record or replay an interaction Selenium IDE Browser extension records actions and replays them. Useful for exploration and simple checks, but recorded flows usually need cleanup before becoming a large maintained suite.
Remote or parallel execution Grid Routes WebDriver sessions to machines and environments. You must plan machines, browser/OS combinations, concurrency, and resources.

WebDriver for coded tests

WebDriver is a language-neutral API and protocol. Your language binding turns calls such as driver.get() or find_element into protocol commands. A browser-specific driver implementation communicates with the browser and returns its result. WebDriver is a W3C Recommendation; consult the project’s WebDriver documentation and your browser’s support page because capabilities and behavior can differ by browser and version.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Selenium IDE for recording

IDE is a practical starting point when you need to capture a browser interaction quickly or explore a new workflow. Treat a recording as a draft: replace fragile selectors, add explicit checks, and decide how test data and cleanup will work before relying on it for regression coverage. IDE’s command-line runner can send tests to a Grid; its documentation names hosted services such as Sauce Labs as an example, but provider features and terms must be verified current.

Grid for distributed execution

Grid is the distribution layer. A test requests a session with capabilities such as browser and platform; Grid places it on a suitable node. Use it when a local browser cannot represent your target environments, when a team needs a shared remote browser farm, or when parallel sessions reduce overall pipeline time. Grid does not remove the need to budget CPU, RAM, browsers, network access, and test isolation.

How Selenium WebDriver works

  1. Your test code calls a language binding.
  2. The binding sends a W3C WebDriver command to a local driver or a remote Grid endpoint.
  3. The browser-specific driver translates the command for its browser and communicates with the browser.
  4. The browser performs the action and returns a response, element state, or error.
  5. Your test framework evaluates assertions and records the result.

WebDriver BiDi is an evolving bidirectional W3C standard developed with browser vendors. It adds a WebSocket connection so automation can react to browser events as well as issue commands. Do not assume identical BiDi coverage in every browser; check the current browser-specific support pages at Selenium’s BiDi documentation.

What you need to install

  • A supported browser (Chrome, Edge, Firefox, Safari, or another browser covered by Selenium’s current support documentation).
  • A language binding for Java, Python, C#, Ruby, JavaScript, or another supported language.
  • A test framework and assertion library appropriate to that language.
  • A matching browser-driver setup. Selenium Manager can automate driver management in supported Selenium paths; otherwise install and maintain the driver required by your browser.
  • Network access to the application under test, plus test accounts and stable test data.

Use the browser-specific sections for Chrome, Edge, Firefox, Internet Explorer, and Safari rather than assuming one capability matrix applies everywhere. Pin browser and binding versions in CI when reproducibility matters, and update them deliberately.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A minimal Python WebDriver test

Install the binding with pip install selenium. With a supported browser installed, Selenium Manager will commonly resolve the driver automatically.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

URL = "https://example.com"
driver = webdriver.Chrome()
try:
    driver.get(URL)
    heading = WebDriverWait(driver, 10).until(
        EC.visibility_of_element_located((By.TAG_NAME, "h1"))
    )
    assert heading.text == "Example Domain"
finally:
    driver.quit()

The try/finally block closes the session even after a failure. Prefer stable attributes such as a dedicated test ID over long XPath expressions. Wait for a meaningful state, not an arbitrary sleep: explicit waits reduce races caused by asynchronous rendering.

Reliable test design

Use deterministic locators

Agree with developers on stable IDs or data-testid attributes. Keep selectors short and specific. A locator that depends on visual text, generated class names, or DOM position is more likely to break during harmless UI changes.

Wait for state transitions

Wait for visibility, clickability, URL changes, an enabled control, or a completion indicator. Avoid mixing implicit and explicit waits without understanding the resulting timeout behavior. Set timeouts based on your application and CI environment, not an arbitrary global number.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Isolate data and sessions

Create or reset test data per test where possible. Quit every driver, clear authentication deliberately, and avoid tests that depend on execution order. Parallel sessions must not share accounts or mutable records unless the test explicitly coordinates access.

Capture diagnostics

On failure, retain the exception, browser and driver versions, URL, console or server logs where available, and a screenshot or page source. This distinguishes an application defect from a stale element, navigation timeout, browser mismatch, or infrastructure failure.

When should you use Selenium Grid?

Choose Grid when you need combinations such as multiple browsers and operating systems, remote execution from CI, or several independent sessions at once. Define the matrix first: browsers, versions, operating systems, screen sizes, locales, and the number of concurrent sessions. Then decide whether to run a standalone server, a distributed deployment, or a hosted Grid.

Selenium’s Grid guide estimates around 1 GB of RAM per browser session as a planning figure. It is not a universal requirement: pages with heavy JavaScript, video, large documents, or developer tools can consume more, while a lightweight page may consume less. Capacity also depends on CPU, disk, network, machine count, and session duration. Load-test your own workload before setting concurrency limits.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Grid planning checklist

  • List the browser/OS combinations that your users actually require.
  • Set a maximum parallel-session count and reserve headroom for the operating system and Grid services.
  • Use isolated profiles and clean session state for each test.
  • Monitor queue time, session failures, CPU, RAM, disk, and network saturation.
  • Ensure nodes can reach the application, identity provider, APIs, and required test fixtures.
  • Retry only infrastructure failures; never hide deterministic assertion failures with blind retries.

Common Selenium failures and fixes

Symptom Likely cause Fix
Session not created or driver mismatch Browser and driver versions or capabilities are incompatible. Update the binding/driver path, allow Selenium Manager to resolve a compatible driver, and consult the browser-specific support page.
Element not found Wrong locator, iframe, shadow DOM, or element not yet present. Verify the DOM, switch to the correct frame or shadow root, use a stable locator, and wait for the required state.
Stale element reference The page re-rendered after the element was located. Locate the element again after the state change; do not retain references across renders.
Element click intercepted Overlay, cookie banner, animation, or another element covers the target. Wait for the overlay to disappear, handle the consent flow, scroll appropriately, and verify the target is clickable.
Timeout or blank page Slow application, blocked network, DNS issue, overloaded node, or an application error. Check URL and server logs, test connectivity from the node, capture page source, and tune waits only after identifying the bottleneck.
Works locally but fails in CI Different browser version, viewport, timezone, fonts, permissions, or resource limits. Record environment details, reproduce in the same container or node image, and make test data and waits deterministic.

Performance, reliability, and cost considerations

Selenium itself does not establish a universal speed or cost advantage. Runtime is driven by browser startup, page weight, application latency, waits, test data, and parallel capacity. Reuse a session only when isolation remains safe; otherwise the cleanup cost is preferable to cross-test contamination. Run a small smoke set on every change and broader browser matrices on a schedule or release gate.

Local execution avoids remote infrastructure but covers fewer environments. Grid and hosted execution add network and infrastructure dependencies while enabling coverage and concurrency. Budget for browser images, node maintenance, observability, credentials, and quarantining genuinely flaky tests. Keep screenshots and logs private when pages contain personal or proprietary data.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Or skip the browser setup

If your goal is a clean image or PDF of a page rather than an interactive assertion, ScreenshotNeo is a simpler website screenshot API. A single request can return PNG, JPEG, WebP, or PDF:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo documentation for options. It accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be disabled. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. It also provides an MCP server with take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

FAQ

Is Selenium a programming language?

No. Selenium provides browser-automation tools and language bindings; you write tests in a supported programming language.

Can Selenium test mobile apps?

This article concerns browser automation. Native and hybrid mobile-app automation requires a separate mobile automation solution; do not assume desktop WebDriver commands provide native-app coverage.

Does Selenium test APIs?

Selenium drives browsers. Use an API client or test framework for direct HTTP/API tests, then reserve Selenium for user-visible integration paths.

Is Selenium IDE enough for a large regression suite?

It can help explore and record flows, but a large suite generally benefits from coded WebDriver tests with explicit data, waits, assertions, and version control.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.