Selenium Grid &amp; Docker Interview Questions for Automation Testing

Show answer

ChromeDriver starts and controls a browser on the same machine as the test. RemoteWebDriver sends the same WebDriver commands over HTTP to a remote endpoint, such as a Selenium Grid, a Docker container or a cloud provider, which starts the browser elsewhere. You pass the Grid URL and browser options, and the rest of the test code stays the same. ChromeDriver itself actually extends RemoteWebDriver.

What is the difference between a Docker image and a container?

Show answer

An image is a read-only template that contains an operating system layer, software and configuration, for example selenium/standalone-chrome with Chrome and ChromeDriver installed. A container is a running instance of an image with its own process, network and writable layer. You can start many containers from one image and destroy them after a test run. This is why every run starts from the same clean browser environment.

What is Docker Compose and why is it useful for Selenium Grid?

Show answer

Docker Compose lets you define several containers, their images, ports, environment variables and networks in one docker-compose.yml file and start them together with docker compose up. For Selenium it means a hub plus Chrome, Firefox and Edge nodes, and even the application under test, start with one command on any laptop or CI agent. The file is version-controlled, so every tester and pipeline uses the same Grid setup.

How do you watch a test running inside a Docker Selenium container?

Show answer

The selenium node and standalone images include a VNC server and noVNC. Expose port 7900 and open http://localhost:7900 in a browser; the default password is secret, or set SE_VNC_NO_PASSWORD to skip it. You can also open the Grid UI on port 4444 and click the session's video icon. This is very useful for debugging tests that fail only inside the container, such as layout or focus problems.

Write Java code to create a RemoteWebDriver for a Selenium Grid using ChromeOptions.

Show answer

String gridUrl = System.getProperty("grid.url", "http://localhost:4444"); ChromeOptions options = new ChromeOptions(); options.addArguments("--window-size=1920,1080"); options.setCapability("se:name", "Login smoke test"); WebDriver driver = new RemoteWebDriver(new URL(gridUrl), options); try { driver.get("https://app.test/login"); } finally { driver.quit(); }

How do you check that the Grid is ready before starting the tests in CI?

Show answer

Poll the Grid status endpoint, http://hub:4444/status, until the JSON field value.ready is true, which means at least one node has registered. In a shell step you can loop with curl and jq, for example until curl -s http://localhost:4444/status | jq -e '.value.ready'; do sleep 2; done, with an overall timeout. In Compose you can add a healthcheck on the hub. Without this, the first tests fail while nodes are still starting.

How do you increase the number of Chrome nodes with Docker Compose?

Show answer

Use the scale option: docker compose up -d --scale chrome=4 starts four Chrome node containers from the same service definition, and each registers with the hub. Do not fix container names or host ports on a scaled service, or the extra containers will clash. Check the Grid UI on port 4444 to confirm the slots. Make sure the host has enough CPU and memory, roughly one CPU core and 1 to 2 GB per browser.

How do you start a standalone Chrome container and run your tests against it?

Show answer

Run docker run -d -p 4444:4444 -p 7900:7900 --shm-size=2g selenium/standalone-chrome:latest, preferably with a pinned version tag instead of latest. It starts a mini Grid with one Chrome node. Point RemoteWebDriver to http://localhost:4444 with ChromeOptions and the tests run inside the container. Port 7900 lets you watch through noVNC. Stop it with docker stop when finished, or use --rm so it is removed automatically.

You configured 50 parallel threads but only 8 tests run at a time on the Grid. Why?

Show answer

The Grid only has 8 free slots, so the other requests wait in the New Session Queue. Total parallelism equals nodes multiplied by max sessions per node, not the TestNG thread count. Check the Grid UI for slot count. To run more, scale the node containers, raise max sessions if hardware allows, or use a larger grid. Otherwise reduce threads to match slots so waiting requests do not time out.

What are the standalone, hub and node, and distributed modes of Selenium Grid 4?

Show answer

Standalone runs every Grid component and a local node in a single process, which suits a laptop or a single container. Hub and node mode runs the router, distributor, queue and session map together as the hub, with separate node processes registering to it, which is the usual team setup. Fully distributed mode runs each component separately, often on Kubernetes, for very large grids that need independent scaling and high availability.

