40 questions with answers for candidates with 3 years of experience — 4 easy, 31 medium, 5 hard.
What interviewers expect: 3 years experience
At three years you are expected to own testing of a feature end to end: analyse requirements, write a lightweight test plan, estimate effort, coordinate with developers and report status. Questions cover estimation techniques, exit criteria, defect metrics and mentoring juniors, along with automation strategy and the test pyramid. Be ready with numbers from your projects, such as suite size and defects found.
This set is weighted towards Testing Throughout the SDLC (7), Black-Box Test Techniques (7), Static Testing (5), Test Tools and Exam Preparation (5).
Test estimation Entry and exit criteria Test pyramid Mentoring and reviews
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
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.
02
A password must be 8 to 16 characters long. What are the 2-value BVA tests?
The partitions by length are 0 to 7 (invalid), 8 to 16 (valid) and 17 or more (invalid). 2-value BVA takes each boundary and its closest neighbour: 7 and 8 for the lower boundary, 16 and 17 for the upper boundary. So test passwords of length 7, 8, 16 and 17 characters, keeping other rules such as character types valid so only the length varies.
03
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.
04
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.
05
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.
06
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.
07
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.
08
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.
09
Tell me about a time you introduced a new tool to your team.
Situation: test cases lived in spreadsheets and traceability was poor. Task: introduce a test management tool. Action: I compared options with the team, ran a two-week pilot on one module, migrated priority test cases, built simple dashboards and ran short training sessions. Result: the team adopted it within a month, and release reports that took a day now took an hour.
10
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.
11
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.
12
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.
13
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.
14
How does decision table testing work, and how is coverage measured?
Decision tables model combinations of conditions and the resulting actions, which suits business rules. Each column is a rule: one combination of conditions with its actions. With n Boolean conditions, a full table has 2 to the power n columns. Coverage items are the feasible columns, so coverage is exercised columns divided by feasible columns. Tables can be minimised by merging columns where a condition does not affect the outcome, shown with a dash.
15
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.
16
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.
17
An amount field accepts 0.01 to 999.99 with two decimal places. What are the 2-value boundary values?
The closest neighbour depends on the precision, here 0.01. Lower boundary: 0.00 (invalid) and 0.01 (valid). Upper boundary: 999.99 (valid) and 1000.00 (invalid). So the four test values are 0.00, 0.01, 999.99 and 1000.00. Always confirm the precision from the specification, because with whole numbers the neighbour would be 1, and with three decimals it would be 0.001.
18
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.
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.
20
Are there prerequisites for CTFL, and does the certificate expire?
There are no formal prerequisites for the Foundation Level exam; students, freshers and experienced professionals can all take it, although some practical testing exposure makes the syllabus easier. The CTFL certificate has lifetime validity and does not need renewal. It is the prerequisite for ISTQB Advanced Level and most Specialist certifications, so it is the starting point of the ISTQB path.
21
Show the TDD red-green-refactor cycle with a small example.
# Red: write a failing test first
def test_discount():
assert discount(1000) == 100
# Green: simplest code that passes
def discount(amount):
return amount * 0.10
# Refactor: improve design, test stays green
RATE = 0.10
def discount(amount):
return round(amount * RATE, 2)
Repeat the cycle for each new behaviour, such as no discount below 500.
22
What is static testing and how is it different from dynamic testing?
Static testing examines work products without executing them, through manual reviews or static analysis tools. Dynamic testing executes the software. Static testing finds defects directly, such as ambiguous requirements or coding standard violations, while dynamic testing causes failures whose defects are then located by debugging. Static testing works on non-executable products like requirements and test plans, and finds defects dynamic testing cannot, such as unreachable code.
23
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.
24
In a review, what is the difference between an anomaly and a defect?
Reviewers log anomalies: observations that differ from what they expected. Not every anomaly is a defect; some turn out to be misunderstandings, open questions or improvement suggestions. During communication and analysis the team decides each anomaly's status, owner and required action, and confirmed ones become defects for the author to fix. This keeps reviews constructive instead of treating every comment as the author's mistake.
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
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.
27
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.
28
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.
29
Your CI pipeline takes two hours because most automated tests are UI tests. What do you suggest?
The suite looks like an inverted test pyramid. I would push checks down: move business logic checks to unit tests, cover service rules with API tests, and keep only a small set of end-to-end UI tests for critical user journeys. I would also run tests in parallel and split suites into a fast smoke stage and a fuller nightly run. Feedback becomes faster and tests less flaky.
30
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.
31
How do you learn a new application quickly when you join a project?
Situation: I joined a project two weeks before a release. Task: become productive quickly. Action: I read user stories and help pages, did short exploratory sessions on main flows, built a mind map of features, asked a senior tester for the riskiest areas and reviewed recent defects. Result: within a week I was executing regression tests independently and found two defects in the first sprint.
32
Walk through the steps of running a technical review of a design document.
Plan: define scope, objective and exit criteria and choose reviewers with the right expertise. Initiate: share the document, checklist and timeline. Individual review: each reviewer logs anomalies in a shared tool. Communication and analysis: the moderator runs the meeting, the team discusses anomalies and agrees actions. Fixing and reporting: the author updates the document, defects are tracked, and results are checked against exit criteria.
33
An order can be placed, shipped, delivered, cancelled or returned. How would you test this workflow?
State transition testing fits because behaviour depends on the current state and events. I would draw the diagram, for example placed to shipped, shipped to delivered, placed to cancelled, delivered to returned, and build a state table. Tests cover every valid transition and attempt invalid ones, such as cancelling a delivered order or returning an undelivered one, checking the system rejects them correctly.
All three are test-first approaches. In TDD, developers write a failing unit test, write code to pass it, then refactor. In ATDD, acceptance tests are derived from acceptance criteria with the team and business before development starts. In BDD, desired behaviour is written as Given/When/Then scenarios in natural language that stakeholders understand and that can be turned into executable tests. All three support shift-left.
35
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.
36
Tell me about a time testing was squeezed at the end of a sprint. What did you do?
Situation: stories reached me only in the last two days of each sprint. Task: stop testing from being a bottleneck. Action: I proposed writing acceptance criteria and test cases during refinement, asked developers to merge smaller stories earlier, and automated API checks in the CI pipeline. Result: within three sprints, carried-over stories fell from five to one, and the team added early testing to its definition of done.
The two common formats are scenario-oriented, such as the Given/When/Then style used in BDD, and rule-oriented, such as a bullet-point verification list or a tabulated input-output mapping. Acceptance criteria define the scope of the story, reach consensus among stakeholders, describe positive and negative scenarios, serve as the basis for acceptance testing and support accurate planning and estimation. Teams can also use other formats as long as criteria are well defined and clear.
38
A module of 15,000 lines of code has 45 defects. Calculate its defect density and explain how you would use it.
Defect density = defects / size = 45 / 15 KLOC = 3 defects per KLOC. If other modules average 1 defect per KLOC, this module is a defect cluster, so I would increase test depth there, ask for a code review or refactoring, and add more regression tests. Compare density only across similar code, because language and complexity affect the numbers.
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.
40
Payment type has 3 partitions (card, UPI, wallet) and customer type has 2 (new, existing). What is the minimum number of tests for Each Choice coverage?
Each Choice coverage needs every partition from each input used at least once, and one test can cover one partition of each input at the same time. So the minimum equals the largest number of partitions: 3. Example tests: card with new, UPI with existing, wallet with new. Covering all combinations would need 3 x 2 = 6 tests, which is not required for Each Choice.
Frequently asked questions
What is asked in ISTQB interviews for 3 years of experience?
At three years you are expected to own testing of a feature end to end: analyse requirements, write a lightweight test plan, estimate effort, coordinate with developers and report status. Questions cover estimation techniques, exit criteria, defect metrics and mentoring juniors, along with automation strategy and the test pyramid. Be ready with numbers from your projects, such as suite size and defects found.
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 3 years of experience?
Focus first on Test estimation, Entry and exit criteria, Test pyramid, Mentoring and reviews.