Skip to content
ISTQB
All coursesPlacement Report
‹ Back to previous sectionCourse homeAll page URLs

ISTQB Technical Round Questions & Answers

40 questions for the technical round stage — 8 easy, 26 medium, 6 hard.

About the technical round round

The technical round is the core of a ISTQB interview: concept questions with follow-ups, a live hands-on task and a deep dive into one of your projects. Interviewers check depth, not just definitions.

Tips for the technical round round

  • Say your approach out loud before you start writing.
  • After a correct answer, expect 'why?' and 'what if?' follow-ups; go one level deeper than the question.
  • Pick one project you can explain end to end, including what you would do differently.
  • If you get stuck, explain what you would try next instead of going silent.
Solved — technical roundStart 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 is exploratory testing and when is it most useful?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
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.
02

How does testing relate to quality assurance and quality control?

Fundamentals of TestingMedium
Save to ▾
Show answer
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.
03

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?

Black-Box Test TechniquesMedium
Save to ▾
Show answer
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.
04

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.

Black-Box Test TechniquesMedium
Save to ▾
Show answer
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.
05

Free shipping applies for orders of 499 rupees or more, otherwise a fee of 40 applies. Design tests using EP and BVA.

Black-Box Test TechniquesMedium
Save to ▾
Show answer
Partitions: 0 or less is invalid, 1 to 498 pays 40, and 499 or more ships free. EP tests: 0 rejected, 250 pays 40, 800 free. 2-value BVA adds 0 and 1 at the lower edge and 498 and 499 at the free shipping boundary. Combined minimal set: 0, 1, 250, 498, 499 and 800, each with the expected fee clearly stated.
06

A review is led by the author, and its goals are to educate the team and reach consensus. Which review type is it?

Static TestingEasy
Save to ▾
Show answer
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.
07

What does the principle 'tests wear out' mean, and what was it called earlier?

Fundamentals of TestingMedium
Save to ▾
Show answer
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 many tests are needed for full statement and branch coverage of this nested code?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
if a > 0: if b > 0: s1 else: s2 else: s3 Statement coverage needs 3 tests, because s1, s2 and s3 are on different paths. Branch coverage also needs 3: (a > 0, b > 0), (a > 0, b <= 0) and (a <= 0). With full if-else structures, both criteria need the same number of tests.
09

What formats can acceptance criteria take?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
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.
10

What do the K-levels K1, K2 and K3 mean in the CTFL syllabus?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
K-levels describe the cognitive level of each learning objective. K1 is remember: recall a term or fact, such as listing test levels. K2 is understand: explain, compare, classify or give examples, such as distinguishing project and product risks. K3 is apply: use a procedure in a given situation, such as deriving boundary values or calculating a three-point estimate. Most exam questions are K2.
11

How is configuration management handled in a DevOps environment?

Defect and Configuration ManagementHard
Save to ▾
Show answer
In DevOps, configuration management is largely automated within the CI/CD pipeline. Source code, test scripts, pipeline definitions and infrastructure as code are all in version control. Each build gets a unique version, artefacts are stored in a repository, and environments are created from versioned templates. This makes test results reproducible and lets teams trace exactly which code, tests and configuration produced a given result.
12

Exit criteria are not met, but the business wants to release tomorrow. What do you do?

Managing the Test ActivitiesHard
Save to ▾
Show answer
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.
13

You have three years of testing experience and three weeks to prepare for CTFL. How do you plan?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
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.
14

A manager says, 'Testing found zero defects in this release, so the software is defect-free.' How do you respond?

Fundamentals of TestingMedium
Save to ▾
Show answer
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'.
15

A module of 15,000 lines of code has 45 defects. Calculate its defect density and explain how you would use it.

Defect and Configuration ManagementMedium
Save to ▾
Show answer
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.
16

What is the test pyramid?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
The test pyramid shows that tests have different granularity and that a healthy suite has many small, fast, isolated tests at the bottom, such as unit or component tests, and fewer large, slow, complex end-to-end tests at the top, such as UI tests. Middle layers often cover API or integration tests. The pyramid helps teams plan automation so the suite is fast, stable and cheap to maintain.
17

Show the TDD red-green-refactor cycle with a small example.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
# 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.
18

Why is not every failed test a defect in the software?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
A failure can be caused by the test itself or the environment, not the test object. Common causes include wrong expected results, outdated test data, incorrect test scripts, misconfigured environments, network issues or unavailable third-party services. CTFL v4.0 therefore talks about anomalies, which are analysed before being reported as defects. Logging every failure as a defect without analysis creates false positives and wastes developer time.
19

Walk through the steps of running a technical review of a design document.

Static TestingMedium
Save to ▾
Show answer
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.
20

Find the minimum tests for statement and branch coverage when there are two independent if statements in sequence.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
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.
21

Explain defect density and defect detection percentage.

