40 questions with answers for candidates with 2 years of experience — 7 easy, 32 medium, 1 hard.
What interviewers expect: 2 years experience
Expect deeper scenario questions: choosing techniques for complex rules, state transition models, risk-based prioritisation under deadlines and working with unstable builds. Interviewers also look for API testing, SQL and some automation exposure, and for clear thinking about test coverage and traceability. You may be asked to review a user story live and point out missing acceptance criteria, or to explain how you handled flaky builds.
This set is weighted towards Black-Box Test Techniques (7), Fundamentals of Testing (6), White-Box, Experience and Collaboration-Based Testing (6), Managing the Test Activities (5).
State transition testing Risk-based prioritisation Traceability and coverage API and SQL checks
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
How do you report test status to non-technical stakeholders?
I focus on decisions they need to make. I use a short dashboard: overall status in plain words, coverage of key requirements, open critical defects and their business impact, top risks with mitigation, and what is needed from them. I avoid jargon, use simple charts and trends, and keep detailed data available for anyone who wants it. Different audiences may need different levels of detail.
02
A review is led by the author, and its goals are to educate the team and reach consensus. Which review type is it?
It is a walkthrough. Walkthroughs are led by the author, and their objectives include educating reviewers, building consensus, generating new ideas, motivating authors and detecting anomalies. Individual preparation is optional. If a trained moderator led it with technical experts to make technical decisions, it would be a technical review; if it followed a fully formal process with metrics, it would be an inspection.
03
Calculate a three-point estimate where optimistic is 6, most likely is 9 and pessimistic is 18 person-days.
DevOps joins development and operations through a CI/CD pipeline. Benefits for testing: fast feedback on code quality, shift-left through automated component tests and static analysis on every commit, stable environments through automation, more visibility of non-functional qualities and less repetitive manual work. Risks: the pipeline must be defined and maintained, CI/CD tools must be set up, and automation needs extra resources. Manual testing from the user's perspective is still needed.
05
The requirements say the system must be 'fast' and 'user-friendly'. What do you do?
I would log these as anomalies in a review because they are not testable. I would ask stakeholders for measurable criteria, for example 'search results appear within 2 seconds for 95 percent of requests at 1,000 concurrent users' and 'a new user completes registration in under three minutes without help'. Testable requirements make test design, acceptance and sign-off objective and prevent disputes later.
06
A developer says your defect cannot be reproduced. What do you do?
I would re-check that I can reproduce it, then add missing details: exact build version, environment, browser or device, user role, test data, timestamps, logs and a screen recording. I would check whether it is intermittent and note the frequency. If needed, I would reproduce it live with the developer. If it truly cannot be reproduced, we can keep it open with monitoring rather than close it.
07
What does the principle 'tests wear out' mean, and what was it called earlier?
In v4.0 the old 'pesticide paradox' was renamed 'tests wear out'. If the same tests are repeated many times, they become less effective at finding new defects because the code they exercise has already been fixed. Testers should modify existing tests and test data and write new tests. The exception is automated regression testing, where repeating the same tests is valuable because the goal is to confirm nothing has broken.
08
How do you learn from sample exams instead of just counting your score?
After each timed attempt, review every question, including correct guesses. For each mistake, note the learning objective, the chapter and why the right option is correct in the syllabus text. Group mistakes by chapter to find weak areas, re-read those sections, and redo similar questions after a few days. Aim for consistent scores of 32 or more out of 40 before the real exam.
09
What is branch testing and how is branch coverage measured?
A branch is a transfer of control between two nodes in the control flow graph. Branches can be unconditional, like straight-line code, or conditional, like the true and false outcomes of an if or the cases of a switch. Branch coverage = branches exercised / total branches x 100. Branch testing designs tests so that every branch, including the hidden false path of an if without else, is exercised.
The exam has 40 multiple-choice questions, each worth one point. The duration is 60 minutes, and candidates taking it in a non-native language usually get 25 percent extra time, making 75 minutes. The pass mark is 65 percent, which means 26 correct answers. There is no negative marking. Questions are mapped to learning objectives at K1, K2 and K3 levels.
11
Write a test charter for an exploratory session on a checkout page.
Charter: Explore the checkout page with different coupon and payment combinations to discover pricing and rounding errors. Time box: 60 minutes. Focus areas: coupon stacking, expired coupons, quantity changes after applying a coupon, currency rounding, and using the browser back button. Record test ideas, defects, questions and areas covered. Debrief with the test lead after the session to agree next charters.
12
Build a decision table for a loan rule: approve if salary is at least 30,000 and credit score is at least 700; refer if only one is met; otherwise reject.
Conditions R1 R2 R3 R4
Salary >= 30000 T T F F
Score >= 700 T F T F
Actions
Approve X - - -
Refer to officer - X X -
Reject - - - X
Two Boolean conditions give 2 x 2 = 4 rules, so 4 test cases give 100 percent decision table coverage.
13
A field accepts integers from 5 to 15. List the 3-value BVA test values.
In 3-value BVA, each boundary gives the boundary value plus both neighbours. Lower boundary 5 gives 4, 5 and 6. Upper boundary 15 gives 14, 15 and 16. So the six values are 4, 5, 6, 14, 15 and 16. Compared with 2-value BVA (4, 5, 15, 16), the extra values 6 and 14 help detect mistakes in comparison operators inside the range.
14
Testing found 80 defects and users found 20 more after release. What is the defect detection percentage?
DDP = defects found in testing / (defects found in testing + defects found after release) x 100
= 80 / (80 + 20) x 100
= 80 / 100 x 100
= 80 percent
So testing caught 80 percent of known defects. Tracking DDP across releases shows whether test effectiveness is improving.
15
Give a checklist you would use to review a user story.
Is it written as 'As a [role], I want [goal], so that [benefit]'? Does it follow INVEST: independent, negotiable, valuable, estimable, small and testable? Are acceptance criteria clear, measurable and testable? Are error flows and edge cases covered? Are terms consistent with the glossary? Are dependencies and non-functional needs stated? Are vague words like 'quickly' or 'etc.' present? Log each anomaly with location, description and a suggestion.
16
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.
17
Your defect tracker is full of duplicate defects from several testers. How do you fix this?
I would set up a short daily triage to merge duplicates and link them to one master defect. Testers should search existing defects by module and keywords before logging, and use clear titles in a standard format such as 'Module - action - result'. Defined components and labels make searching easier. Tracking duplicate rates also shows whether the guidance is working.
18
What happens in test monitoring, test control and test completion?
Test monitoring gathers information about testing to check progress and whether exit criteria are met, using metrics like test case progress, defect counts, coverage and cost. Test control uses that information to give guidance and corrective actions, such as reprioritising tests or changing the schedule. Test completion collects data from finished activities to consolidate experience, testware and other information, usually at milestones like release or end of iteration.
19
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.
20
Write a BDD scenario for locking an account after three failed login attempts.
Feature: Account lockout
Scenario: Lock account after three failed attempts
Given a registered user with an active account
When the user enters a wrong password 3 times in a row
Then the account is locked
And the message 'Account locked. Try again after 30 minutes' is shown
Given sets the context, When is the action and Then is the expected outcome.
21
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.
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.
23
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.
24
Tell me about a time a test design technique helped you find a defect.
Situation: I was testing a scholarship form where students aged 17 to 25 were eligible. Task: design efficient tests for the age rule. Action: I applied boundary value analysis and tested 16, 17, 25 and 26. Result: 25 was wrongly rejected because the code used 'less than 25'. The developer fixed it, and I shared the BVA checklist with the team so others used it too.
25
Which test estimation techniques are described in CTFL v4.0?
Estimation based on ratios uses historical figures, such as a development-to-test effort ratio. Extrapolation uses measurements from the current project, for example averaging the last three iterations. Wideband Delphi is an expert-based technique where experts estimate separately and iterate until consensus; Planning Poker is an Agile variant. Three-point estimation uses optimistic, most likely and pessimistic values to calculate a weighted estimate and its standard deviation.
26
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.
27
Tell me about an exploratory testing session that found a critical defect.
Situation: a ticket booking app had passed all scripted tests. Task: run a one-hour exploratory session on seat selection. Action: I tried quick double taps, switching networks and booking the same seat from two devices. Result: two users could book the same seat. I logged a detailed report with videos, it was fixed before release, and concurrency tests were added to the regression suite.
28
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.
29
What is exploratory testing and when is it most useful?
In exploratory testing, tests are designed, executed and evaluated at the same time while the tester learns about the test object. It is often structured as session-based testing with a time box, a test charter and a debrief. It is most useful when specifications are few or poor, under time pressure, or to complement formal techniques. Its success depends on the tester's experience, domain knowledge, curiosity and analytical skills.
30
The product owner writes vague acceptance criteria such as 'search should work well'. What do you do?
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.
31
What is checklist-based testing and what are its risks?
In checklist-based testing, the tester designs and runs tests to cover the conditions on a checklist built from experience, user needs or knowledge of why software fails. Items should be specific and testable, not vague or automatable by tools. Checklists give some consistency and guidance when detailed test cases are missing, but they become less effective over time as developers learn to avoid those mistakes, so they must be updated regularly.
32
Marks from 0 to 100 give: 0-39 fail, 40-59 pass, 60-100 distinction. How many partitions and 2-value boundary values are there?
Valid partitions: 0-39, 40-59 and 60-100, plus two invalid partitions: below 0 and above 100, so 5 partitions. Boundaries in 2-value BVA: -1, 0, 39, 40, 59, 60, 100 and 101, which is 8 values. Five tests give 100 percent EP coverage, and eight tests give 100 percent 2-value boundary coverage. Note that output partitions like fail, pass and distinction also guide the partitioning.
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.
34
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.
35
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.
36
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.
A retrospective is held at the end of an iteration, release or project to discuss what went well, what did not and how to improve. For testing, the benefits include more effective and efficient testing, better testware, team bonding, better quality of the test basis and stronger cooperation between developers and testers. Results should be recorded and the improvement actions tracked so that they are actually carried out.
38
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.
39
How do you use the ISTQB glossary to prepare effectively?
Each learning objective lists keywords that you must know. Make flashcards for them with the exact glossary definition and one example from your own work, such as 'test basis: the user story for checkout'. Review them daily with spaced repetition. Pay attention to similar terms, like test condition versus test case, and confirmation versus regression testing, because exams use them as distractors.
40
Discounts depend on several combined business rules such as membership, coupon and festival offers. Which technique do you choose?
Decision table testing fits best, because the outcome depends on combinations of conditions. I would list the conditions and actions, build the full table, remove infeasible combinations, minimise columns where a condition does not matter, and turn each column into a test case. The table also exposes gaps or contradictions in the rules, which I would raise with the business analyst before testing.
Frequently asked questions
What is asked in ISTQB interviews for 2 years of experience?
Expect deeper scenario questions: choosing techniques for complex rules, state transition models, risk-based prioritisation under deadlines and working with unstable builds. Interviewers also look for API testing, SQL and some automation exposure, and for clear thinking about test coverage and traceability. You may be asked to review a user story live and point out missing acceptance criteria, or to explain how you handled flaky builds.
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 2 years of experience?
Focus first on State transition testing, Risk-based prioritisation, Traceability and coverage, API and SQL checks.