What Is Selenium and Its Components — WebDriver, Grid, IDE

Selenium is the oldest, most widely used browser automation framework on earth. It was created in 2004, predates jQuery, predates Node.js, and has powered enterprise QA teams for two decades. If you list "Selenium + Java" on your CV, recruiters in every market still recognise it instantly — it remains the single most-requested automation skill in the Java QA world. This lesson is the orientation: what the framework actually consists of, how each piece fits together, and why you'll spend the rest of this course inside one of those pieces — WebDriver.

The four components

When someone says "Selenium," they could mean any of four things. Knowing which is which prevents an embarrassing amount of confusion in your first job:

• Selenium WebDriver — the core library you'll import in Java code. Sends commands to browsers via the W3C WebDriver protocol. This is what you'll use every single day.
• Selenium Grid — a server that lets you run WebDriver tests on remote machines and across many browser/OS combinations in parallel. Covered in chapter 7.
• Selenium IDE — a Chrome/Firefox extension that records your clicks and replays them. Useful for prototyping and for non-developers; not what production suites are built from.
• Selenium Manager — new in Selenium 4.6+. A small built-in helper that resolves the right driver binary for your installed browser automatically. No more downloading chromedriver.exe by hand.

Notice that only one of these — WebDriver — is a Java library. The others are tools that orbit around it.

How WebDriver actually drives a browser

Every Selenium test, no matter how complex, follows the same chain:

1. Your Java code calls something like driver.findElement(By.id("email")).sendKeys("alice@test.com").
2. The Selenium client library turns that call into an HTTP request following the W3C WebDriver protocol.
3. A browser-specific driver binary (ChromeDriver for Chrome, GeckoDriver for Firefox, msedgedriver for Edge) receives that request on a local port.
4. The driver translates the WebDriver command into the browser's native automation interface, the browser performs the action, and the result travels back up the chain.

WebDriver driver = new ChromeDriver();
driver.get("https://qa.codes");                   // step 1: Java method call
driver.findElement(By.id("search")).sendKeys("Selenium"); // travels through HTTP → ChromeDriver → Chrome
String title = driver.getTitle();                  // command + response, end to end
driver.quit();

The extra hop through HTTP is what people mean when they call Selenium "slower than Cypress or Playwright." Cypress runs inside the browser, and Playwright talks to browsers via the Chrome DevTools Protocol with a single persistent connection. Selenium adds a binary translator in the middle. In practice, on modern hardware, that overhead is small — usually 10–50 ms per command. It rarely matters unless you're running thousands of micro-actions back to back.

Selenium vs Playwright vs Cypress

If you're coming from Cypress or Playwright, here's how Selenium lines up against them:

The honest summary: Selenium is the safest bet if you want maximum employability in Java-centric organisations (banks, insurance, telecoms, consulting firms). Playwright is the modern challenger and what you'd reach for on a greenfield TypeScript project. Cypress is fantastic for component-level and frontend-team-owned tests but is not the default for backend-heavy enterprise QA.

Why Selenium is still relevant in 2026

It would be easy to write Selenium off as "the old one" and move on. People have been predicting its replacement for a decade. They keep being wrong, for three reasons:

1. The job market. Search any job board for "QA engineer Java" — you'll see "Selenium" in the requirements far more often than "Playwright." Big enterprises don't rewrite working test suites; they extend them. Suites started in 2014 are still running today.
2. Language coverage. Playwright supports four languages; Cypress supports one. Selenium supports almost every language a real QA team uses. When your backend is in Java, Python is on the data team, C# is in the legacy services group, and you want one framework everyone can read — Selenium is that framework.
3. Selenium 4 modernised it. Relative locators, native Chrome DevTools Protocol support, much improved Grid, and Selenium Manager (automatic driver setup). The 2026 version of Selenium is materially nicer to use than the 2018 version.

What the rest of this course assumes

We assume you've worked through Core Java for QA — classes, methods, collections, exception handling, and the Maven mindset. We don't re-explain those. We do explain every Selenium concept from scratch, every TestNG annotation as we use it, and every design decision the framework asks you to make.

By the end of chapter 1 you'll have a Maven project running real tests. By the end of the course you'll have a complete framework — Page Object Model, data-driven tests, parallel execution, CI pipelines — for a flight booking application.

Reference the Selenium tool entry on qa.codes for the cheat-sheet view of every method we'll cover, and bookmark it. You'll come back.

⚠️ Common mistakes

• Confusing Selenium IDE with Selenium WebDriver. They share a name; that's about it. IDE is a record-and-playback browser extension whose exported scripts are rough scaffolding at best. Production tests are written in code with WebDriver. If a tutorial tells you to record-then-export, you're not learning what most teams actually do.
• Believing that Cypress or Playwright "have replaced" Selenium. They have not. They're alternatives that fit certain projects better. The job market is the lagging indicator that proves it: even teams that adopt Playwright today often have a Selenium suite they keep maintaining. Both skills coexist.
• Skipping the architecture mental model. "It's just driver.findElement — why do I care about WebDriver protocol?" Because when something fails (SessionNotCreatedException, ChromeDriver version mismatch, network timeouts to the driver), the architecture is the map that tells you where to look. Spend ten minutes on it now or two hours debugging later.

🎯 Practice task

This lesson is theory; the next is hands-on. Before moving on, prove you can frame Selenium correctly. 10 minutes.

1. Open the Selenium tool entry on qa.codes and skim the page. Note which sections refer to WebDriver (the library) and which refer to Grid (the server).
2. Open Chrome and visit chrome://version. Write down the major version (e.g., 131). This is the Chrome version you'll use in lesson 2 — Selenium needs a matching ChromeDriver, and WebDriverManager (or Selenium Manager) will resolve it for you.
3. Write a one-paragraph answer in your notes to: "My team is starting a fresh test suite for a Java + Spring Boot backend with a React frontend. We need cross-browser coverage across Chrome, Firefox, and Edge, and the company already runs Jenkins. Should we pick Selenium, Playwright, or Cypress, and why?" Force yourself to commit to an answer; the goal is having an opinion you can defend.
4. Stretch: look at one job description on LinkedIn for a "QA Automation Engineer" role in your country. Count how many of these the job mentions: Selenium, TestNG/JUnit, Maven, Jenkins, Java. The pattern you'll see is what this course prepares you for.

Next lesson: scaffold the Maven project, wire the dependencies, and run mvn clean test against an empty suite — the foundation everything else sits on.