Defect and Configuration ManagementHard
Save to ▾
Show answer
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.
22

A defect you closed last week appears again in a new build. What could be the cause and what do you do?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
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.
23

What are the main forms of acceptance testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
User acceptance testing is done by intended users. Operational acceptance testing is done by operations staff and covers backup, restore, installation and disaster recovery. Contractual and regulatory acceptance testing checks contract criteria or legal rules. Alpha testing is done by potential users at the developer's site, and beta testing by users at their own locations. Acceptance testing mainly builds confidence and validates fitness, not defect finding.
24

What is the difference between severity and priority?

Defect and Configuration ManagementEasy
Save to ▾
Show answer
Severity is the degree of impact the defect has on the system or its stakeholders, such as a crash or data loss. Priority is the urgency of fixing it, usually set by the business or product owner. Testers usually suggest severity, and priority is decided in triage. Example: a crash in a rarely used admin report is high severity but may be low priority.
25

Compare TDD, ATDD and BDD.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
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.
26

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?

Black-Box Test TechniquesHard
Save to ▾
Show answer
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.
27

How do you use the ISTQB glossary to prepare effectively?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
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.
28

Your defect tracker is full of duplicate defects from several testers. How do you fix this?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
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.
29

How do you report test status to non-technical stakeholders?

Managing the Test ActivitiesMedium
Save to ▾
Show answer
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.
30

The product owner writes vague acceptance criteria such as 'search should work well'. What do you do?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
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

How do you learn from sample exams instead of just counting your score?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
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.
32

What is branch testing and how is branch coverage measured?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
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.
33

How does a tester contribute to release and iteration planning?

Managing the Test ActivitiesMedium
Save to ▾
Show answer
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.
34

What is the difference between the test management role and the testing role in CTFL v4.0?

Fundamentals of TestingMedium
Save to ▾
Show answer
v4.0 describes roles, not job titles. The test management role owns the test process, the test team and leadership of test activities, mainly planning, monitoring and control, and completion. The testing role owns the engineering side: test analysis, design, implementation and execution. One person can hold both roles, and in Agile teams some management tasks are done by the team while cross-team coordination may sit with a test manager.
35

Your team must choose a new test automation tool. What factors do you consider?

Test Tools and Exam PreparationHard
Save to ▾
Show answer
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.
36

What categories of test tools does CTFL v4.0 describe?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
Test management tools, static testing tools, test design and implementation tools, test execution and coverage tools, non-functional testing tools, DevOps tools such as CI/CD pipelines and build tools, collaboration tools, and tools supporting scalability and deployment standardisation such as virtual machines and containers. Any tool that assists testing counts, even a spreadsheet. Tools improve efficiency, quality and repeatability.
37

A password must be 8 to 16 characters long. What are the 2-value BVA tests?

Black-Box Test TechniquesEasy
Save to ▾
Show answer
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.
38

What is the value of static testing?

Static TestingMedium
Save to ▾
Show answer
Static testing detects defects in the earliest phases, when they are cheapest to fix. It finds defects that dynamic testing cannot, such as unreachable code or defects in non-executable work products. It helps evaluate quality and build confidence, improves shared understanding among stakeholders, and gives fast feedback on code through static analysis in CI. Reviews cost effort, but the total cost of quality is usually lower.
39

Why does 100 percent branch coverage guarantee 100 percent statement coverage, but not the other way round?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
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.
40

What should a tester look for when reviewing code?

Static TestingHard
Save to ▾
Show answer
Check that inputs are validated and errors handled; comparisons at boundaries are correct, such as less than versus less than or equal; variables are initialised before use; there are no hard-coded passwords or secrets; logs avoid personal data; duplicated code is removed; complexity is reasonable; and unit tests cover new logic and edge cases. Combine manual review with static analysis tools for routine checks.

Frequently asked questions

What happens in the ISTQB technical round round?

The technical round is the core of a ISTQB interview: concept questions with follow-ups, a live hands-on task and a deep dive into one of your projects. Interviewers check depth, not just definitions.

How do I clear the technical round round?

Say your approach out loud before you start writing. After a correct answer, expect 'why?' and 'what if?' follow-ups; go one level deeper than the question. Pick one project you can explain end to end, including what you would do differently.

Which round comes next?

A typical order is online assessment, telephonic screening, one or two technical rounds, a managerial round and HR. Use the other round pages to practise each stage.

Practise every interview round

Online Assessment questionsTelephonic Interview questionsManagerial Round questionsRapid-Fire questionsHR & behavioural questionsFull mock interview

More ways to practise

Company-wise ISTQB questionsExperience-wise ISTQB questionsRole-wise ISTQB questionsCity-wise ISTQB questionsMost asked ISTQB questionsScenario-based questionsPractical / hands-on questionsHR & behavioural questionsISTQB mock interviewOnline assessment questionsTechnical round questionsManagerial round questionsISTQB topic sheets