Why do Selenium browser containers need a larger shm_size?

Show answer

Chrome and Firefox use shared memory at /dev/shm for rendering and inter-process communication. Docker gives containers only 64 MB of shared memory by default, which is not enough for modern pages, so the browser tab crashes with errors like session deleted because of page crash. Setting shm_size to 2g in Compose, or --shm-size=2g with docker run, fixes it. Mounting /dev/shm from the host is an alternative.

What does SE_NODE_MAX_SESSIONS control in the Docker Selenium images?

Show answer

It sets how many browser sessions a node container can run at once. The default is one, which gives the best isolation and stability. Increasing it lets one container run several browsers in parallel, but you must also set SE_NODE_OVERRIDE_MAX_SESSIONS to true and give the container enough CPU, memory and shared memory. Many teams keep one session per container and scale the number of containers instead.

How do you get reports, screenshots and downloaded files out of a Docker container?

Show answer

Use volumes. A bind mount maps a host folder into the container, for example -v $(pwd)/target:/app/target, so reports written in the container appear on the CI agent for archiving. Named volumes are managed by Docker and suit data that should survive restarts. For browser downloads, mount the node's download folder or enable the Grid's managed downloads with the se:downloadsEnabled capability to fetch files through the Grid API.

Describe a time you convinced your team to run tests in Docker.

Show answer

Situation: our tests behaved differently on each tester's laptop and on Jenkins because of browser and driver versions. Task: make results consistent. Action: I built a small demo with Docker Compose running the Grid and the app, showed identical results on three machines and on CI, and wrote a one-page setup guide. Result: the team adopted it within two sprints, works-on-my-machine failures almost disappeared and new joiners were productive on day one.

Write a docker-compose.yml that runs a Selenium hub with Chrome and Firefox nodes.

Show answer

services: selenium-hub: image: selenium/hub:4.25.0 ports: - "4442:4442" - "4443:4443" - "4444:4444" chrome: image: selenium/node-chrome:4.25.0 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443 firefox: image: selenium/node-firefox:4.25.0 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

Write a Dockerfile that runs a Maven and TestNG test suite.

Show answer

FROM maven:3.9-eclipse-temurin-21 WORKDIR /app # cache dependencies first for faster rebuilds COPY pom.xml . RUN mvn -q dependency:go-offline COPY src ./src COPY testng.xml . ENV GRID_URL=http://selenium-hub:4444 CMD ["sh", "-c", "mvn test -Dgrid.url=$GRID_URL -Dsurefire.suiteXmlFiles=testng.xml"]

How do you record videos of tests running on a Docker Selenium Grid?

Show answer

Add the selenium/video image as a sidecar container next to each node, sharing the node's display through DISPLAY_CONTAINER_NAME, and mount a folder for the mp4 files. Newer Grid versions also support recording per session by setting the se:recordVideo capability with Dynamic Grid. Name videos with se:name so they match test names. Keep videos only for failed tests or for a few days, because they use a lot of disk space.

Tests on the Grid fail with SessionNotCreatedException saying the new session request timed out. What do you check?

Show answer

It means no matching free slot appeared in time. Check the Grid UI to see whether nodes are registered and whether their capabilities match the request, such as browser name, version or platform. Compare the test thread count with total slots, since extra threads just wait in the queue. Look for stuck sessions holding slots after aborted builds. Then increase capacity, reduce threads, or raise the session request timeout.

Chrome inside a Docker node keeps crashing with session deleted because of page crash. How do you fix it?

Show answer

This is almost always shared memory exhaustion, because Docker's default /dev/shm of 64 MB is too small for Chrome. Set shm_size: 2gb in Compose or --shm-size=2g in docker run. Also check the container's memory limit and the number of sessions per node, since several browsers in one container multiply memory use. Heavy pages or memory leaks in long sessions can also crash tabs, so restart sessions between test classes.

File upload tests pass locally but fail when they run on a remote Grid. Why?

Show answer

