Selenium is a mature, language-agnostic framework (Java, Python, C#, JS) with the largest community and browser support. Playwright is newer (by Microsoft), supports Chromium, Firefox, and WebKit natively, has built-in auto-waiting, network interception, and trace viewer. Choose Selenium when your team has existing Selenium infrastructure or needs cross-browser support including legacy browsers. Choose Playwright for greenfield projects where speed, auto-waiting, and modern API design matter. In 2026, most new projects at product companies start with Playwright.

POM separates page structure (locators, elements) from test logic by creating a class for each page or component. Each class contains locators as variables and user actions as methods. Benefits: reduces code duplication, improves maintainability (change a locator in one place, not 50 tests), and makes tests readable. POM is the most asked design pattern in QA automation interviews — over 70% of framework-round questions reference it directly or indirectly.

Use Explicit Waits (WebDriverWait with ExpectedConditions) to wait for specific conditions: element visibility, clickability, or presence. Avoid Thread.sleep() — it wastes time and creates flaky tests. Implicit Waits set a global timeout for finding elements but cannot wait for specific conditions. In Selenium 4, the recommended approach is explicit waits. Example: new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(locator));

Playwright automatically waits for elements to be actionable before performing operations — visible, enabled, stable, and receiving events. You rarely need explicit waits. This eliminates the most common source of flaky tests in Selenium. In Selenium, you must manually code waits for every interaction. Playwright’s auto-wait covers click, fill, check, and navigation actions by default, making test scripts shorter and more reliable.

TestNG offers richer features out of the box: parallel execution, data providers, test grouping, dependency management, and detailed HTML reports. JUnit 5 has closed the gap with extensions, parameterised tests, and tags. TestNG is dominant in enterprise QA automation (TCS, Infosys, GCCs). JUnit 5 is preferred in developer-driven testing environments. In interviews, state your preference with reasoning — there is no wrong answer. Most QA automation frameworks in India use TestNG with Selenium or Playwright.

For iframes: driver.switchTo().frame(frameElement) to enter, driver.switchTo().defaultContent() to return. For multiple windows: get all window handles with driver.getWindowHandles(), iterate and switch with driver.switchTo().window(handle). Common interview trap: forgetting to switch back to the parent frame or default content after interacting with an iframe — subsequent locators will fail silently.

Cypress runs inside the browser (not as an external driver), giving it direct DOM access, automatic waiting, and time-travel debugging. It is JavaScript-only and supports Chromium and Firefox (no Safari/WebKit). Cypress excels at component and integration testing for frontend teams. Selenium and Playwright are better for cross-browser E2E testing and multi-language teams. Cypress is common at JavaScript-heavy startups; Selenium and Playwright dominate enterprise QA.

Selenium supports: ID, Name, ClassName, TagName, LinkText, PartialLinkText, CSS Selector, and XPath. Preferred order: ID (fastest, most stable) > CSS Selector (fast, readable) > XPath (most flexible, slower). Avoid using absolute XPath — it breaks with any DOM change. Use relative XPath with attributes: //button[@data-testid='submit']. In 2026, data-testid attributes are the industry standard for test-stable locators.

BDD (Behavior-Driven Development) uses Gherkin syntax: Given (precondition), When (action), Then (expected result). A feature file describes a user scenario in plain English. Step definitions map Gherkin steps to automation code. Example: Given the user is on the login page / When the user enters valid credentials / Then the user should see the dashboard. BDD bridges the gap between business and QA teams. Cucumber questions are growing — now asked in 40% of product company interviews.

Upload: use sendKeys(filePath) on the file input element — no need for AutoIT or Robot class in most cases. Download: configure browser preferences to auto-download to a specific directory, then verify the file exists. In Playwright, use page.setInputFiles() for uploads and download.path() for downloads. Interview tip: mention that you avoid OS-dependent tools (AutoIT) because they break cross-platform CI/CD execution.

GET retrieves data (read-only, idempotent). POST creates a new resource. PUT updates an entire resource (idempotent). PATCH partially updates a resource. DELETE removes a resource. In testing, verify each method returns the correct status code: GET 200, POST 201, PUT 200, DELETE 204. Also test invalid methods — sending POST to a GET-only endpoint should return 405 Method Not Allowed.

Use the Tests tab with JavaScript assertions: pm.test("Status 200", function() { pm.response.to.have.status(200); }); Validate response body: pm.expect(jsonData.name).to.eql("John"); Validate schema using tv4.validate() or AJV. Validate response time: pm.expect(pm.response.responseTime).to.be.below(2000); Run collections with Newman CLI for CI/CD integration.

REST uses HTTP methods, is stateless, supports JSON/XML, and is lightweight. SOAP uses XML exclusively, has built-in WS-Security, supports ACID transactions, and is protocol-independent. REST dominates modern applications (90%+ of new APIs). SOAP is still used in banking, insurance, and legacy enterprise systems. In interviews, mention that you test REST APIs with Postman/Rest Assured and SOAP APIs with SoapUI.

