Bottom to top:

• Unit tests (70%): Fast, isolated, test single functions/classes
• Integration tests (20%): Test component interactions, APIs
• E2E tests (10%): Full user flows, slowest, most brittle

More tests at bottom = faster feedback, easier maintenance.

Automate when: Test runs frequently, is repetitive, tests critical paths, requires exact data comparison, regression testing

Keep manual when: Exploratory testing, UX/usability evaluation, one-time tests, rapidly changing features, visual testing (though this is automatable now)

Verification: "Are we building the product right?" Checks against specifications.

Validation: "Are we building the right product?" Checks against user needs.

Black box: No knowledge of internals, test based on requirements/behavior

White box: Full code access, test internal paths/logic

Gray box: Partial knowledge, common in integration testing

Regression testing ensures new changes don't break existing functionality.

Optimization: Prioritize by risk, parallelize execution, use test impact analysis, maintain test suite (remove flaky/redundant tests), run smoke tests first.

Tests that pass/fail inconsistently without code changes.

Common causes: Timing issues, test order dependencies, shared state, external dependencies.

Solutions: Proper waits (not sleep), isolated test data, mock external services, quarantine flaky tests while fixing.

Equivalence partitioning: Divide inputs into groups that should behave similarly, test one from each group.

Boundary value: Test at edges of partitions (min, max, just inside, just outside). Bugs often occur at boundaries.

• Code coverage: Line, branch, function coverage
• Requirement coverage: Tests mapped to requirements
• Risk coverage: Critical paths tested

Note: High coverage doesn't guarantee quality—you can have 100% coverage with poor tests.

Smoke testing: Broad, shallow tests to verify basic functionality works. "Does the build even run?"

Sanity testing: Narrow, deep tests on specific functionality after changes. "Does this feature work?"

• Clear, descriptive name explaining what it tests
• Arrange-Act-Assert structure
• One assertion per test (ideally)
• Independent—no reliance on other tests
• Repeatable—same result every time
• Fast execution

Testing earlier in the development cycle. Include QA in design discussions, review requirements for testability, write tests alongside code (TDD), catch bugs before they're expensive to fix.

Introducing small code changes (mutations) to verify tests catch them. If a mutation survives (tests still pass), your tests aren't thorough enough. Measures test quality, not just coverage.

Selenium: Multi-language, multi-browser, mature ecosystem. Slower, more setup.

Cypress: JavaScript only, fast, great DX, built-in waits. Single domain limitation.

Playwright: Microsoft-backed, multi-browser, multi-language, modern API, good for cross-browser.

Design pattern where each page/component has a class containing its elements and actions.

Benefits: Reusability, maintainability (locator changes in one place), readable tests. Tests call page methods, not raw selectors.

Preference order:

1. data-testid (explicit, stable)
2. ID (if unique and stable)
3. Name/placeholder (semantic)
4. CSS selector (flexible)
5. XPath (powerful but brittle)

Avoid: Index-based, complex XPath, class names that change.

• Explicit waits: Wait for specific condition (visibility, clickability)
• Implicit waits: Global timeout for finding elements
• Avoid: Thread.sleep/hard waits

Cypress/Playwright have built-in auto-waiting, reducing flakiness.

Uploads: Send file path to input element (don't interact with OS dialog)

Downloads: Configure download directory, verify file exists after action, use headless browser settings

Alerts: Switch to alert, accept/dismiss, get text

Windows/tabs: Switch to window by handle

iframes: Switch to frame before interacting with elements inside

• Use test runner features (pytest-xdist, TestNG parallel)
• Selenium Grid or cloud services (BrowserStack, Sauce Labs)
• Ensure tests are independent (no shared state)
• Isolated test data per thread

Distributed test execution system. Hub routes tests to nodes running different browser/OS combinations. Enables parallel execution across multiple machines. Selenium Grid 4 uses Docker for easier setup.

• API login and inject session cookie (faster)
• UI login in setup, reuse session
• Mock authentication for unit tests
• Store credentials securely (env vars, secrets manager)

Parameterize browser in tests, use cloud providers for browser farm, prioritize browsers by user analytics, handle browser-specific quirks with conditional logic or separate tests.

Comparing screenshots to detect unintended visual changes. Tools: Percy, Chromatic, Applitools.

Challenges: Dynamic content, anti-aliasing differences, maintaining baselines.

1. Check error message and stack trace
2. Review screenshots/videos from failed run
3. Run locally in headed mode
4. Add debugging breakpoints
5. Check if it's a test issue or application bug
6. Verify test data and environment

• Manual: Postman, Insomnia
• Automation: REST Assured, requests (Python), SuperTest
• Contract: Pact for consumer-driven contracts
• Performance: k6, JMeter, Gatling

• Status codes (200, 400, 401, 404, 500)
• Response body structure and data types
• Response time
• Error handling and messages
• Authentication/authorization
• Input validation (invalid data, edge cases)
• Idempotency for POST/PUT/DELETE

GET: Retrieve data (idempotent)

POST: Create new resource

PUT: Update/replace resource (idempotent)

PATCH: Partial update

DELETE: Remove resource (idempotent)

Use JSON Schema validation. Define expected schema (types, required fields, formats), validate response against it. Tools: Ajv, jsonschema. Catches structural changes before they break clients.

Ensures API provider and consumer agree on interface. Consumer defines expectations (contract), provider verifies it meets them. Pact is popular tool. Catches integration issues without full E2E tests.

• Store tokens/keys in environment variables
• Generate tokens programmatically in test setup
• Handle token refresh for long test suites
• Test both authenticated and unauthenticated scenarios

Load: Test under expected user load—can system handle normal traffic?

Stress: Test beyond capacity—when does it break?

Soak/Endurance: Test over extended time—any memory leaks or degradation?

• Monitor response times per endpoint
• Check database query times
• Monitor server resources (CPU, memory, I/O)
• Use APM tools (New Relic, Datadog)
• Profile slow endpoints

• Response time (average, p50, p95, p99)
• Throughput (requests/second)
• Error rate
• Concurrent users supported
• Resource utilization

• Unit tests for individual services
• Contract tests between services
• Integration tests with mocked dependencies
• E2E tests for critical paths (fewer, slower)
• Chaos engineering for resilience

• Unit tests on every commit
• Integration tests on PR merge
• E2E tests on staging deployment
• Fail build on test failure
• Publish reports and coverage
• Alert on test degradation

1. Review requirements and acceptance criteria
2. Identify test scenarios (happy path, edge cases, errors)
3. Determine what to automate vs test manually
4. Write test cases before testing
5. Execute tests, log bugs with clear repro steps
6. Add automated tests to regression suite

• Create test data in setup, clean up in teardown
• Use factories/builders for data generation
• Avoid production data (privacy concerns)
• Database seeding for consistent states
• Isolated data per test to prevent conflicts

Consider: Severity (impact on users), frequency (how many affected), workaround availability, business impact, fix complexity. Critical/blocking bugs first, then high-impact issues. Communicate priorities with team.

• Regular review and cleanup of obsolete tests
• Fix or quarantine flaky tests immediately
• Modular, reusable test components
• Clear naming and organization
• Documentation and onboarding for new team members
• Monitor test suite health metrics

Structure: Describe the context, how you found it (exploratory testing, edge case thinking, user perspective), the impact, how you reported it. Shows your testing mindset and attention to detail.