40 questions with answers for candidates with 10+ years of experience — 11 medium, 29 hard.
What interviewers expect: 10 years experience
Senior test manager and QA head interviews focus on organisation-wide quality: test policy, governance, metrics programmes, test process improvement models, risk management in regulated domains, vendor management and building testing capability. Expect questions about business impact, cost of quality and how you transformed QA for Agile and DevOps delivery. Show clear examples with numbers and results.
This set is weighted towards Managing the Test Activities (9), Testing Throughout the SDLC (6), Test Tools and Exam Preparation (5), Static Testing (5).
Quality governance Test process improvement Cost of quality QA transformation
Solved at this levelStart 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.
✓ 3 questions free • Unlock the rest in seconds
01
You have three years of testing experience and three weeks to prepare for CTFL. How do you plan?
Experience helps, but the exam follows syllabus wording, not company practice. Week 1: read chapters 1 to 3 and the glossary terms in each learning objective. Week 2: study chapters 4 to 6, practise BVA, decision tables, state transitions, coverage and estimation calculations. Week 3: take timed official sample exams, analyse every wrong answer against the syllabus, and revise weak chapters.
02
What test case prioritisation strategies are there?
Risk-based prioritisation orders tests by the results of risk analysis, running tests for the highest risks first. Coverage-based prioritisation orders by coverage, running tests that achieve the most coverage first; additional coverage prioritisation picks each next test by the extra coverage it adds. Requirements-based prioritisation follows the priorities of requirements set by stakeholders. Dependencies can force a lower-priority test to run first.
Test analysis answers 'what to test': it analyses the test basis, identifies testable features, defines and prioritises test conditions, and evaluates the test basis for defects. Test design answers 'how to test': it turns test conditions into test cases, identifies coverage items, defines test data requirements and designs the test environment. Example: the condition 'login with a locked account' becomes, in design, a case with exact inputs and the expected error message.
04
Why does 100 percent branch coverage guarantee 100 percent statement coverage, but not the other way round?
Every statement lies on at least one branch, so exercising all branches executes all statements. The reverse fails when a decision has an empty outcome. Example: 'if x > 10: print(big)' followed by 'print(done)'. One test with x = 15 runs every statement, giving 100 percent statement coverage, but the false branch is never taken, so branch coverage is only 50 percent. This is called subsumption.
05
How do you run an effective defect triage meeting?
Invite the test lead, a development lead and the product owner. Prepare a filtered list of new and re-opened defects before the meeting. For each defect, confirm it is valid and not a duplicate, agree severity and priority, assign an owner and a target release, or reject or defer it with a reason. Keep it time-boxed, record decisions in the tool, and review ageing critical defects regularly.
06
What triggers maintenance testing, and what decides its scope?
Maintenance testing covers changes to a system already in production. Triggers are modifications such as enhancements, corrective fixes or hotfixes; upgrades or migrations of the operational environment, including data migration; and retirement of an application, which may need archiving and restore tests. Scope depends on the risk of the change, the size of the existing system and the size of the change, with impact analysis guiding regression selection.
07
Your organisation is moving from the V-model to DevOps. How should the test strategy change?
I would push component tests and static analysis into the pipeline on every commit, build a test pyramid with many unit tests, fewer API tests and few UI tests, provision environments through infrastructure as code and add production monitoring. Testers shift from long test phases to continuous risk analysis, exploratory testing and quality coaching. I would plan training and track metrics like lead time and escaped defects.
08
Explain defect density and defect detection percentage.
Defect density is the number of defects per unit of size, such as per thousand lines of code or per function point. It helps find defect clusters and compare components. Defect detection percentage (DDP) is defects found by testing divided by all defects found, including those found after release, times 100. A falling DDP means more defects are escaping, which signals weaker test effectiveness.
09
Describe how you improved the defect management process in a team.
Situation: defects stayed open for weeks and reports were often incomplete. Task: speed up resolution. Action: I introduced a defect template, clear status rules, a twice-weekly triage meeting and a dashboard of defect age and re-open rate. I trained testers on writing reproducible reports. Result: average resolution time fell by about 40 percent, and developers stopped returning reports for missing information.
Functional testing checks what the system should do, covering completeness, correctness and appropriateness. Non-functional testing checks how well it behaves, using ISO/IEC 25010 characteristics such as performance efficiency, usability, security, reliability, compatibility, maintainability and portability. Black-box testing is specification-based, and white-box testing is structure-based. Any test type can be applied at any test level, with a different focus at each.
11
A static analysis tool reports 2,000 warnings on legacy code. What is your approach?
I would not try to fix everything at once. First, tune the rule set to remove irrelevant rules and false positives. Then classify warnings by severity and fix security issues and likely defects first. I would set a quality gate that blocks only new issues in changed code, so the codebase improves gradually. Trend reports each sprint show management steady progress.
The quadrants group test types by whether they are business-facing or technology-facing, and whether they support the team or critique the product. Q1 (technology, support): component and component integration tests, usually automated. Q2 (business, support): functional tests, examples, user story tests, prototypes. Q3 (business, critique): exploratory, usability and user acceptance testing. Q4 (technology, critique): smoke tests and non-functional tests except usability, such as performance and security.
13
Describe a time you led a test team through conflicting priorities.
Situation: two product owners wanted their features tested first in the same sprint. Task: decide fairly and keep the team focused. Action: I brought both to a short meeting, scored the features by business risk and release dates, and agreed a shared order with the delivery manager. I shared the plan with the team and tracked it daily. Result: both features shipped, and the risk-based method became our default.
14
How are CTFL v4.0 exam questions distributed across chapters?
Approximately: Chapter 1, Fundamentals of Testing, 8 questions; Chapter 2, Testing Throughout the SDLC, 6; Chapter 3, Static Testing, 4; Chapter 4, Test Analysis and Design, 11; Chapter 5, Managing the Test Activities, 9; Chapter 6, Test Tools, 2. Chapters 4 and 5 carry half the marks and include most K3 questions, so practise techniques and estimation thoroughly.
15
Midway through the test cycle you are 30 percent behind schedule. What test control actions can you take?
I would analyse the cause first: unstable builds, late delivery or underestimated effort. Then take control actions: reprioritise tests by risk so critical areas run first, request extra testers or environments, automate repetitive checks, raise blocking defects with developers, and, if needed, agree with stakeholders on reduced scope or a revised date. I would report the impact and residual risks transparently.
16
How do you use a state table to find invalid transitions?
A state table lists states as rows and events as columns, and each cell shows the resulting state or marks the transition as invalid. Example: a document workflow with states Draft, Review and Published, and events submit, approve and reject. Draft with approve is invalid. Valid cells are coverage items for valid transitions coverage; invalid cells are tested for all transitions coverage, one per test case.
17
A key tester resigns and a vendor will deliver a module late. How do you treat these risks?
Both are project risks. For the resignation, I would mitigate by documenting knowledge, pairing another tester for a handover and adjusting assignments; a contingency plan could be a short-term contractor. For the vendor delay, I would monitor delivery dates, prepare stubs to test our side, reorder testing to start other modules first and agree a contingency with management.
18
Management expects automation to replace all manual testers within six months. How do you respond?
I would explain the risks of unrealistic expectations. Automation is excellent for stable, repetitive regression checks, but exploratory, usability and new-feature testing still need human judgment. Introducing a tool also needs time for framework design, training and maintenance. I would propose a phased plan: automate a high-value smoke and regression set first, measure the benefits, and redeploy testers to higher-value testing.
19
Describe product risk analysis and product risk control.
Risk analysis has two parts: risk identification, using brainstorming, workshops, interviews or cause-effect diagrams, and risk assessment, which categorises risks and estimates likelihood, impact and level, either quantitatively or qualitatively with a risk matrix. Risk control has risk mitigation, such as selecting test techniques, levels, types and testers by risk, and risk monitoring. Responses include mitigation by testing, acceptance, transfer and contingency plans.
20
Describe how you convinced a team to adopt shift-left testing.
Situation: our releases had many defects traced to unclear requirements. Task: reduce them without slowing delivery. Action: I showed data that about 40 percent of defects started in requirements, piloted requirement reviews and three-amigos sessions in one team, and tracked the results. Result: requirement-related defects dropped by roughly half over two releases, and other teams adopted the practice.
21
How did you give feedback on a senior colleague's document that had many issues?
Situation: a senior architect's design missed several error-handling flows. Task: give feedback respectfully. Action: I grouped comments by theme, framed them as questions with concrete examples, noted the strong sections, and offered to discuss in person rather than only posting comments. Result: he accepted most points, appreciated the clear feedback, and later invited me to review his designs earlier.
22
An insurance premium depends on five Boolean conditions. The full decision table has 32 columns. How do you keep testing manageable?
First remove infeasible combinations, for example 'under 18' with 'retired'. Then minimise the table by merging columns where a condition has no effect on the action. Next, prioritise the remaining rules by risk and business value, testing high-impact rules first. I would also verify the rules with the business, since a large table often exposes contradictions or missing actions.
23
Your team says reviews are a waste of time. How do you change their minds?
I would bring data: track defects found in reviews and estimate what they would have cost if found in system testing or production. I would also make reviews lighter: smaller chunks, checklists, time-boxed sessions, asynchronous tool-based reviews and static analysis to automate routine checks. Matching the review type to each work product keeps the cost low, and sharing the savings usually wins support.
24
You must estimate test effort for a new type of project with no historical data. How do you do it?
Without history, ratio and extrapolation techniques are not reliable, so I would use expert-based techniques. With Wideband Delphi or Planning Poker, testers and developers estimate independently, discuss big differences and repeat until they agree. I would add three-point estimates for uncertain areas, list assumptions and risks, and re-estimate using extrapolation after the first iterations produce real data.
25
How do static analysis tools fit into a CI pipeline, and what are their limits?
Static analysis tools examine code without executing it, checking coding standards, complexity metrics, data flow anomalies, security vulnerabilities and duplication. In CI they run on every commit or pull request, giving fast feedback and blocking merges that fail quality gates. They support shift-left, but they produce false positives, so rules must be tuned, and they cannot judge whether the code actually meets user needs.
26
What certification path can you follow after CTFL?
After CTFL you can take Advanced Level modules: Test Analyst, Technical Test Analyst and Test Management. Specialist modules include Test Automation Engineering, Performance Testing, Security Testing, Mobile Application Testing, Usability Testing and AI Testing, among others. Expert Level certifications follow for experienced professionals. Choose based on your role: automation engineers pick technical paths, while leads pick test management.
27
Discount depends on customer type (regular, gold, platinum) and whether the order exceeds 1,000 rupees. How many rules does the full decision table have?
When conditions are not Boolean, multiply the number of values of each condition. Customer type has 3 values and the order condition has 2, so the full table has 3 x 2 = 6 rules. Each rule becomes one test case for 100 percent decision table coverage. If, for example, platinum always gets the same discount regardless of amount, those two columns can be merged, giving 5.
28
Explain the levels of test independence with their benefits and drawbacks.
Independence ranges from none (authors test their own work), some (a peer in the same team), high (testers outside the team but in the organisation) to very high (testers from outside the organisation). Independent testers find different kinds of failures and challenge assumptions. Drawbacks include isolation from developers, communication delays, adversarial relationships and developers losing responsibility for quality. Most projects mix levels: developers test components, independent testers handle system and acceptance testing.
29
Your team must choose a new test automation tool. What factors do you consider?
Fit with the technology stack and application types; team skills and learning curve; integration with CI/CD, test management and defect tools; reporting; licensing and total cost of ownership; vendor support or community health for open-source tools; scalability; and compliance needs. I would run a proof of concept on real scenarios, then a pilot on one project before rolling it out widely.
30
How does a tester contribute to release and iteration planning?
In release planning, testers help write testable user stories and acceptance criteria, take part in product and quality risk analyses, estimate test effort for stories, define the test approach and plan release testing. In iteration planning, they join detailed risk analysis of stories, check testability, break stories into testing tasks, estimate testing effort and identify the functional and non-functional aspects to test.
Include: summary of testing done and the scope; evaluation of product quality against the test plan and exit criteria; deviations from plan in schedule, effort or scope; impediments faced; metrics such as tests run, passed, failed, coverage and defects by severity; open defects with workarounds; unmitigated residual risks; testware handed over or archived; and lessons learned with improvement actions for the next release.
32
How would your test approach differ for a medical device versus a startup mobile game?
Testing is context dependent. For a medical device I would use formal documented plans, high independence, strict traceability to requirements, demanding coverage targets and evidence for regulators. For a mobile game I would use lightweight plans, exploratory testing, beta users, automation of core flows and fast releases. Factors that drive the choice include risk, regulations, budget, time, team skills, the SDLC and the technical environment.
33
How do you use impact analysis to decide regression scope?
Identify changed items from commits and change requests; use traceability to find affected requirements, components and interfaces; check dependency maps and defect history; rank the affected areas by risk; select automated regression for broad coverage plus targeted manual tests for high-risk flows; and document what is excluded and why. Impact analysis can also help decide whether a risky change should be made at all.
34
How would you combine test techniques for a new UPI payment feature?
I would use black-box techniques: EP and BVA for amount limits, decision tables for rules such as daily limits and first-time payee checks, and state transitions for payment status from initiated to success, failed or pending. Developers would add white-box branch coverage in unit tests. I would add error guessing and exploratory sessions on network drops, duplicate taps and timeouts, prioritised by risk.
35
Prepare a fault attack list for a file upload feature.
List likely failures and design tests for each: empty file; file just above the size limit; very large file; wrong extension; correct extension with wrong content; file names with spaces, Unicode or very long names; duplicate names; upload interrupted by network loss; many uploads at once; malicious files such as scripts; and uploads without login or with an expired session. Prioritise by risk.
36
Your company is migrating customer data from a legacy system to the cloud. What testing is needed?
This is maintenance testing triggered by migration. I would check data completeness with record counts and checksums, data accuracy through sampling and reconciliation reports, transformation rules, performance on the new platform and rollback procedures. Operational acceptance testing covers backup, restore and failover. Regression testing of key functions on migrated data is needed, and retiring the old system may need archiving tests.
37
Model an ATM PIN entry with three attempts as states and transitions. How many tests are needed for valid transitions coverage?
This is a configuration management failure. I would ensure every build has a unique version shown in the application and in the release notes, that deployments to test environments are automated and logged, and that test runs record the build version tested. Entry criteria should include confirming the build version. A deployment notification in the team channel also helps everyone stay aligned.
39
What makes an inspection different from other review types?
Inspection is the most formal review type. It follows the complete review process, uses defined roles and checklists, requires individual preparation, applies entry and exit criteria, and collects metrics such as anomalies found per page to improve both the development and inspection processes. The author cannot act as review leader or scribe. It suits safety-critical and high-risk work products, but it costs the most effort.
40
On a safety-critical medical project, developers want to do all testing themselves to save time. How do you advise?
For safety-critical products, regulations and risk usually demand higher independence. I would keep developer component testing and static analysis, but recommend that system and acceptance testing be done by an independent test team, possibly with external assessors for certification. I would explain the benefits: a fresh perspective, fewer shared assumptions and objective evidence for regulators, while keeping close communication to avoid isolation and delays.
Frequently asked questions
What is asked in ISTQB interviews for 10+ years of experience?
Senior test manager and QA head interviews focus on organisation-wide quality: test policy, governance, metrics programmes, test process improvement models, risk management in regulated domains, vendor management and building testing capability. Expect questions about business impact, cost of quality and how you transformed QA for Agile and DevOps delivery. Show clear examples with numbers and results.
How many questions should I practise before a ISTQB interview?
Work through all 40 questions here, then the company-wise sets for the employers you are targeting. Quality matters more than count: be able to explain why each answer is right.
Which topics matter most for 10+ years of experience?
Focus first on Quality governance, Test process improvement, Cost of quality, QA transformation.