Cross-browser testing questions come up in almost every QA automation interview. Here are the most commonly asked ones — with answers that show real experience, not textbook theory.
Q: How do you handle cross-browser testing in your framework?
A: We use a WebDriver Factory pattern that creates the appropriate browser based on a TestNG parameter. Our testng-crossbrowser.xml has separate <test> blocks for Chrome, Firefox, and Edge with parallel="tests" so all three run simultaneously. ThreadLocal<WebDriver> ensures thread safety. For local development, we use Docker Selenium Grid (one docker-compose command). For CI, we run headless Chrome on Grid for speed, plus BrowserStack for Safari and mobile device testing. Tests are tagged with groups — "cross-browser" group runs on all browsers, "regression" runs on Chrome only.
Q: What is the difference between RemoteWebDriver and ChromeDriver?
A: ChromeDriver runs Chrome on the local machine — it communicates directly with the Chrome browser installed locally. RemoteWebDriver connects to a remote server (Selenium Grid Hub or cloud platform like BrowserStack) over HTTP and executes tests on a browser running on that remote machine. The test code stays identical — only the driver initialization changes. This is why the WebDriver Factory pattern is so powerful: switch between local and remote with one configuration change.
Q: What is Selenium Grid 4 architecture?
A: Grid 4 has five components: Router (receives test requests), Distributor (assigns requests to available nodes), Session Map (tracks active sessions), Node (runs the actual browser), and Event Bus (internal messaging). In practice, you can run it in Standalone mode (all components on one machine) or Distributed mode (separate Hub and Nodes). For Docker setups, the Hub image includes Router, Distributor, Session Map, and Event Bus. Node images include the browser and its driver.
Q: How do you handle a test that fails on one browser but passes on others?
A: First, I check if it's a timing issue — I increase the explicit wait. If that doesn't help, I open the page in that browser's DevTools and compare the element's CSS rendering with Chrome. Common fixes: JavaScript click fallback for ElementClickInterceptedException, Actions class for sendKeys issues on Firefox, explicit alert waits for Safari. I log the browser name and version in Allure reports and capture screenshots on failure. The CrossBrowserUtils class centralizes all browser-specific workarounds. If the fix is browser-specific, I detect the browser at runtime using RemoteWebDriver.getCapabilities().
Q: Why is ThreadLocal needed for parallel execution?
A: When TestNG runs tests in parallel, each test runs in a separate thread. If you store WebDriver in a regular instance variable, all threads share the same variable. Thread 1 might quit the driver while Thread 2 is still using it — NullPointerException. ThreadLocal gives each thread its own isolated copy of the WebDriver. Thread 1 has its Chrome driver, Thread 2 has its Firefox driver, and they never interfere. Without ThreadLocal, parallel cross-browser testing is impossible. Always call threadLocal.remove() in teardown to prevent memory leaks.
Q: What is headless testing and when do you use it?
A: Headless mode runs the browser without a visible UI. We use --headless=new (Chrome 112+) which uses the same rendering engine as regular Chrome, so test behavior is identical. We use headless in CI/CD pipelines where there's no monitor, and in Docker containers where memory is limited. It's 2-3x faster than headed mode. We always set --window-size=1920,1080 in headless mode because the default size is tiny and elements can be off-screen. For local debugging, we use headed mode. We make this configurable via a system property — same test, different mode.
Q: How do you decide which tests to run on which browsers?
A: We use a priority matrix. Critical flows (login, checkout, payment) run on all browsers. Regression suite runs on Chrome and Firefox. API-driven tests run on Chrome only — API calls don't depend on browser rendering. UI layout tests run on Chrome and Safari — Safari has the most CSS differences. We check analytics to see which browsers our users actually use and prioritize accordingly. Tests are tagged with TestNG groups: "cross-browser" runs on all, "regression" runs on Chrome, "smoke" runs on all. This gives us 90% cross-browser coverage with 40% of the execution cost.
Q: Have you used BrowserStack? How do you integrate it?
A: Yes. We use BrowserStack for Safari testing (can't install Safari on Linux CI) and real mobile device testing. Integration uses RemoteWebDriver with bstack:options capabilities — OS, browser version, project name, build name. Credentials come from environment variables, never hardcoded. For testing staging apps on localhost, we use BrowserStack Local tunnel. We enable debug mode for video recordings and network logs. The code change is minimal — same RemoteWebDriver, different URL (hub-cloud.browserstack.com), different capability keys. Switching between Grid and BrowserStack is a configuration change, not a code change.
| Question | One-Line Answer |
|---|---|
| Default Grid port? | 4444 |
| Grid dashboard URL? | http://localhost:4444/ui |
| Chrome headless flag? | --headless=new (Chrome 112+) |
| BrowserStack capability key? | bstack:options |
| LambdaTest capability key? | LT:Options |
| Why shm_size in Docker? | Chrome needs shared memory for rendering — without it, it crashes |
| ThreadLocal vs regular field? | ThreadLocal isolates WebDriver per thread — required for parallel runs |
| Safari engine? | WebKit |
| Firefox engine? | Gecko |
| Chrome engine? | Blink |
Key Point: Know these patterns cold: WebDriver Factory, ThreadLocal for parallel, RemoteWebDriver for Grid/cloud, --headless=new for CI, bstack:options for BrowserStack. These cover 90% of cross-browser interview questions.
Key Point: Cross-browser testing is asked in every QA interview. Know the WebDriver Factory, ThreadLocal, Grid architecture, and headless mode patterns.
Answer all 5 questions, then submit to see your score.
1. What is the purpose of Selenium Grid?
2. Why is ThreadLocal<WebDriver> required for parallel cross-browser testing?
3. Which Chrome headless flag should you use for Chrome 112 and later?
4. What does the shm_size setting do in Docker Selenium Grid configuration?
5. Which browsers share the same rendering engine (Blink)?