Hard ISTQB Interview Questions

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.

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.

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.

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.

Non-functional tests are often left to the end, but late discovery of performance or security problems can threaten the whole project. v4.0 recommends starting early, even at component level, for example measuring response time of a key service. Some tests need special environments such as a usability lab. Many non-functional tests reuse functional tests but measure a different quality, like checking login speed under 500 concurrent users.

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.

I would push component tests and static analysis into the pipeline on every commit, build a test pyramid with many unit tests, fewer API tests and few UI tests, provision environments through infrastructure as code and add production monitoring. Testers shift from long test phases to continuous risk analysis, exploratory testing and quality coaching. I would plan training and track metrics like lead time and escaped defects.

Identify changed items from commits and change requests; use traceability to find affected requirements, components and interfaces; check dependency maps and defect history; rank the affected areas by risk; select automated regression for broad coverage plus targeted manual tests for high-risk flows; and document what is excluded and why. Impact analysis can also help decide whether a risky change should be made at all.

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.

Static analysis tools examine code without executing it, checking coding standards, complexity metrics, data flow anomalies, security vulnerabilities and duplication. In CI they run on every commit or pull request, giving fast feedback and blocking merges that fail quality gates. They support shift-left, but they produce false positives, so rules must be tuned, and they cannot judge whether the code actually meets user needs.

I would choose an inspection: a formal process with a trained moderator, defined roles, checklists, mandatory preparation, entry and exit criteria and collected metrics. Its aim is to find as many anomalies as possible and to provide documented evidence for audits. For a quick internal design idea, a walkthrough or informal review is enough, because the higher cost of inspection is justified only by high risk.

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.

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.

All states coverage requires every state to be visited. Valid transitions coverage, also called 0-switch coverage, requires every valid transition to be exercised. All transitions coverage requires every valid transition to be exercised and every invalid transition to be attempted, ideally one invalid transition per test to avoid fault masking. Full valid transitions coverage guarantees full all states coverage, and all transitions coverage is recommended for safety-critical software.

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 state table lists states as rows and events as columns, and each cell shows the resulting state or marks the transition as invalid. Example: a document workflow with states Draft, Review and Published, and events submit, approve and reject. Draft with approve is invalid. Valid cells are coverage items for valid transitions coverage; invalid cells are tested for all transitions coverage, one per test case.

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.

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.

First remove infeasible combinations, for example 'under 18' with 'retired'. Then minimise the table by merging columns where a condition has no effect on the action. Next, prioritise the remaining rules by risk and business value, testing high-impact rules first. I would also verify the rules with the business, since a large table often exposes contradictions or missing actions.

ATDD is a test-first approach. The team, including business, developers and testers, analyses the story and acceptance criteria in a specification workshop, then writes test cases before implementation. Positive tests come first, then negative tests and non-functional characteristics. Tests are written in a form stakeholders understand, cover every criterion without going beyond the story, and are often automated so they become executable requirements.

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.

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.

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.

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.

The quadrants group test types by whether they are business-facing or technology-facing, and whether they support the team or critique the product. Q1 (technology, support): component and component integration tests, usually automated. Q2 (business, support): functional tests, examples, user story tests, prototypes. Q3 (business, critique): exploratory, usability and user acceptance testing. Q4 (technology, critique): smoke tests and non-functional tests except usability, such as performance and security.

Risk analysis has two parts: risk identification, using brainstorming, workshops, interviews or cause-effect diagrams, and risk assessment, which categorises risks and estimates likelihood, impact and level, either quantitatively or qualitatively with a risk matrix. Risk control has risk mitigation, such as selecting test techniques, levels, types and testers by risk, and risk monitoring. Responses include mitigation by testing, acceptance, transfer and contingency plans.

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.

Include: summary of testing done and the scope; evaluation of product quality against the test plan and exit criteria; deviations from plan in schedule, effort or scope; impediments faced; metrics such as tests run, passed, failed, coverage and defects by severity; open defects with workarounds; unmitigated residual risks; testware handed over or archived; and lessons learned with improvement actions for the next release.

I would analyse the cause first: unstable builds, late delivery or underestimated effort. Then take control actions: reprioritise tests by risk so critical areas run first, request extra testers or environments, automate repetitive checks, raise blocking defects with developers, and, if needed, agree with stakeholders on reduced scope or a revised date. I would report the impact and residual risks transparently.

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.

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.

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.

Situation: two product owners wanted their features tested first in the same sprint. Task: decide fairly and keep the team focused. Action: I brought both to a short meeting, scored the features by business risk and release dates, and agreed a shared order with the delivery manager. I shared the plan with the team and tracked it daily. Result: both features shipped, and the risk-based method became our default.

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.

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.

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.

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.

Invite the test lead, a development lead and the product owner. Prepare a filtered list of new and re-opened defects before the meeting. For each defect, confirm it is valid and not a duplicate, agree severity and priority, assign an owner and a target release, or reject or defer it with a reason. Keep it time-boxed, record decisions in the tool, and review ageing critical defects regularly.

Situation: defects stayed open for weeks and reports were often incomplete. Task: speed up resolution. Action: I introduced a defect template, clear status rules, a twice-weekly triage meeting and a dashboard of defect age and re-open rate. I trained testers on writing reproducible reports. Result: average resolution time fell by about 40 percent, and developers stopped returning reports for missing information.

After CTFL you can take Advanced Level modules: Test Analyst, Technical Test Analyst and Test Management. Specialist modules include Test Automation Engineering, Performance Testing, Security Testing, Mobile Application Testing, Usability Testing and AI Testing, among others. Expert Level certifications follow for experienced professionals. Choose based on your role: automation engineers pick technical paths, while leads pick test management.

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.

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.

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.