What is the Page Object Model (POM) and why is it important in test automation?

POM is a design pattern that creates an abstraction layer between test scripts and UI elements. Each page (or component) gets a class that encapsulates its locators and interactions. Benefits: reduces duplication (one locator update fixes all tests), improves readability (tests read like user stories), and makes maintenance scalable. Without POM, a single UI change can break dozens of tests.

How do you handle flaky tests in your automation suite?

First, identify if flakiness is from timing (add explicit waits, not sleeps), test data (ensure isolation), or environment (container-based test infra). Track flaky tests with a quarantine mechanism — flag them, fix root causes, and only re-enable when stable. Implement retry logic as a temporary band-aid, not a permanent fix. Monitor flaky test rate as a team metric. In Playwright, use `test.retry()` judiciously and `waitForSelector` over arbitrary delays.

Compare Playwright, Selenium, and Cypress. When would you choose each?

Playwright: best for modern web apps, auto-wait, multi-browser (Chromium, Firefox, WebKit), supports multiple languages, great for parallelism. Selenium: mature ecosystem, supports any language/browser, best when you need to integrate with legacy infrastructure or non-web testing. Cypress: excellent DX for JavaScript teams, time-travel debugging, but limited to Chromium-family browsers and single-tab testing. Choose based on team skills, browser requirements, and existing infrastructure.

How do you design a test automation framework from scratch?

Start with goals: what types of tests (UI, API, visual), what browsers/platforms, what CI integration. Architecture layers: test runner (Playwright/Jest), page objects or component abstractions, test data management (factories/fixtures), reporting (Allure, HTML), and CI integration. Key decisions: parallel execution strategy, environment configuration, retry policies, and screenshot/video capture for failures. Start with a few critical path tests and expand. Avoid over-engineering — build what you need now.

Explain the difference between implicit waits, explicit waits, and hard sleeps. Which should you use?

Hard sleeps (`sleep(5000)`) waste time and are still flaky — avoid them. Implicit waits set a global timeout for element lookups but hide real problems. Explicit waits (`waitForSelector`, `waitForResponse`) wait for specific conditions and are the gold standard — they're precise and self-documenting. Playwright's auto-wait handles most cases, so you rarely need manual waits. When you do, always wait for a specific condition (element visible, network idle) rather than a fixed time.

How do you handle test data management in automation?

Approaches by maturity: (1) Seed data in test setup — API calls or DB seeds before each test. (2) Factory pattern — generate unique data per test run to avoid conflicts. (3) Fixtures — Playwright fixtures provide scoped setup/teardown. (4) Isolated environments — Docker containers with known state. Key principle: each test should be independent and create its own data. Never rely on shared mutable state between tests.

What is visual regression testing and how would you implement it?

Visual regression captures screenshots of UI components or pages and compares them against approved baselines, pixel-by-pixel or perceptually. Tools: Playwright's `toHaveScreenshot()`, Percy, Chromatic, BackstopJS. Implementation: capture baselines in CI, compare on PR, review diffs in a visual dashboard. Challenges: dynamic content (mask timestamps, ads), responsive breakpoints (test multiple viewports), and managing baseline updates when UI intentionally changes.

How do you achieve parallel test execution and why does it matter?

Parallel execution reduces feedback time — a 60-minute suite can run in 10 minutes across 6 workers. Requirements: test isolation (no shared state or data), independent test environments or careful resource partitioning, and a runner that supports parallelism (Playwright shards, Selenium Grid, TestNG). Challenges: shared databases (use unique prefixes or separate schemas), file system conflicts, and port collisions. Monitor for flakiness introduced by parallelism.

How do you test accessibility (a11y) in your automation suite?

Integrate axe-core via `@axe-core/playwright` or `cypress-axe`. Run automated a11y scans as part of your test suite — check for missing alt text, color contrast, ARIA roles, keyboard navigation. Automated tools catch ~30-40% of a11y issues (WCAG violations). Supplement with manual keyboard-only testing, screen reader testing (NVDA/VoiceOver), and user testing with people who use assistive technology.

What is BDD (Behavior-Driven Development) and how does Cucumber fit into test automation?

BDD uses natural-language scenarios (Given/When/Then) to describe expected behavior before writing code. Cucumber maps these Gherkin scenarios to step definitions (code). Benefits: shared language between QA, devs, and PMs; living documentation. Drawbacks: extra abstraction layer, step definition maintenance, and Gherkin can become a bottleneck if overused. Best for acceptance tests where non-technical stakeholders need to understand scenarios. Don't force all tests into BDD.