sendKeys with a file path sends a path that exists on your test machine, but the browser runs on the remote node where that path does not exist. Set a LocalFileDetector on the RemoteWebDriver, using ((RemoteWebDriver) driver).setFileDetector(new LocalFileDetector()), so Selenium zips and transfers the file to the node first. Alternatively mount the test data folder into the node container. Always use absolute paths.

After aborted Jenkins builds, Grid slots stay busy and new tests wait. How do you handle it?

Show answer

When a build is killed, driver.quit() never runs, so sessions stay open until the node notices. Set a sensible session timeout on nodes, such as SE_NODE_SESSION_TIMEOUT of 300 seconds, so idle sessions are cleaned up. Always call quit in an @AfterMethod with alwaysRun or a finally block. In CI, bring the Compose Grid up per build and tear it down in a post always step, so each build gets a fresh Grid.

Tests running inside Docker cannot reach the application running on the host's localhost. Why, and how do you fix it?

Show answer

Inside a container, localhost means the container itself, not the host machine. On Docker Desktop use host.docker.internal as the host name. On Linux add extra_hosts with host.docker.internal:host-gateway, or use the host's IP. A cleaner option is running the application in the same Compose network and calling it by its service name, such as http://web:8080. Make sure the app listens on 0.0.0.0, not only 127.0.0.1.

Tell me about a time you set up test infrastructure that other teams started using.

Show answer

Situation: three product teams each kept their own unstable Grid VMs. Task: provide one reliable shared Grid. Action: I set up a Docker-based Grid with pinned images, health checks, video for failures and a short onboarding guide, then ran a pilot with one team and fixed their issues before opening it up. Result: all three teams moved within a quarter, VM costs dropped and Grid-related failures fell sharply.

What are the main components of Selenium Grid 4?

Show answer

Grid 4 is split into the Router, which receives all requests, the Distributor, which assigns new sessions to nodes, the Session Map, which records which node owns each session, the New Session Queue, which holds requests waiting for a free slot, the Event Bus, which lets components communicate, and Nodes, which run the browsers. In standalone or hub mode these run in one process, but they can also be deployed separately to scale.

What is the New Session Queue in Selenium Grid 4 and what happens when all slots are busy?

Show answer

When a test requests a session and no node slot matches, the request waits in the New Session Queue instead of failing immediately. The distributor picks it up when a matching slot frees. If it waits longer than the session request timeout, which is 300 seconds by default, the client gets a SessionNotCreatedException. Tuning this timeout and matching thread count to slot count prevents long waits and timeouts in CI.

How does Selenium Grid decide which node gets a new session?

Show answer

Each node advertises slots with stereotypes, which are capability sets like browserName chrome, a browser version and platformName linux. The distributor compares the requested capabilities with those stereotypes and picks a free matching slot, preferring nodes with lower load. If nothing matches, the request stays in the queue until timeout. Custom capabilities in the stereotype let you route tests to special nodes, such as nodes with a particular extension.

What is Dynamic Grid in Selenium 4?

Show answer

In Dynamic Grid the node does not run browsers itself. It is configured with a Docker socket and a list of browser images, and for each new session it starts a fresh browser container, runs the test and then removes the container. Every test gets a clean browser, and capacity grows without pre-starting many nodes. It can also record video per session. The trade-off is container start-up time for each session.

How does running Selenium Grid on Kubernetes with autoscaling differ from Docker Compose?

Show answer

Docker Compose runs a fixed number of nodes on one machine, which is simple but limited to that host's CPU and memory. On Kubernetes, typically installed with the Selenium Helm chart, nodes are pods spread across a cluster, and KEDA can scale node pods up based on the queue length and back to zero when idle. It suits large teams with bursty CI demand but needs cluster knowledge and monitoring.

Your UI tests run noticeably slower on the Grid than on your laptop. How do you find the cause?

Show answer

Every command now travels over the network, so chatty code with many findElement calls or getText in loops suffers most. Check latency between test runner and Grid, ideally keeping them in the same network or region. Check node resources: overloaded CPU or many sessions per container slow browsers. Video recording and VNC add overhead. Reduce round trips by batching checks, using JavaScript for bulk reads and avoiding implicit waits combined with explicit ones.

You need 2,000 UI tests to run on every pull request in under 20 minutes. How would you design the infrastructure?