Skip to content

ISTQB Managerial Round Questions & Answers

35 questions for the managerial round stage — 3 easy, 20 medium, 12 hard.

About the managerial round round

The managerial round is usually with a hiring manager or team lead. It mixes real-work scenarios, prioritisation and stakeholder questions with behavioural questions about ownership, conflict and learning.

Tips for the managerial round round

  • Use the STAR format for every story: Situation, Task, Action, Result.
  • Show trade-offs: what you chose, what you gave up and why.
  • Be honest about mistakes and focus on what you changed afterwards.
  • Ask the manager about team goals and how success is measured in the role.
Solved — managerial 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

Your automated regression suite fails randomly, and the team no longer trusts it. What do you do?

Save to ▾
Show answer
Flaky tests are a known automation risk. I would quarantine flaky tests so they do not block the pipeline, then find the causes: hard-coded waits, shared test data, test order dependency or unstable environments. Fixes include explicit waits, independent test data, isolated environments and retries only for known infrastructure issues. I would track the flaky rate and return fixed tests to the main suite.
02

Explain the absence-of-defects fallacy.

Save to ▾
Show answer
It is a misconception that verifying software thoroughly and fixing every found defect guarantees success. A system can pass every test against its specification and still be useless if the specification was wrong or the users' real needs were missed. That is why testing must include validation as well as verification, for example early review of requirements with business stakeholders and user acceptance testing before release.
03

The requirements say the system must be 'fast' and 'user-friendly'. What do you do?

Save to ▾
Show answer
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.
04

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

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.
05

Tell me about a time a test design technique helped you find a defect.

Save to ▾
Show answer
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.
06

Tell me about a time you delivered testing under a very tight deadline.

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

Testers spent a day testing the wrong build version. How do you prevent this?

Save to ▾
Show answer
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.
08

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

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.
09

Production defects increased over the last three releases. How do you analyse and act?

Save to ▾
Show answer
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.
10

Show a simple CI pipeline step that runs automated tests on every push.

Save to ▾
Show answer
name: tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: '3.12' - run: pip install -r requirements.txt - run: pytest --junitxml=report.xml The pipeline fails if any test fails, giving fast feedback to the developer.
11

How did you give feedback on a senior colleague's document that had many issues?

Save to ▾
Show answer
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.
12

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

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.
13

A key tester resigns and a vendor will deliver a module late. How do you treat these risks?

Save to ▾
Show answer
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.
14

Management expects automation to replace all manual testers within six months. How do you respond?

Save to ▾
Show answer
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.
15

A developer says one value per partition is enough. Why might you still add boundary tests?

Save to ▾
Show answer
Equivalence partitioning assumes all values in a partition behave the same, but many defects occur at the edges, where developers write '>' instead of '>=' or use the wrong limit. One middle value like 35 in an 18 to 60 range will never reveal these. Boundary value analysis adds tests at 17, 18, 60 and 61, so the two techniques together give good coverage with few tests.
16

A static analysis tool reports 2,000 warnings on legacy code. What is your approach?

Save to ▾
Show answer
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.
17

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

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.
18

Tell me about a time you convinced developers to adopt a code coverage quality gate.

Save to ▾
Show answer
Situation: escaped defects kept coming from untested code paths. Task: improve unit testing without slowing the team. Action: I showed coverage reports linking low-coverage modules to production defects, proposed a gate of 80 percent branch coverage on new code only, and helped write the first tests. Result: within two months coverage on changed code rose sharply and escaped defects in those modules fell.
19

How would you combine test techniques for a new UPI payment feature?

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

Prepare a fault attack list for a file upload feature.

Save to ▾
Show answer
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.
21

The requirements are incomplete and release is in two days. How do you test?

Save to ▾
Show answer
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.
22

Ten automated tests fail overnight, but the cause is an expired SSL certificate in the test environment. How should this be reported?

Save to ▾
Show answer
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.
23

A production hotfix must go live in three hours. How do you decide what to test?

Save to ▾
Show answer
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.
24

Give an example of a high-severity low-priority defect and a low-severity high-priority defect.

Save to ▾
Show answer
High severity, low priority: the app crashes when exporting a report in a legacy format that almost nobody uses; the impact is severe but rarely triggered, so it can wait. Low severity, high priority: the company logo is misspelled on the home page before a major launch; functionality is unaffected, but brand impact makes it urgent. Severity reflects impact, priority reflects business urgency.
25

Your company is migrating customer data from a legacy system to the cloud. What testing is needed?

Save to ▾
Show answer
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.
26

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.

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.
27

Tell me about a time you introduced a new tool to your team.

Save to ▾
Show answer
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.
28

A developer says your defect cannot be reproduced. What do you do?

Save to ▾
Show answer
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.
29

Your team says reviews are a waste of time. How do you change their minds?

Save to ▾
Show answer
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.
30

How do you use the ISTQB glossary to prepare effectively?

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.
31

Tell me about an exploratory testing session that found a critical defect.

Save to ▾
Show answer
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.
32

Suggest a four-week study plan for a fresher preparing for CTFL v4.0.

Save to ▾
Show answer
Week 1: chapters 1 and 2, the seven principles, test activities, test levels and test types; make notes of key terms. Week 2: chapter 3 and black-box techniques, solving at least 30 EP, BVA, decision table and state transition problems. Week 3: white-box and experience-based techniques, chapters 5 and 6, with estimation and risk exercises. Week 4: three or more timed sample exams and revision of mistakes.
33

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

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.
34

How would your test approach differ for a medical device versus a startup mobile game?

Save to ▾
Show answer
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.
35

An amount field accepts 0.01 to 999.99 with two decimal places. What are the 2-value boundary values?

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

Frequently asked questions

What happens in the ISTQB managerial round round?

The managerial round is usually with a hiring manager or team lead. It mixes real-work scenarios, prioritisation and stakeholder questions with behavioural questions about ownership, conflict and learning.

How do I clear the managerial round round?

Use the STAR format for every story: Situation, Task, Action, Result. Show trade-offs: what you chose, what you gave up and why. Be honest about mistakes and focus on what you changed afterwards.

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.