QA Engineer Interview Prep Guide

Structure by test pyramid levels: 1) Unit tests: payment calculation logic, tax computation, discount code validation (aim for 80%+ coverage), 2) Integration tests: payment gateway API contract tests, email service integration, database transaction integrity, 3) E2E tests: happy path checkout with Playwright (select items, apply discount, enter payment, verify confirmation), error paths (invalid card, expired discount, out-of-stock mid-checkout), 4) Performance: load test checkout endpoint under 1000 concurrent users with k6, 5) Security: SQL injection on input fields, IDOR on order retrieval, PCI compliance validation. Discuss risk-based prioritization: payment processing gets the most test coverage because failure cost is highest.

Show clean test structure with arrange-act-assert pattern: use page.getByRole() and page.getByTestId() for stable selectors (never CSS selectors that break). Test cases: 1) Successful login: fill email/password, click submit, assert redirect to dashboard, 2) Failed login: invalid credentials, assert error message visible with correct text, 3) Rate limiting: attempt 5 failed logins, assert lockout message, 4) Accessibility: verify form labels are associated with inputs, error messages have aria-live attributes, focus moves to error on submission failure. Use test fixtures for setup/teardown, page object pattern for reusability. Discuss why data-testid is preferred over CSS classes (classes change during redesigns).

Use the test automation pyramid as a framework: automate at the bottom (unit, integration, contract tests) aggressively, automate critical E2E paths selectively, keep exploratory testing manual. Automate when: tests run frequently (regression), data-driven scenarios (100 input combinations), CI/CD gates (blocking deployment), and multi-browser/device testing. Keep manual when: one-time validation, usability assessment, visual/subjective evaluation, and exploratory testing for new features. Example of wrong automation: "We automated visual regression tests for a marketing site that redesigned every quarter. The 200 visual tests broke with every redesign, requiring more maintenance effort than manual review. We replaced them with a smaller set of layout tests and manual design review."

Structure systematically: Positive tests: valid payload returns 201 with user object, idempotency check. Negative tests: missing required fields (400), invalid email format, password too short, duplicate email (409). Boundary tests: maximum length username, special characters in name, Unicode characters. Security: SQL injection in fields ("OR 1=1--"), XSS payloads in name field, authorization (cannot create admin user without admin role), rate limiting (429 after N requests). Schema validation: response matches OpenAPI spec. Performance: response time under 200ms at p95, test under concurrent load. Discuss tools: Postman for manual exploration, REST Assured or Playwright API testing for automation, k6 for performance.

Approach flakiness as a reliability engineering problem: 1) Quarantine: move flaky tests to a separate suite that does not block deployments while you fix them, 2) Categorize root causes: timing issues (race conditions, insufficient waits), shared state (tests depending on other test execution order), environment issues (network timeouts, database state), non-deterministic data (random IDs, timestamps), 3) Fix by category: replace sleep() with explicit waits (waitForSelector, waitForResponse in Playwright), isolate test data (each test creates its own data), use retry logic only as a last resort (it masks real issues), mock external dependencies, 4) Prevent: add flaky detection to CI (run new tests 10x before merging), track flaky test metrics weekly, set a team SLO (less than 2% flaky rate).

Use STAR format with emphasis on your testing technique: "During exploratory testing of our payment migration, I noticed that applying a 100% discount code and then removing it still set the total to $0 in the database, even though the UI showed the correct amount. I found this by testing the remove-discount flow specifically, which was not in the original test plan. The root cause was that the discount removal API was not recalculating the cart total. If shipped, customers could get free orders. I wrote a regression test, documented the edge case, and it was fixed within 2 hours." Show the investigation technique, quantify the business impact, and describe the preventive action.

Design a testing pipeline: 1) Pre-commit: linting, unit tests (fast, under 2 minutes), 2) PR/merge: unit tests + integration tests + API contract tests (under 10 minutes), blocks merge on failure, 3) Post-merge to staging: E2E tests with Playwright (critical paths only, under 15 minutes), visual regression tests, accessibility scans with axe-core, 4) Pre-production: full E2E suite, performance tests with baseline comparison, security scan (OWASP ZAP), 5) Post-deploy: smoke tests against production, synthetic monitoring. Discuss parallelization for speed, test result reporting (Allure, HTML reports), and alerting on test infrastructure failures.

Explain POM as a design pattern that separates UI locators and actions from test logic: each page or component gets a class containing element selectors and interaction methods. Benefits: when the UI changes, you update one page object instead of 50 tests. Example: LoginPage class with emailInput, passwordInput, submitButton locators and login(email, password) method. Tests call loginPage.login("user@test.com", "pass123") without knowing the selector details. Extend to component objects for reusable widgets (DataTable, Modal, Dropdown). Discuss alternatives: Screenplay pattern for complex workflows, app actions pattern (Cypress recommended approach). Mention that over-abstraction is a mistake: do not create page objects for trivial pages.