Automation Testing Interview Questions and Answers (1970)

Automation testing uses scripts and tools to execute predefined test cases, compare actual and expected results, and report outcomes without human intervention during execution. Best fit: regression, smoke, data-driven, and load testing. Not a full replacement for exploratory or usability testing.

Faster feedback (minutes vs days), higher reliability, 24/7 execution, parallel runs across browsers/devices, better coverage on repetitive tests, precise performance metrics, and long-term cost savings once stable.

Automate: regression, smoke, data-driven, load, cross-browser, API contract, and integration. Don't automate: one-off tests, unstable features, UX/look-and-feel, ad-hoc exploratory, tests where expected result is subjective.

Mike Cohn's test pyramid: broad base of fast unit tests (70%), middle layer of integration/API tests (20%), thin top of slow E2E UI tests (10%). Inverting it ("ice-cream cone") creates a slow, flaky suite that fails in CI.

ROI = (Manual hours saved × Rate per hour × Cycles) − (Build cost + Maintenance cost). Break-even for a well-designed suite is usually 5–10 regression cycles. Calculate per-suite; don't average across the whole product.

A tool is software that drives execution (Selenium WebDriver, Playwright). A framework is a structured set of guidelines, utilities, patterns, and conventions built on top of tools — Page Object Model, config management, data providers, reporting, CI hooks.

A test harness is the collection of stubs, drivers, test data, and configuration files that surround the code under test and let tests run in isolation. Common in unit testing (e.g., JUnit runner + Mockito + fixtures = harness).

Assertion (hard assert) stops the test on failure. Verification (soft assert) logs the failure and continues, so a single run reports every problem instead of stopping at the first. TestNG SoftAssert and Playwright expect.soft() enable this.

POM is a design pattern where each web page/component has a class that exposes methods (login, addToCart) and hides locators. Benefits: DRY, easy maintenance when UI changes, readable tests, reusable across suites. Modern variant: Page Component Model.

A data-driven framework separates test data from test logic — data lives in Excel, CSV, JSON, or a database and the same test runs for every row. TestNG @DataProvider, JUnit @ParameterizedTest, or Playwright's test.each() handle this.

A keyword-driven framework encodes actions as keywords (Login, ClickButton, AssertText) in a spreadsheet or file; non-technical testers author scripts by chaining keywords. Popular via Robot Framework and legacy QTP/UFT.

A hybrid framework combines data-driven, keyword-driven, and POM patterns — most enterprise Java/TestNG suites in production. Data lives in external files, business keywords wrap POM methods, and reporting is centralized (Allure/ExtentReports).

BDD is a collaboration technique where features are described as executable scenarios in Given-When-Then (Gherkin) — readable by PO, dev, QA. Cucumber (Java/JS), SpecFlow (.NET), and Behave (Python) execute the scenarios against step definitions.

Six pillars: (1) clear folder structure, (2) config-driven environments, (3) POM or component abstraction, (4) reusable test data providers, (5) reporting + screenshots + video on failure, (6) CI/CD integration with parallel execution and retry logic.

Common patterns: Page Object, Singleton (WebDriver instance), Factory (browser factory), Fluent Interface (builder-style API), Strategy (test data source), and Facade (business flow wrapper on top of POM).

Externalize into environment files (config.dev.json, config.qa.json, config.prod.json) or use env vars. Load at runtime based on a system property (-Denv=qa). Never hardcode URLs, credentials, or API keys in the framework or test code.

Selenium is an open-source browser automation suite: WebDriver (language bindings that drive the browser via native APIs), Grid (parallel + remote execution), IDE (record/replay for prototyping). Selenium 4 added relative locators, CDP access, and Grid 4 with Docker-native scaling.

Playwright is Microsoft's modern browser automation framework (TypeScript, JS, Python, .NET, Java) with auto-waiting, network interception, trace viewer, parallel execution, and built-in test runner. Faster and less flaky than Selenium for modern SPAs.

Cypress is a JavaScript-only E2E framework that runs inside the browser (not via WebDriver). Faster, better DX, time-travel debugging, but limited to Chromium-family + Firefox and single-domain tests. Selenium/Playwright win on cross-language and multi-tab support.

Selenium: enterprise Java, Grid at scale, widest job market. Playwright: modern TypeScript/Python stacks, best flakiness profile, cross-browser + mobile web. Cypress: JS-only teams needing best DX for front-end regression. Pick based on stack, hiring pipeline, and existing infra.

Locators identify elements on a page. Order of preference: (1) data-testid or id (stable), (2) accessibility role + name, (3) CSS selector, (4) XPath (only when nothing else works). Avoid absolute XPath and text-based locators for i18n apps.

Implicit wait — global polling for element presence; set once per driver. Explicit wait (WebDriverWait + ExpectedCondition) — waits for a specific condition. Fluent wait — explicit wait with custom polling interval and ignored exceptions. Never mix implicit and explicit (unpredictable timing).

