40 questions for QA Lead interviews — 23 medium, 17 hard.
About the QA Lead role
A QA lead plans and manages testing for a product or release, guides a team of testers, sets standards and gives the release recommendation. Interviews focus on test strategy and planning, estimation, risk-based prioritisation, metrics, defect triage, handling pressure from stakeholders and mentoring. Expect scenario questions on missed deadlines, production incidents and building a QA process from scratch, plus examples of improving quality with data.
Test strategy Estimation Risk management Team leadership Stakeholder reporting
Solved for this roleStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
A test strategy is a high-level document, often at organisation or product level, that defines the general approach: test levels, types, tools, environments, automation approach and standards. It changes rarely. A test plan is project or release specific: scope, schedule, resources, entry and exit criteria, risks and deliverables. The plan follows the strategy and applies it to a particular release.
Keep it short and decision-oriented. Show open bugs by severity, the created versus resolved trend, blockers with owners and dates, defect leakage from the last release and modules with the most defects. Give a clear recommendation, such as ready, ready with known issues or not ready, with reasons. Use a shared dashboard for detail, and one slide or email summary for leaders who need only the risk picture.
Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.
09
What is defect prevention and what practical techniques does a QA team use?
Defect prevention focuses on stopping defects from being introduced instead of only finding them. Practical techniques include requirement reviews and clear acceptance criteria, Three Amigos sessions, design and code reviews, unit testing standards, coding checklists from past bugs, root cause analysis of escaped defects, and training on common mistakes. Track whether repeated defect types fall over time to prove the effort works.
Won't Fix means the bug is acknowledged as real, but the team decides not to fix it, usually because the impact is very low, the feature is being retired or the cost of fixing is higher than the benefit. The decision is made by the product owner, often in triage with dev and QA leads. The tester should make sure the reason is recorded and, if user-facing, documented as a known issue.
11
Production has a critical bug. What are your steps?
Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.
Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.
A QA lead reviews requirements and plans testing, including scope, estimates, resources and risks. They assign work, set standards for test cases and bug reports, and review test artefacts. During execution, they track progress, run triage and remove blockers. At the end, they give a clear release recommendation, prepare closure reports and drive lessons learned. They also mentor the team and improve the process over time.
An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.
15
Customer records are being moved from an old system to a new one. How do you test the migration?
Compare record counts per table before and after. Check field mapping, data types, formats, encodings and default values for a sample of records, including edge cases like nulls, special characters and very old records. Verify relationships are kept, such as each order still linked to its customer. Run key business reports in both systems and compare totals. Test the rollback plan and confirm the new application works with migrated data.
16
The same bug keeps reopening across three sprints. What do you do?
Stop the retest loop and call a short session with the developer, lead and product owner. Check whether the fix addresses the root cause or only the symptom, whether everyone agrees on the expected behaviour and whether different environments or data are involved. Run a root cause analysis and agree on clear acceptance tests before the next fix. Add an automated regression check so it cannot silently return.
17
What is the difference between a defect and a production incident?
A defect is a flaw in the software that makes it behave differently from the requirement, whether found in testing or production. A production incident is an event that disrupts or degrades service for users, such as an outage or a failed payment flow. An incident may be caused by a defect, but also by infrastructure, configuration or third-party failures. Incidents are handled by an incident process first, then linked to defects for the fix.
18
The test environment is down for two days just before release. What do you do?
Escalate immediately with the impact on the schedule. While it is down, prepare test data, review and update test cases, and test what you can elsewhere: API tests against another environment, UI on a developer machine or a staging copy. Track the lost hours in the status report. When the environment returns, run smoke first, then the prioritised list, and ask whether the release date or scope needs to change.
A bug bash is a short, time-boxed session where people from across the team, including developers, product and support, test the product together to find as many issues as possible before a release. To run one, share a build, scope and test accounts, assign focus areas, give a simple bug template and a shared board, then triage findings at the end. It brings fresh eyes and finds usability issues formal tests miss.
Check that each requirement is clear, complete, consistent and testable. Look for vague words like fast or user-friendly, missing error handling, undefined limits, conflicting rules and missing roles or states. For each requirement ask how you would test it and what the expected result is. Record questions in a review log and get answers from the business analyst before writing test cases, so ambiguity does not turn into defects later.
22
Tell me about a time you organised or ran a bug bash before a release.
Situation: a new seller onboarding flow was due in a week and only two testers had seen it. Task: I wanted wider coverage quickly. Action: I set up a one-hour bug bash with developers, product and support, shared test accounts, focus areas and a simple bug form, then triaged findings with the lead. Result: we found 18 issues, including two blockers on low-end phones, and fixed them before launch.
23
How do you test an application when requirements change frequently?
Note the order ID and compare the UI value, the API response and the database value to find where they differ. Check if the UI calculates the total on the screen instead of using the saved value, whether taxes, discounts or rounding are applied at different layers and whether a later update job changed the record. Log the bug with all three values, because invoices and reports will use the database figure.
25
Tell me about a time you had to push back on a release date.
Model answer: Situation: a loan app release was planned on Friday, but the EMI schedule showed wrong values for some tenures. Task: give an honest recommendation. Action: I presented the failing cases, the number of affected customers and the compliance risk in the go or no-go meeting, and proposed a three-day delay with a fix plan. Result: management agreed, the fix shipped on Monday, and no complaints came in.
26
How do you decide testing is complete when some bugs are still open?
Testing is complete when agreed exit criteria are met, not when the bug count is zero. Check that planned tests ran, critical and high bugs are fixed or formally accepted, and remaining open bugs have workarounds and low user impact. Present the list with risk to the product owner, who decides on release. Record accepted bugs as known issues, so nothing is hidden and they are planned for a later release.
Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.
30
What is idempotency in APIs and how do you test it?
An operation is idempotent if repeating the same request gives the same result as doing it once. GET, PUT and DELETE should be idempotent; POST usually is not. To test, send the same request several times and check the server state does not change after the first call. For payments, check that retrying with the same idempotency key does not create a second charge, which protects users during network retries.
31
Explain three-point estimation for testing with an example.
Three-point estimation uses an optimistic (O), most likely (M) and pessimistic (P) estimate for each task. The weighted formula is (O + 4M + P) divided by 6. If testing a module would take 4 days at best, 6 days most likely and 14 days at worst, the estimate is (4 + 24 + 14) / 6 = 7 days. It includes uncertainty in a single number and is often combined with a work breakdown of test activities.
Run a backlog grooming session with the product owner. Close bugs that are obsolete, no longer reproducible or for retired features. Merge duplicates. Group the rest by module and user impact, and ask whether a few related bugs can be fixed together as one story. Agree to reserve a small share of each sprint for bug fixes. Set an ageing rule, for example review any bug older than 90 days.
A workload model describes the realistic load to simulate: which user journeys run, their mix in percentages, the number of concurrent users, request rates, think times, data volumes and the ramp-up pattern. For example, 60 percent browse, 25 percent search, 10 percent add to cart and 5 percent checkout at a peak of 2,000 concurrent users. It is built from production analytics and business forecasts, and wrong models produce meaningless results.
35
SQL: find orders whose total does not match the sum of their order items.
SELECT o.order_id, o.total_amount,
SUM(i.quantity * i.unit_price) AS items_total
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount <> SUM(i.quantity * i.unit_price);
36
Tell me about a device-specific bug you found and how you reported it.
Model answer: Situation: users of one budget phone model reported that the camera upload screen was black. Task: reproduce it. Action: I borrowed the same model, found the issue only appeared when the battery saver was on, and logged the bug with the device model, OS version, logs and a video. Result: the developer fixed the camera initialisation, and we added that model to our device matrix.
37
Describe how you contributed in a sprint retrospective to improve quality.
Model answer: Situation: our sprints kept ending with stories stuck in testing. Task: suggest a fix in the retrospective. Action: I showed that most stories reached QA in the last two days and proposed smaller stories, early test case sharing and developers deploying to QA daily. Result: the team tried it next sprint, and the number of stories carried over dropped from five to one.
Mutation testing measures the quality of a test suite. A tool makes small changes, called mutants, to the code, such as changing greater than to greater than or equal, and runs the tests. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, which shows a weak spot in the tests. The mutation score is killed mutants divided by total mutants. It is strong but slow, so teams apply it to critical modules.
39
The developer says "it's not a bug". What do you do?
Collect exact details: user, time, device, browser and request IDs. Compare production with QA for configuration, feature flags, data volume, third-party integrations, versions and caching. Ask for production logs and error traces through the support or dev team. Try to reproduce in QA with production-like data or in a staging environment. Once found, add a test for the gap and fix the environment difference if one caused it.
Frequently asked questions
What does a QA Lead do?
A QA lead plans and manages testing for a product or release, guides a team of testers, sets standards and gives the release recommendation. Interviews focus on test strategy and planning, estimation, risk-based prioritisation, metrics, defect triage, handling pressure from stakeholders and mentoring. Expect scenario questions on missed deadlines, production incidents and building a QA process from scratch, plus examples of improving quality with data.
Which skills are tested in a QA Lead interview?
Expect questions on Test strategy, Estimation, Risk management, Team leadership, Stakeholder reporting. Most rounds also ask you to explain a project and solve one practical problem live.
How do I prepare for a QA Lead interview?
Revise STLC and Test Planning, Bug Life Cycle and Jira, Testing Types, Agile, SQL and API Testing first using the topic sheets, practise the questions on this page aloud, then do one full mock interview to practise timing.