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.

33Questions · All Levels

QUESTIONS / qa-methodology

QA Methodology & Strategy interview questions.

Questions on test planning, risk-based testing, test pyramid, shift-left, exploratory testing, and quality metrics.

Practice Live with AI

Free to start · 7-day trial on paid plans

APPROACH / QA-METHODOLOGY.STRATEGY

How to approach methodology questions.

QA methodology questions are often phrased innocuously ("how do you write a test plan?") and weighted heavily. They are the round where hiring managers find out whether you treat quality as a process you follow or as a system you can reason about. The candidates who advance are the ones who answer with trade-offs and counter-examples, not with definitions copied from an ISTQB syllabus.

Risk-based testing is the load-bearing concept. Be ready to explain how you assess probability and business impact for a feature before you write a single test, how you document the risk register so it survives sprint planning, and how you defend a decision to skip coverage on a low-risk path. "We test everything" is the answer that loses the round. "We deliberately under-test the admin export job because it ships behind a feature flag and runs once a quarter" is the answer that wins it.

Test design techniques still matter, but only if you can show them in motion. Equivalence partitioning, boundary value analysis, decision tables, and state transition testing are not vocabulary words; they are tools you apply to a specific input space. If an interviewer asks you to design tests for a discount calculator, walk through partitions out loud, name the boundaries you would cover, and call out the combinations a decision table would surface that single-axis tests miss.

Metrics are where senior candidates earn the offer. Know which metrics drive behaviour you want (escaped defect rate, mean time to detect, flake rate, test runtime budget) and which ones drive behaviour you do not (raw test count, code coverage as a target, pass rate without context). Have an opinion on Goodhart's Law as it applies to QA dashboards. If you have ever seen coverage gamed, lead with that story.

What hiring managers are listening for

Risk-based prioritisation
You can defend skipping coverage on a path because the risk maths supports it.
Test design fluency
You apply equivalence partitioning and decision tables to concrete inputs in real time.
Metric judgment
You distinguish between metrics that drive learning and metrics that drive theatre.
Strategy under constraint
You can produce a defensible plan when the team has half the time and twice the scope.

Common pitfall

Do not lead with the V-model or the test pyramid as if they answer the question. Both are useful frames, but interviewers ask "tell me about your QA approach" precisely to see whether you can move beyond them. Use the pyramid to anchor your answer for thirty seconds, then talk about the specific decisions you made on a real project where the pyramid did not fit cleanly.

Practice by Tool & Technology

Dive deeper with tool-specific interview questions.

All Tool & Technology Questions Playwright Interview Questions Selenium Interview Questions Postman Interview Questions JMeter Interview Questions Jenkins Interview Questions

EXEC.NOW

Ready to Ace Your QA Interview?

Stop reading answers, start practicing them live with AI that knows QA.

Join 1,200+ QA engineers already practicing with AssertHired.

Start your free QA interview

FREE.TO.START · 7.DAY.TRIAL ON PAID PLANS

Written by Aston Cook, Senior QA EngineerLast updated: March 2026

QA Methodology & Strategy interview questions.

How to approach methodology questions.

What hiring managers are listening for

More Question Categories

Practice by Tool & Technology

Ready to Ace Your QA Interview?