40 questions with answers for candidates with 5 years of experience — 1 easy, 24 medium, 15 hard.
What interviewers expect: 5 years experience
Interviews target test lead skills: planning a release, risk analysis with stakeholders, defect triage, progress and completion reports, handling schedule slips and managing a small team. Expect questions on DevOps, shift-left, quality metrics like defect detection percentage and how you improved a test process with measurable results. Leadership examples should follow STAR format and show business impact.
This set is weighted towards Fundamentals of Testing (10), White-Box, Experience and Collaboration-Based Testing (8), Defect and Configuration Management (5), Managing the Test Activities (5).
Test planning and control Product and project risks Quality metrics Process improvement
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
What are false positives and false negatives in testing?
A false positive is a test result that reports a defect when none exists, for example a test failing because of wrong test data or an unstable environment. A false negative is a test that passes even though a defect is present, so the defect is missed. False positives waste time and reduce trust in tests; false negatives are more dangerous because defects escape to production.
02
Why is traceability between the test basis and testware important?
Traceability links test basis items such as requirements, risks and user stories to test conditions, test cases, results and defects. It lets teams measure coverage, assess the impact of changes, support audits in regulated domains and report progress in business terms, for example 'requirement R12 has three passed tests and one open defect'. When a requirement changes, traceability shows exactly which tests must be updated or re-run.
03
What is the difference between a test progress report and a test completion report?
A test progress report is produced regularly during testing, for example daily or per sprint. It covers the period, progress against plan, impediments, metrics, new or changed risks and planned work. A test completion report is prepared at the end of a test level, iteration or project. It summarises testing, evaluates quality against the plan, lists deviations, unmitigated risks, open defects, metrics and lessons learned.
04
A company uses its own testing terms that differ from ISTQB terms. How do you handle this in the exam and at work?
In the exam, always answer using the ISTQB syllabus and glossary definitions, because questions are written from them. At work, I would map local terms to ISTQB ones, for example 'sanity check' to a smoke test, and help the team build a shared glossary. A common vocabulary reduces misunderstandings, especially when working with distributed teams or clients.
05
What is testware? Give examples from different test activities.
Testware is any work product created during the test process. Examples: test plan and risk register from planning; progress reports and control directives from monitoring and control; prioritised test conditions from analysis; test cases, test charters and coverage items from design; test procedures, automated scripts, test suites and test data from implementation; test logs and defect reports from execution; and the test completion report with lessons learned from completion.
06
A manager says, 'Testing found zero defects in this release, so the software is defect-free.' How do you respond?
Testing shows the presence of defects, not their absence, so finding none only reduces the probability of undiscovered defects. I would also raise the absence-of-defects fallacy: did our tests cover real user needs? I would share coverage data, untested risk areas and whether our tests may have worn out. A more accurate statement is 'no defects were found within the agreed coverage and risk scope'.
07
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.
08
Your manual regression suite has not found a new defect for several releases. What do you do?
This points to the 'tests wear out' principle. I would review the suite against recent changes and defect data, refresh test data and steps, add tests for new features and risky areas, and run exploratory sessions to find new kinds of defects. Stable regression checks are still worth keeping and automating, because their job is to confirm unchanged areas still work, not to discover new defects.
09
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.
White-box testing considers the whole implementation, so it can find defects even when the specification is vague, outdated or incomplete. Coverage gives an objective measure of thoroughness. It can also be used in static testing, for example dry runs of code or pseudocode. Its main weakness is that it cannot detect omissions: if a requirement was never implemented, no white-box test will notice it.
11
Ten automated tests fail overnight, but the cause is an expired SSL certificate in the test environment. How should this be reported?
These failures are caused by the environment, not the test object, so they should not be logged as product defects. I would raise one environment issue with the infrastructure team, mark the test results as blocked or environment failure, and re-run after the certificate is renewed. I would also suggest monitoring certificate expiry so the same false positives do not recur.
Situation: our team wrote test cases with no clear technique, and suites kept growing. Task: improve efficiency. Action: I applied equivalence partitioning and boundary value analysis to the form validations and used decision tables for pricing rules, removing redundant tests. Result: we cut the regression suite by about 30 percent while finding more boundary defects, and my lead asked me to train two juniors.
13
Production defects increased over the last three releases. How do you analyse and act?
I would categorise escaped defects by module, root cause and the test level that should have found them, and calculate defect detection percentage per release. Typical findings are missing regression coverage, unclear requirements or environment differences. Actions might include requirement reviews, adding regression tests for each escaped defect, improving test data and environment parity, and tracking the trend to confirm improvement.
14
How does testing relate to quality assurance and quality control?
Testing is a form of quality control (QC): a product-oriented, corrective approach that checks work products. Quality assurance (QA) is process-oriented and preventive: it improves processes on the idea that a good process produces a good product. Test results are used by both. QC uses them to fix defects, and QA uses them as feedback on how well the development and test processes are performing.
15
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.
16
A decision table has three Boolean conditions. If condition A is false, the result is always 'reject'. How many columns does the minimised table have?
A full table has 2 to the power 3 = 8 columns. When A is false, the other two conditions do not matter, so those four columns merge into one column with dashes for B and C. When A is true, the four combinations of B and C remain. The minimised table has 4 + 1 = 5 columns, so 5 tests give full coverage, if all columns are feasible.
17
You identified 6 equivalence partitions and your tests exercise 4 of them. What is the coverage? Does adding a second test in the same partition help?
EP coverage = exercised partitions / identified partitions x 100 = 4 / 6 x 100 = 66.7 percent. Adding another test in an already covered partition does not increase coverage, because coverage counts partitions, not tests. To reach 100 percent you need tests in the two missing partitions. Exams often include such distractors to see if you count tests instead of coverage items.
18
Order these tests for execution: A (priority 1, depends on C), B (priority 2), C (priority 3), D (priority 2, depends on B). 1 is highest.
A has the highest priority but depends on C, so C must run first, followed by A. Next come the priority 2 tests: B, then D, because D depends on B. The execution order is C, A, B, D. ISTQB exams often include such questions; always satisfy dependencies first, then follow priority, and run the highest priority test as early as its dependencies allow.
19
The requirements are incomplete and release is in two days. How do you test?
I would use session-based exploratory testing. I would write short charters for the riskiest areas, agree priorities with the product owner, run time-boxed sessions, note defects and questions, and debrief after each session. I would add error guessing for common failure types and a quick checklist for critical flows, and report clearly which areas were covered and which risks remain.
20
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.
21
A test suite executes 8 of 10 executable statements and 3 of 4 branches. What are the coverage figures?
Statement coverage = 8 / 10 x 100 = 80 percent. Branch coverage = 3 / 4 x 100 = 75 percent. To raise them, look at the control flow graph to see which statements and which branch outcome were missed, then design inputs that force execution down those paths. Coverage tools in CI pipelines report these numbers automatically for each build.
22
Explain collaborative user story writing, the 3 Cs and INVEST.
User stories are written collaboratively by business, development and testing. The 3 Cs are Card (the medium describing the story), Conversation (how the story will be used, documented or verbal) and Confirmation (the acceptance criteria). A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. If stakeholders cannot say how to test a story, it is probably unclear or does not reflect real value.
23
Find the minimum tests for statement and branch coverage when there are two independent if statements in sequence.
if a > 0:
s1
if b > 0:
s2
Statement coverage: one test with a = 1 and b = 1 runs s1 and s2, so 1 test.
Branch coverage: each if needs a true and a false outcome. Tests (a = 1, b = 1) and (a = 0, b = 0) cover all four branches, so 2 tests.
24
A production hotfix must go live in three hours. How do you decide what to test?
I would do a quick impact analysis to see what the change touches, run confirmation tests for the defect, then a risk-based regression subset covering the changed module, its integrations and critical business flows like login and payment. I would use the automated smoke suite in the pipeline, record what was not covered, and plan fuller regression in the next regular release.
25
Derive test conditions for the requirement 'Users can transfer up to 50,000 rupees per day.'
Read the test basis and list testable aspects. Conditions: a transfer within the limit succeeds; a transfer of exactly 50,000 succeeds; a transfer above 50,000 is rejected with a clear message; several transfers in one day are added together against the limit; the limit resets the next day; zero or negative amounts are rejected. Prioritise them by risk, then design test cases with exact amounts using boundary value analysis.
26
A new tester has no domain knowledge and no detailed test cases. How can checklists help, and what is the risk?
A checklist of high-level conditions, such as validations, error messages, navigation and security basics, gives the new tester structure and consistency while learning the domain. Each run can vary slightly, which increases coverage. The risk is that checklists wear out as developers learn to avoid listed defects, so the team should update them with new defect patterns and pair the tester with an experienced colleague.
27
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.
28
Model an ATM PIN entry with three attempts as states and transitions. How many tests are needed for valid transitions coverage?
I would suggest a short three-amigos session with the product owner and a developer. Together we would turn the vague criterion into testable ones, for example 'searching by product name returns matching items sorted by relevance', 'no results shows a helpful message' and 'results load in under 2 seconds'. Writing them as Given/When/Then scenarios makes them clear and ready for ATDD.
30
Exit criteria are not met, but the business wants to release tomorrow. What do you do?
Testers provide information; the release decision belongs to stakeholders. I would prepare a short report showing which criteria are not met, open defects by severity, untested areas and the resulting risks, with possible mitigations such as feature flags, hotfix readiness or limited rollout. If stakeholders accept the risk, I would record the decision and the residual risks in the completion report.
31
Tell me about a time you delivered testing under a very tight deadline.
Situation: a regulatory change had to go live in five days. Task: test it without missing critical risks. Action: I ran a quick risk analysis with the product owner, focused on calculation rules and reports, automated repetitive data checks, and gave daily status updates. Result: we released on time with no production defects in high-risk areas, and lower-risk cosmetic issues were fixed in the next sprint.
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.
33
You join a Scrum team with two-week sprints. What testing activities would you do during a sprint?
I would join backlog refinement to review stories and acceptance criteria, help estimate test effort in sprint planning, write acceptance tests early, pair with developers on automation, test each story as soon as it is ready, keep regression running in the CI pipeline, run exploratory sessions on new features and share testing feedback in the retrospective. Testing runs continuously rather than at the end of the sprint.
34
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.
35
Your manager asks you to lower the severity of a defect to meet release targets. How do you respond?
Situation: before a release, my manager wanted a payment defect marked minor. Task: stay honest without creating conflict. Action: I explained the actual impact with data, how often it occurred and affected users, and suggested keeping severity accurate while lowering priority if the business accepted the risk, with a workaround documented. Result: the manager agreed, and the risk was recorded transparently.
36
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.
37
Tell me about a time you found an important defect. How did you report it?
Situation: while testing our final-year e-commerce project, I found checkout accepted expired coupon codes. Task: report it clearly before the demo. Action: I reproduced it three times and logged clear steps, expected and actual results, screenshots and the coupon data, and marked severity high because it meant revenue loss. Result: the developer fixed it within a day, and I added a regression test for coupon expiry.
38
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.
39
A field accepts integers from 1 to 99. Which set of values achieves 100 percent 2-value BVA coverage: {1, 99}, {0, 1, 99, 100}, {0, 50, 100} or {1, 2, 98, 99}?
The answer is {0, 1, 99, 100}. Two-value BVA needs each boundary value and its closest neighbour in the adjacent partition: 0 and 1 at the lower edge, 99 and 100 at the upper edge. {1, 99} misses the invalid neighbours, {0, 50, 100} misses 1 and 99, and {1, 2, 98, 99} stays inside the valid partition, which is closer to 3-value thinking.
40
A defect you closed last week appears again in a new build. What could be the cause and what do you do?
Possible causes include a code merge that overwrote the fix, a fix made only in one branch, or a deployment of an older artefact. I would re-open the defect with evidence and the build numbers, ask the team to check version control history, and add an automated regression test for the defect so it is caught immediately if it returns again.
Frequently asked questions
What is asked in ISTQB interviews for 5 years of experience?
Interviews target test lead skills: planning a release, risk analysis with stakeholders, defect triage, progress and completion reports, handling schedule slips and managing a small team. Expect questions on DevOps, shift-left, quality metrics like defect detection percentage and how you improved a test process with measurable results. Leadership examples should follow STAR format and show business impact.
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 5 years of experience?
Focus first on Test planning and control, Product and project risks, Quality metrics, Process improvement.