For JWT: send a POST to the auth endpoint with credentials, extract the token from the response, and include it in subsequent requests as Authorization: Bearer <token>. For OAuth 2.0: follow the grant type flow (client credentials, authorization code), obtain the access token, and use it until expiry. In Postman, use Pre-request Scripts to auto-refresh tokens. In Rest Assured, chain requests to handle token lifecycle programmatically.

Contract testing verifies that the API provider and consumer agree on the request/response format — without running the full service. Tools like Pact define contracts as JSON specifications. When the provider changes its API, contract tests fail before deployment, preventing integration breakages. In microservices architectures with 50+ services, contract testing catches breaking changes that E2E tests miss because they only cover happy paths.

Send invalid inputs: empty body, wrong data types, exceeding field limits, SQL injection strings, missing required fields. Verify appropriate error codes (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity). Verify error messages are descriptive but do not expose internal details. Test rate limiting (429 Too Many Requests). Negative testing often reveals more bugs than positive testing.

Postman: GUI-based, ideal for exploratory testing, quick validations, and sharing collections with the team. Best for manual QA and API documentation. Rest Assured: Java-based, BDD-style syntax (given().when().then()), integrates directly into TestNG/JUnit test suites and CI/CD pipelines. Best for building scalable automation frameworks. Use Postman for exploration and debugging, Rest Assured for regression automation.

1xx: Informational (100 Continue). 2xx: Success (200 OK, 201 Created, 204 No Content). 3xx: Redirection (301 Moved, 302 Found). 4xx: Client Error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found). 5xx: Server Error (500 Internal, 502 Bad Gateway, 503 Service Unavailable). In interviews, be specific — saying “I check for 200” is weak; saying “POST should return 201 with a Location header” shows real understanding.

Configure the pipeline (Jenkins, GitHub Actions, GitLab CI) to trigger test execution on every commit or pull request. Define test stages: unit tests first (fast feedback), then API tests, then UI tests (slowest). Use exit codes to fail the pipeline on test failures. Store test reports as pipeline artifacts. Notify the team via Slack or email on failures. The key principle: tests must run without manual intervention and block deployment on failure.

Docker creates lightweight, isolated containers with pre-configured environments. In test automation: run browsers in containers (Selenium Grid with Docker), spin up test databases, and ensure consistent environments across local and CI/CD. Use docker-compose.yml to define multi-container setups (app + database + Selenium Grid). Docker eliminates “works on my machine” problems — every test run uses the identical environment.

Selenium Grid runs tests in parallel across multiple machines, browsers, and operating systems. A Hub receives test requests and distributes them to Nodes. Use it when: test suite execution time is too long on a single machine, you need cross-browser testing (Chrome, Firefox, Edge), or you need to run tests on different OS versions. In 2026, most teams use Selenium Grid 4 with Docker or cloud platforms like BrowserStack and LambdaTest.

The test pyramid has three layers: Unit Tests (base, largest number, fastest), Integration/API Tests (middle), and UI/E2E Tests (top, fewest, slowest). Healthy ratio: 70% unit, 20% API, 10% UI. Anti-pattern: the “ice cream cone” where most tests are UI-based — slow, flaky, expensive to maintain. In interviews, explain how you apply this: “I automate business logic at the API layer and reserve UI tests for critical user journeys only.”

Strategies: (1) Generate test data dynamically using factories or builders before each run. (2) Use database seeding scripts to reset to a known state. (3) Mock external dependencies with tools like WireMock. (4) Use separate test environments with dedicated databases. Never use production data in tests — it creates data privacy risks and unpredictable test results. Each test should be independent and not rely on data created by another test.

Shift-left means moving testing earlier in the development lifecycle — writing tests during development, not after. QA participates in requirement reviews, writes test cases before code is written (BDD), and automates tests alongside feature development. Impact: defects are found earlier (cheaper to fix), test coverage is higher, and release cycles are shorter. In 2026, shift-left is not a buzzword — it is an expectation at product companies and GCCs.

Smoke testing: a quick, shallow check that critical functionality works after a new build (10-15 tests, run first). Sanity testing: a narrow, focused check on a specific feature or bug fix. Regression testing: a comprehensive re-run of existing tests to ensure new changes have not broken anything. Sequence in a sprint: smoke (after build) –> sanity (after bug fix) –> regression (before release). Automate smoke and regression; sanity is often manual and targeted.

Automate: repetitive tests run every sprint (regression), data-driven tests with many input combinations, cross-browser/cross-device checks, and tests that are tedious or error-prone manually. Do not automate: one-time tests, exploratory testing, tests with frequently changing requirements, and tests that require visual judgement. The ROI formula: if a test runs more than 3 times and takes more than 5 minutes manually, automate it.

A framework is a structured set of guidelines, tools, and libraries that organises test automation. Components: test runner (TestNG/JUnit/pytest), page objects (POM), configuration management (properties/YAML files), reporting (Allure, ExtentReports), logging, data providers (Excel/CSV/database), utilities (waits, screenshots, retries), and CI/CD integration. A well-designed framework allows new tests to be written in minutes by following established patterns.

