Before you go — grab our most downloaded resource.
QA cheat sheets used by 30,000+ testers.
🔒 No spam, ever. Join 30,000+ QA engineers. Unsubscribe anytime.
No thanks, I'll skip the free cheat sheetsDocker plus Selenium Grid turns a slow, flaky, machine-dependent suite into fast, reproducible, parallel cross-browser runs. Here is what you need to know.
"Tests pass on my machine" is the oldest excuse in QA. Docker kills it — it packages your tests and their exact dependencies into a container that runs identically everywhere. Add Selenium Grid and you run your whole suite in parallel across browsers, in CI, in minutes. Knowing this stack is a clear senior-SDET signal.
| Concept | What it means |
|---|---|
| What is Docker? | Docker packages your application + all its dependencies into a CONTAINER. The container runs the same way everywhere — your laptop, CI server, production. Analogy: Docker container = shipping container. Whatever you put inside arrives exactly as packed, regardless of the ship (server) it travels on. |
| Why Docker for SDET? | Problem: 'Tests pass on my machine but fail in CI.' Root cause: Different browser version, different OS, different Java version. Docker solution: Selenium tests run in a standardised container. Same result everywhere. No 'works on my machine' excuses. |
| Key Docker Commands | docker pull selenium/node-chrome:4 ← download Selenium Chrome image docker run -d -p 4444:4444 selenium/hub:4 ← start Selenium Hub docker ps ← list running containers docker logs container_id ← see container logs docker stop container_id ← stop container docker-compose up -d ← start all services from docker-compose.yml docker-compose down ← stop all services |
| Dockerfile for Test Project | FROM maven:3.9-eclipse-temurin-17 ← base image with Java + Maven WORKDIR /app ← set working directory COPY pom.xml . ← copy pom first (layer cache) RUN mvn dependency:go-offline -q ← download deps (cached) COPY src ./src ← copy source code CMD ["mvn", "test", "-Dsuite=regression"] ← run tests when container starts |
| Question | Answer |
| What is Docker and why do you use it for testing? | Docker packages test environment (browser, Java, OS dependencies) into a container. Tests run identically on any machine. Eliminates 'works on my machine' problems. Enables parallel browser testing on CI without installing browsers on each server. |
| What is Selenium Grid? Why use it? | Selenium Grid allows running tests on multiple machines/browsers in parallel. Hub receives test requests. Nodes run browsers. Benefits: parallel execution (faster), cross-browser testing (Chrome + Firefox + Edge simultaneously), remote execution in CI. |
| How do you run Selenium tests in Docker? | 1. Start Selenium Grid: docker-compose up (Hub + Chrome + Firefox nodes). 2. Change WebDriver to RemoteWebDriver pointing to localhost:4444. 3. Run tests via Maven or testng.xml. Tests route through Hub to available browser nodes. Grid UI at localhost:4444/ui shows active sessions. |
| What is the difference between docker run and docker-compose? | docker run: Start a single container. Manual. Good for one-off containers. docker-compose: Start multiple containers together from a YAML file. Manages networking between containers (Hub + Chrome nodes need to talk to each other). Use compose for Selenium Grid. |
| How do you ensure tests run the same in CI as locally? | Use the same Docker image in CI as locally. GitHub Actions example: 'runs-on: ubuntu-latest + docker-compose up + mvn test + docker-compose down' Same container = same browser version = same environment = reproducible results. |
The standard setup is a hub plus browser nodes, brought up with Docker Compose. Your tests point at the hub, which distributes them across the nodes in parallel:
In an interview, the key points are: containers give reproducible environments, Grid gives parallel cross-browser execution, and Compose brings the whole grid up with one command in CI. That combination cuts a suite that took an hour down to minutes.
Grid execution is a framework and CI concern.
Selenium Simulator → Jenkins / CI SimulatorDocker packages tests and their exact dependencies into a container that runs identically on any machine, eliminating "works on my machine" and making CI runs reproducible.
A hub-and-node setup that distributes your tests across multiple browsers and machines in parallel, so a large suite finishes in a fraction of the time.
You run the Grid hub and browser nodes as containers (often via Docker Compose), point your tests at the hub, and it parallelises them across the nodes — reproducible and fast.
For mid-to-senior roles increasingly yes. Even a working understanding of containers plus a dockerised Grid is a strong differentiator.
Selenium images and flags change across versions — check the official selenium/docker images for current tags.