Playwright automatically waits for elements to be attached, visible, stable (not animating), enabled, and receiving events before actioning. This eliminates most explicit waits and is the primary reason Playwright suites are less flaky than Selenium.

Selenium Grid distributes tests across multiple machines/browsers in parallel. Grid 4 uses a Hub + Node model, supports Docker Compose out of the box, and integrates with Kubernetes for auto-scaling. Use it when local execution can't hit the parallelism you need.

Trigger via GitHub Actions, Jenkins, GitLab CI, Azure DevOps, or CircleCI. Steps: checkout code → install deps → run smoke on PR → run full regression on merge → publish Allure/ExtentReports → notify Slack. Use test-tagging (@smoke, @regression) to control scope per pipeline stage.

TestNG parallel="methods" or "tests" with thread-count. Playwright projects + workers. Cypress parallelization via Dashboard. JUnit 5 parallel execution config. Always ensure test isolation: thread-safe WebDriver (ThreadLocal), unique test data, no shared mutable state.

Store WebDriver in ThreadLocal, generate unique test data per thread (UUID + timestamp), avoid static mutable state, use per-thread config, and isolate downloads/screenshots into per-thread folders. Test with -DthreadCount=10 locally before pushing.

Docker containerizes browsers (selenium/standalone-chrome), test frameworks, and app under test — reproducible across dev laptops and CI. Docker Compose spins up Selenium Grid + app + DB with one command. Ephemeral containers per PR isolate flaky state.

Allure (rich HTML + trends), ExtentReports (interactive), ReportPortal (AI failure clustering), Playwright's built-in HTML reporter, and Cypress Dashboard. Attach screenshots, videos, network HAR, and logs to every failed test.

Root-cause first — is it wait, data, environment, or third-party? Fix implicit waits with explicit conditions, replace unstable selectors with data-testid, isolate test data, mock third parties, and stabilize animations. Retry flaky tests up to 2× in CI (test.retries), but always quarantine and file a bug.

API test automation validates REST/GraphQL/SOAP endpoints without a UI — faster and more stable than UI tests. Tools: RestAssured (Java), Requests + Pytest (Python), Postman + Newman, Playwright APIRequestContext, Karate DSL, k6 for load.

Check: HTTP status code, response time, response headers, response body (schema, values, JSONPath assertions), error handling for 4xx/5xx, authentication/authorization, and idempotency for POST/PUT/DELETE. Use JSON schema validators or Pact for contract testing.

Contract testing (Pact, Spring Cloud Contract) validates that a consumer and provider agree on request/response shape — the provider runs consumer-generated contract tests in its pipeline. Prevents integration bugs across microservices without slow E2E environments.

Performance testing measures response time, throughput, and stability under load. Tools: JMeter (open-source, plugin-rich), k6 (JS-scriptable, developer-friendly), Gatling (Scala DSL, high performance), Locust (Python), Azure Load Testing.

Service virtualization simulates third-party or downstream services (payment gateway, mainframe, partner API) so tests can run without them. Tools: WireMock, MockServer, Hoverfly, Mountebank. Critical when dependencies are unstable, rate-limited, or costly.

Visual regression testing captures screenshots and diffs them against baselines to catch UI/UX regressions (moved buttons, broken CSS). Tools: Percy, Applitools Eyes, Chromatic, Playwright's toHaveScreenshot(). AI-driven tools ignore anti-aliasing and dynamic content noise.

Automation coverage %, pass rate, mean time to detect (MTTD), mean time to repair (MTTR), flaky-test rate, average execution time, defect leakage %, tests per feature, and framework maintenance hours. Track trends, not absolute numbers.

Risk + stability + frequency. Automate 80–90% of stable regression, 100% of API contract, 100% of load. Keep 20% manual bandwidth for exploratory, UX, one-off, and new-feature investigation. Revisit ratio every quarter.

Centralize the framework (shared BOM/library), publish coding standards + PR template, run brown-bag sessions, and appoint SDET champions per squad. Governance model: shared framework, team-owned tests, common CI templates, weekly test-health review.

Request stable data-testid from developers (best). Otherwise use relative locators (Selenium 4), text + role selectors (Playwright), or parent-child CSS. Avoid absolute XPath and IDs that contain UUIDs or timestamps.

Check the last commit and CI environment change. Group failures by error signature (locator not found, timeout, assertion). If concentrated in one module → likely UI change, sync with dev. If scattered → likely environment/network/test data. Run 5 samples locally in headed mode with trace enabled to pinpoint.

Show cost of manual regression per release × release frequency, current defect leakage, and time-to-market delay. Present a phased plan: pilot on one critical flow → measure ROI → expand. Track and publish MTTR/coverage/leakage monthly to keep momentum.