What is the test pyramid and how do you apply it in practice?

The test pyramid suggests: many fast unit tests at the base, fewer integration tests in the middle, and few slow E2E tests at the top. In practice: developers own unit tests, QA focuses on integration and E2E tests for critical flows. The anti-pattern is the "ice cream cone" — too many E2E tests that are slow and flaky. Apply it pragmatically: if your app is API-heavy, invest more in API integration tests. If it's UI-heavy, visual regression tests may be more valuable than unit tests.

How do you create a test plan for a new feature?

A test plan covers: (1) Scope — what's being tested and what's out of scope. (2) Test approach — manual vs. automated, exploratory vs. scripted. (3) Test scenarios — positive paths, negative paths, edge cases. (4) Test data requirements — what data needs to exist. (5) Environment — where tests will run. (6) Entry/exit criteria — when to start testing, when to declare "done." (7) Risks — what could go wrong, what might not be testable. Keep it lightweight — a one-page document or checklist, not a 50-page specification.

What is risk-based testing and how do you implement it?

Risk-based testing prioritizes testing effort based on probability of failure × impact of failure. Implementation: (1) Identify risk factors — new code, complex logic, third-party integrations, historically buggy areas. (2) Assign risk scores — high/medium/low for probability and impact. (3) Allocate testing effort proportionally — high-risk areas get thorough testing, low-risk areas get smoke tests. (4) Review risks each sprint — new features shift the risk landscape. Tools: risk matrices, heatmaps. This ensures limited testing time targets the highest-value areas.

What is exploratory testing and how does it complement automated testing?

Exploratory testing is simultaneous learning, test design, and execution — you explore the app, form hypotheses, and test them in real-time. It finds bugs that scripted tests miss: usability issues, unexpected edge cases, integration problems, and "what if" scenarios. Structure with session-based testing: time-boxed sessions with a charter (e.g., "Explore the checkout flow focusing on payment error handling"). Automation handles regression; exploratory testing handles discovery. Both are essential — neither alone is sufficient.

How do you measure test coverage and is 100% coverage a good goal?

100% code coverage is not a useful goal — it encourages testing trivial code while missing important scenarios. Coverage types: (1) Code coverage — lines/branches executed (measured by Istanbul/c8). (2) Requirements coverage — which requirements have test cases. (3) Risk coverage — which high-risk areas are tested. Better metrics: critical path coverage (are all business-critical flows tested?), mutation testing score (do tests actually catch bugs?), and escaped defect rate (how many bugs reach production?). Aim for high coverage of critical paths, not arbitrary coverage percentages.

What is boundary value analysis and equivalence partitioning?

Equivalence partitioning divides inputs into groups that should behave the same way — test one value from each group instead of every possible input. Example: age field accepts 18-65 → partitions: 65 (invalid). Boundary value analysis tests at the edges of partitions: 17, 18, 65, 66. Bugs cluster at boundaries because code uses , >= and off-by-one errors are common. Together, these techniques reduce test cases while maximizing defect detection.

How do you approach regression testing effectively?

Regression testing verifies that new changes don't break existing functionality. Strategy: (1) Automate the regression suite — no human should repeatedly run the same tests. (2) Prioritize by risk — not every test runs on every change. (3) Maintain the suite — remove obsolete tests, update for UI changes, fix flaky tests. (4) Layer it — smoke tests (5 minutes) on every commit, full regression (30 minutes) on PR merge, extended regression (hours) nightly. The biggest antipattern: a regression suite that takes so long nobody runs it.

What is the difference between verification and validation in QA?

Verification: "Are we building the product right?" — does the implementation match the specification? (code reviews, unit tests, static analysis). Validation: "Are we building the right product?" — does the product meet the user's actual needs? (user acceptance testing, beta testing, usability testing). A feature can pass verification (matches spec perfectly) but fail validation (the spec was wrong, and users don't want it). QA should care about both — don't just test against the spec, question whether the spec makes sense.

How do you handle testing in a monorepo vs. polyrepo architecture?

Monorepo: all services in one repo. Testing benefits: easy cross-service refactoring, shared test utilities, atomic commits across services. Challenges: need selective testing (only run tests for affected services), CI pipeline can be slow without proper change detection (Nx, Turborepo). Polyrepo: each service in its own repo. Testing benefits: clear ownership, independent CI pipelines. Challenges: cross-repo integration testing is harder, version synchronization, need contract tests between repos. Neither is inherently better — match to team structure and workflow.

How do you build a quality metrics dashboard?

Key metrics to visualize: (1) Escaped defect rate — bugs found in production per release. (2) Test pass rate trend — is quality improving or degrading? (3) Flaky test rate — % of tests that intermittently fail. (4) Mean time to detect — how long between a bug being introduced and found. (5) Automation coverage of critical paths. (6) Release cycle time — from commit to production. (7) CI pipeline duration trend. Tools: Grafana + InfluxDB for time-series data, Allure for test reports, or a custom dashboard in your preferred stack. Review metrics in sprint retrospectives.