Data-driven testing separates test logic from test data — the same test runs with multiple data sets. In TestNG, use @DataProvider to feed data from arrays, Excel, CSV, or databases. In JUnit 5, use @ParameterizedTest. Example: a login test that runs with 20 username/password combinations. Benefits: one test script covers dozens of scenarios, easy to add new data without changing code.

First, identify the root cause: timing issues (add proper waits), test data dependencies (isolate test data), environment instability (use Docker), or order-dependent tests (make tests independent). Implement retry mechanisms (TestNG IRetryAnalyzer, Playwright test.retries). Track flaky tests in a dashboard — if a test fails randomly more than 5% of the time, fix it or remove it. Flaky tests erode team trust in automation.

Equivalence partitioning divides inputs into groups (partitions) where all values in a group should produce the same result. Test one value per partition. Boundary value analysis tests at the edges of partitions — minimum, minimum+1, maximum-1, maximum, and just outside boundaries. Example: age field accepting 18-65. Partitions: 65. Boundary values: 17, 18, 19, 64, 65, 66. These techniques reduce test cases from infinite to manageable while maximising defect detection.

Appium is an open-source framework for automating native, hybrid, and mobile web apps on iOS and Android. It uses the WebDriver protocol — so Selenium experience transfers directly. Key concepts: DesiredCapabilities (device, platform, app path), UIAutomator2 (Android), and XCUITest (iOS). Appium runs tests on real devices, emulators, and cloud platforms (BrowserStack, Sauce Labs). Mobile testing questions appear in 25%+ of QA automation interviews at companies with mobile products.

Assertions verify that actual results match expected results. Hard assertions (Assert.assertEquals) stop execution on failure. Soft assertions (SoftAssert in TestNG) continue execution and report all failures at the end. Use hard assertions for critical checkpoints (login success). Use soft assertions when validating multiple fields on a page (verify all form errors at once). Effective assertions are specific — assert on exact values, not just “element exists”.

Use the STAR method. Describe the bug’s severity (data loss, security, payment failure), how you found it (regression test, exploratory testing), how you communicated it (immediately, with reproduction steps), and the outcome (release delayed by 1 day, preventing X impact on Y users). Interviewers assess your judgement, communication under pressure, and prioritisation — not just technical debugging.

Use risk-based testing: identify high-risk areas (payment, authentication, core workflows) and prioritise those. Apply the 80/20 rule — 80% of defects cluster in 20% of modules. Test critical user journeys first, edge cases later. Communicate trade-offs to stakeholders: “We can cover 100% of P1 scenarios and 60% of P2 by the deadline. Here is what we are deferring and the risk.” Never skip testing entirely — a reduced regression suite is better than no regression.

Provide objective evidence: clear reproduction steps, screenshots, logs, environment details, and the expected vs actual result referencing the requirement document. Avoid “it is broken” language — use “the behavior differs from the spec in section X.” If ambiguity exists in the requirement, escalate to the product owner for clarification. The goal is shared understanding, not winning an argument. Document the resolution for future reference.

Structure your answer: “I start with the official documentation to understand core concepts. Then I build a small proof-of-concept on a test application. I contribute to the team’s framework within the first week. I deepen through real project work, not just tutorials.” Example: “When our team migrated from Selenium to Playwright, I completed the Playwright docs in 3 days, automated 5 critical tests by day 5, and led the migration plan within 2 weeks.”

Shift-left: participate in grooming and design reviews to catch issues before code is written. Automate regression so it runs without manual effort. Focus manual testing on new features and exploratory scenarios. Use risk-based prioritisation to cover the highest-impact areas first. Communicate test coverage honestly — “we have automated 85% of regression; the remaining 15% covers rarely used admin flows with low risk.”

Key metrics: test coverage percentage (automated vs total test cases), execution time (trend over sprints), pass/fail rate, defect detection rate (bugs found by automation vs manual), flaky test percentage (should be below 5%), and automation ROI (time saved vs time invested). Avoid vanity metrics like “number of test scripts” — 500 poorly designed tests are worse than 100 well-maintained ones. Present metrics that demonstrate business value.

Structure: what was the problem (slow execution, high flakiness, poor coverage), what you did (parallelised tests, implemented retry logic, refactored POM), and the measurable result (execution time reduced from 4 hours to 45 minutes, flaky rate dropped from 15% to 3%). Interviewers want to see initiative and impact. Quantify everything — “I improved test execution time” is vague; “I reduced it by 80% using parallel execution on Selenium Grid” is compelling.

Avoid generic answers. Connect to: (1) a specific moment when automation prevented a production bug and you saw the real impact, (2) the satisfaction of building frameworks that scale — it is engineering, not just testing, and (3) why this company’s product challenges excite you. Example: “I automated a payment flow regression suite that caught a critical rounding error in staging — preventing a ₹12L revenue leak. That moment proved that QA automation directly protects business outcomes.”