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

ISTQB Interview Questions & Answers

All 200 unique questions in one place — 60 easy, 95 medium, 45 hard — grouped by topic.

Practise by topic

Fundamentals of Testing · 26Testing Throughout the SDLC · 25Static Testing · 24Black-Box Test Techniques · 25White-Box, Experience and Collaboration-Based Testing · 25Managing the Test Activities · 26Defect and Configuration Management · 24Test Tools and Exam Preparation · 25

Practise the way your interview works

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
Solved overallStart 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 are the typical objectives of testing according to the ISTQB CTFL v4.0 syllabus?

Fundamentals of TestingEasy
Save to ▾
Show answer
Testing objectives include evaluating work products such as requirements and code, triggering failures and finding defects, ensuring required coverage of the test object, reducing the risk of poor quality, verifying that specified requirements are met, checking compliance with contracts or regulations, giving stakeholders information for decisions, building confidence in quality, and validating that the test object works as users expect. Objectives vary with context, test level and the SDLC model.
02

What is the difference between testing and debugging?

Fundamentals of TestingEasy
Save to ▾
Show answer
Testing triggers failures caused by defects (dynamic testing) or finds defects directly in work products (static testing). Debugging is a development activity that reproduces a failure, diagnoses the root cause and fixes the defect. After the fix, testers run confirmation testing to check the fix and regression testing to check nothing else broke. In short, testing finds and reports problems, while debugging locates and removes them.
03

Explain error, defect, failure and root cause with an example.

Fundamentals of TestingEasy
Save to ▾
Show answer
A human makes an error (mistake), for example misreading a requirement. The error produces a defect (fault or bug) in a work product such as code or a document. When defective code is executed it may cause a failure, meaning the system does something wrong or fails to do something. The root cause is the fundamental reason for the error, such as time pressure or unclear requirements. Failures can also come from environmental conditions like radiation.
04

List the seven testing principles in CTFL v4.0.

Fundamentals of TestingEasy
Save to ▾
Show answer
1) Testing shows the presence, not the absence, of defects. 2) Exhaustive testing is impossible, so use test techniques, prioritisation and risk. 3) Early testing saves time and money. 4) Defects cluster together in a few components. 5) Tests wear out, so update them or write new ones. 6) Testing is context dependent. 7) Absence-of-defects fallacy: a defect-free system can still fail if it does not meet user needs.
05

Explain the absence-of-defects fallacy.

Fundamentals of TestingEasy
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.
06

What does 'defects cluster together' mean and how is it used?

Fundamentals of TestingEasy
Save to ▾
Show answer
A small number of components usually contain most of the defects or cause most operational failures, similar to the Pareto principle. Predicted and observed defect clusters are an important input to risk-based testing, so testers focus more effort on those areas. Example: in a banking app, the interest calculation and payment modules may hold most reported defects, so they get deeper and more frequent regression coverage.
07

Name the main test activities in the ISTQB test process.

Fundamentals of TestingEasy
Save to ▾
Show answer
The test process has seven activity groups: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion. They are often iterative or done in parallel rather than strictly sequential. How they are carried out depends on context, such as the SDLC, product risks, budget, time, team skills and regulations, so an Agile team performs them in small loops in every iteration.
08

What is the whole team approach?

Fundamentals of TestingEasy
Save to ▾
Show answer
In the whole team approach, any team member with the right knowledge can perform any task, and everyone is responsible for quality. The team shares a physical or virtual workspace, and testers work closely with business representatives to create acceptance tests and with developers to agree the test strategy and automation. It improves communication and uses combined skills, although safety-critical contexts may still need higher test independence.
09

What is the difference between verification and validation?

Fundamentals of TestingEasy
Save to ▾
Show answer
Verification checks whether the system meets its specified requirements: 'Are we building the product right?' Validation checks whether the system meets user and stakeholder needs in its operational environment: 'Are we building the right product?' Both are testing objectives. Example: verification confirms the eight-character password rule is implemented, while validation checks that real users can actually register easily on a mobile phone.
10

A developer misreads a tax rule, codes the wrong formula, and a customer later sees an incorrect invoice total. Identify the error, defect and failure.

Fundamentals of TestingEasy
Save to ▾
Show answer
The error is the human mistake: the developer misreading the tax rule. The defect is the wrong formula in the code. The failure is the incorrect invoice total seen when the code runs. The root cause might be an ambiguous requirement or time pressure. Remember for the exam that not every defect causes a failure; it does so only when the defective code executes under certain conditions.
11

Match these tasks to test activities: identifying test conditions, creating test data and suites, comparing actual and expected results, archiving testware.

Fundamentals of TestingEasy
Save to ▾
Show answer
Identifying and prioritising test conditions is test analysis. Creating test data, arranging test procedures and assembling test suites is test implementation. Running tests and comparing actual with expected results is test execution. Archiving testware, handing it over and recording lessons learned is test completion. Exams often mix design and implementation: designing test cases is test design, while preparing them to run is implementation.
12

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

How is test analysis different from test design?

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

What is testware? Give examples from different test activities.

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

Why is traceability between the test basis and testware important?

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

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

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

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'.
19

Your manual regression suite has not found a new defect for several releases. What do you do?

Fundamentals of TestingMedium
Save to ▾
Show answer
This points to the 'tests wear out' principle. I would review the suite against recent changes and defect data, refresh test data and steps, add tests for new features and risky areas, and run exploratory sessions to find new kinds of defects. Stable regression checks are still worth keeping and automating, because their job is to confirm unchanged areas still work, not to discover new defects.
20

Derive test conditions for the requirement 'Users can transfer up to 50,000 rupees per day.'

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

How do you perform a simple root cause analysis on a production failure?

Fundamentals of TestingMedium
Save to ▾
Show answer
Collect the failure details and logs, reproduce the issue and identify the defect. Then ask 'why' repeatedly until you reach a process cause. Example: a wrong discount was shown; why? the code used an old rule; why? the requirement changed without notice; why? there was no change review step. Action: add change notifications and a review step. Fixing root causes prevents whole families of similar defects.
22

Tell me about a time you found an important defect. How did you report it?

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

Describe a situation where a developer rejected your defect. How did you handle it?

Fundamentals of TestingMedium
Save to ▾
Show answer
Situation: a developer marked my defect 'works as designed'. Task: resolve it without conflict. Action: I re-read the user story, attached the acceptance criteria that contradicted the behaviour, and discussed it calmly with the developer and product owner, focusing on user impact rather than blame. Result: the product owner confirmed it was a defect, and we clarified the story wording so similar confusion did not happen again.
24

Explain the levels of test independence with their benefits and drawbacks.

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

On a safety-critical medical project, developers want to do all testing themselves to save time. How do you advise?

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

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

Fundamentals of TestingHard
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.
27

How does the choice of SDLC model affect testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
In sequential models like waterfall and the V-model, testers join early for reviews and planning, but dynamic testing happens later once code exists. In iterative and incremental models such as Scrum, every iteration delivers a working increment, so static and dynamic testing happen at all levels in each iteration, regression testing is critical and automation is usually needed. The model affects scope, timing, documentation, techniques and automation.
28

What is the shift-left approach in testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Shift-left means performing testing earlier in the SDLC. Practices include reviewing specifications from a tester's perspective, writing test cases before code, using CI/CD for fast feedback, running static analysis before dynamic testing and starting non-functional testing at component level. It costs extra effort early, but saves much more later, because a defect found in requirements is far cheaper to fix than one found in production.
29

How do retrospectives help testing?

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

What are the five test levels in CTFL v4.0?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Component testing checks individual units in isolation. Component integration testing checks interfaces and interactions between components. System testing checks overall behaviour, both functional and non-functional. System integration testing checks interfaces with other systems and external services. Acceptance testing focuses on validation and readiness for deployment. Each level has its own objectives, test basis, test objects, typical defects and responsibilities.
31

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

What is the difference between confirmation testing and regression testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Confirmation testing checks that an original defect has been fixed, by re-running the failed tests or new tests that cover the change. Regression testing checks that a change, including a fix, has not caused adverse effects elsewhere, in the same component, connected components or the environment. Regression suites grow and run often, so they are strong candidates for automation, typically inside a CI pipeline.
33

A test checks that the loan module correctly sends customer data to an external credit bureau API. Which test level is this?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
This is system integration testing, because it tests the interface between our system and an external system, the credit bureau API. If it checked the interface between two internal modules of our own application, it would be component integration testing. In exam questions, keywords such as 'external system', 'third-party service' or 'other systems' point to system integration testing.
34

Business users test a new payroll system in their own office before go-live. What kind of testing is this?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
This is user acceptance testing, because intended users validate that the system meets their needs in a realistic environment before deployment. If it were a commercial product released to external customers at their own sites for feedback, it would be beta testing. If potential users tested it at the developer's site, it would be alpha testing. Look for who tests and where.
35

Why do you want to start your career in software testing?

Testing Throughout the SDLCEasy
Save to ▾
Show answer
Model answer: I enjoy finding how things break and thinking from the user's side. During my degree I tested our team project and found issues others missed, which built my interest. I studied the ISTQB Foundation syllabus to learn standard terms and techniques. I want to grow from manual testing into automation and domain expertise, and testing lets me understand the whole product and the full SDLC.
36

Which good testing practices apply regardless of the SDLC model?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
CTFL v4.0 lists these: for every software development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a level begin during the corresponding development phase; and testers are involved in reviewing work products as soon as drafts are available. Together these practices support early testing and quality control in waterfall, V-model and Agile projects alike.
37

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

What are the benefits and risks of DevOps for testing?

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

Explain the four test types defined in CTFL v4.0.

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

How does component integration testing differ from system integration testing?

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Component integration testing focuses on interfaces between components of the same system and is usually done by developers or testers who know the architecture, often with stubs and drivers. System integration testing focuses on interfaces with other systems and external services, such as payment gateways or government APIs, and needs production-like environments. Incremental integration, top-down or bottom-up, is preferred over big-bang because it localises defects.
41

You join a Scrum team with two-week sprints. What testing activities would you do during a sprint?

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

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

Testing Throughout the SDLCMedium
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.
43

Write a BDD scenario for locking an account after three failed login attempts.

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

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

Tell me about a time testing was squeezed at the end of a sprint. What did you do?

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

Describe how you convinced a team to adopt shift-left testing.

Testing Throughout the SDLCMedium
Save to ▾
Show answer
Situation: our releases had many defects traced to unclear requirements. Task: reduce them without slowing delivery. Action: I showed data that about 40 percent of defects started in requirements, piloted requirement reviews and three-amigos sessions in one team, and tracked the results. Result: requirement-related defects dropped by roughly half over two releases, and other teams adopted the practice.
47

What triggers maintenance testing, and what decides its scope?

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

Why does CTFL v4.0 recommend starting non-functional testing early?

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

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

Testing Throughout the SDLCHard
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.
50

Your organisation is moving from the V-model to DevOps. How should the test strategy change?

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

How do you use impact analysis to decide regression scope?

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

What is static testing and how is it different from dynamic testing?

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

Which work products can be examined by static testing?

Static TestingEasy
Save to ▾
Show answer
Almost any work product that can be read and understood: requirements, user stories, acceptance criteria, architecture and design documents, source code, test plans, test cases, test charters, backlog items, contracts, project plans, schedules and budgets. Static analysis tools need work products with a formal structure, such as code or models with defined syntax. Products that are hard for humans to interpret, like third-party executable code, are not suitable for review.
54

Why is early and frequent stakeholder feedback important?

Static TestingEasy
Save to ▾
Show answer
Early and frequent feedback catches misunderstandings about requirements before they become expensive. Without it, the product may not match what stakeholders want, leading to costly rework, missed deadlines, blame games and even project failure. Regular feedback through reviews, demos and backlog refinement keeps the team focused on the most valuable features and builds a shared understanding of what is being built.
55

What are the roles in a formal review?

Static TestingEasy
Save to ▾
Show answer
The manager decides what is reviewed and provides resources. The author creates and fixes the work product. The moderator, or facilitator, ensures meetings run effectively, mediating and managing time. The scribe, or recorder, collects anomalies and records decisions. Reviewers perform the review and may be team members, experts or stakeholders. The review leader takes overall responsibility, deciding who is involved and organising the review. One person can hold several roles.
56

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

Give a checklist you would use to review a user story.

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

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

What types of defects are typically found by static testing?

Static TestingMedium
Save to ▾
Show answer
Requirements defects such as inconsistencies, ambiguities, contradictions, omissions and duplicates; design defects like inefficient database structures or poor modularisation; coding defects such as variables with undefined values, unreachable or duplicated code and excessive complexity; deviations from standards; incorrect interface specifications; security vulnerabilities like buffer overflows; and gaps in test coverage, such as missing tests for an acceptance criterion.
60

Describe the activities of the review process in CTFL v4.0.

Static TestingMedium
Save to ▾
Show answer
Planning defines scope, purpose, quality characteristics, exit criteria, effort and timeframe. Review initiation ensures everyone has access and is ready. In individual review, each reviewer assesses the work product and logs anomalies, recommendations and questions. Communication and analysis discusses anomalies and decides their status and actions. Fixing and reporting creates defect reports, the author fixes them, and results are reported against exit criteria.
61

Compare the four review types in CTFL v4.0.

Static TestingMedium
Save to ▾
Show answer
An informal review has no defined process or formal output and aims to detect anomalies. A walkthrough is led by the author and aims to educate, build consensus, generate ideas and detect anomalies. A technical review is done by technically qualified reviewers led by a moderator, aiming at consensus and technical decisions. An inspection is the most formal, follows the full process, collects metrics and aims to find the maximum number of anomalies.
62

What are the success factors for reviews?

Static TestingMedium
Save to ▾
Show answer
Define clear objectives and measurable exit criteria; pick a review type that fits the objective, work product and people; review small chunks so reviewers stay focused; give feedback to authors so they improve; allow enough preparation time; secure management support; make reviews part of the culture to promote learning; and train participants for their roles. Review results must never be used to evaluate the performance of individuals.
63

In a review, what is the difference between an anomaly and a defect?

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

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

Static TestingMedium
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.
65

A review meeting turns into people blaming the author. How do you handle it as moderator?

Static TestingMedium
Save to ▾
Show answer
I would refocus the discussion on the work product, not the person, remind everyone of the review objectives, and record the anomaly neutrally. Afterwards I would speak privately with the people involved. To prevent repeats, I would set ground rules, train participants and make sure review results are never used to judge individuals. Authors in a safe culture share work openly, so reviews find more defects.
66

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

Static TestingMedium
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.
67

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

Show two defects a static analysis tool can find without running the code.

Static TestingMedium
Save to ▾
Show answer
def get_discount(amount): if amount > 1000: rate = 0.1 return amount * rate # rate undefined when amount <= 1000 def old_helper(): return 0 print('done') # unreachable code The tool flags a possibly undefined variable, a data flow anomaly, and unreachable code. Both are found statically, before any test is executed.
69

Tell me about a time a review you did prevented a serious problem.

Static TestingMedium
Save to ▾
Show answer
Situation: reviewing a refund user story, I noticed it did not say how partial refunds work on discounted orders. Task: clarify it before development started. Action: I logged the gap, set up a 15-minute call with the product owner and developer, and we added three acceptance criteria with worked examples. Result: the feature shipped without the refund calculation errors that had hurt an earlier release.
70

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

Static TestingMedium
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.
71

What makes an inspection different from other review types?

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

How do static analysis tools fit into a CI pipeline, and what are their limits?

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

Which review type would you choose for safety-critical requirements, and why?

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

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

Static TestingHard
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.
75

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

Which black-box test techniques are covered in CTFL v4.0?

Black-Box Test TechniquesEasy
Save to ▾
Show answer
CTFL v4.0 covers four black-box techniques: equivalence partitioning, boundary value analysis (2-value and 3-value), decision table testing and state transition testing. They derive tests from the specification without looking at the internal structure, so tests stay valid even when the implementation changes. Use case testing, which was in older syllabi, is no longer part of the v4.0 Foundation syllabus.
77

Explain equivalence partitioning and its coverage.

Black-Box Test TechniquesEasy
Save to ▾
Show answer
Equivalence partitioning divides data into partitions whose values are expected to be processed the same way, so one value per partition is enough. Partitions can cover inputs, outputs, configuration items or time, and include valid and invalid partitions. They must be non-empty and must not overlap. Coverage is partitions exercised divided by partitions identified. With several inputs, Each Choice coverage requires every partition of every input to be used at least once.
78

An age field accepts 18 to 60. Apply equivalence partitioning. How many tests give 100 percent EP coverage?

Black-Box Test TechniquesEasy
Save to ▾
Show answer
There are three partitions: below 18 (invalid), 18 to 60 (valid) and above 60 (invalid). Pick one value from each, for example 10, 35 and 70. So three test cases give 100 percent EP coverage. Test invalid partitions one at a time so that one invalid value does not hide another, and confirm with the specification whether non-numeric input forms another invalid partition.
79

A quantity field accepts 1 to 100. List the 2-value BVA test values.

Black-Box Test TechniquesEasy
Save to ▾
Show answer
The valid partition is 1 to 100, with invalid partitions below and above it. For each boundary, take the boundary and its closest neighbour in the adjacent partition. Lower boundary: 0 and 1. Upper boundary: 100 and 101. So 2-value BVA needs four values: 0, 1, 100 and 101, and four test cases give 100 percent 2-value boundary coverage.
80

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

Discounts depend on several combined business rules such as membership, coupon and festival offers. Which technique do you choose?

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

A field accepts integers from 1 to 99. Which set of values achieves 100 percent 2-value BVA coverage: {1, 99}, {0, 1, 99, 100}, {0, 50, 100} or {1, 2, 98, 99}?

Black-Box Test TechniquesEasy
Save to ▾
Show answer
The answer is {0, 1, 99, 100}. Two-value BVA needs each boundary value and its closest neighbour in the adjacent partition: 0 and 1 at the lower edge, 99 and 100 at the upper edge. {1, 99} misses the invalid neighbours, {0, 50, 100} misses 1 and 99, and {1, 2, 98, 99} stays inside the valid partition, which is closer to 3-value thinking.
83

What is the difference between 2-value and 3-value boundary value analysis?

Black-Box Test TechniquesMedium
Save to ▾
Show answer
BVA applies to ordered partitions. In 2-value BVA each boundary has two coverage items: the boundary value and its closest neighbour in the adjacent partition. In 3-value BVA there are three: the boundary and both neighbours. For a valid range 18 to 60, 2-value gives 17, 18, 60, 61, and 3-value gives 17, 18, 19, 59, 60, 61. 3-value is stricter and can catch defects like 'x == 18' written instead of 'x >= 18'.
84

How does decision table testing work, and how is coverage measured?

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

A field accepts integers from 5 to 15. List the 3-value BVA test values.

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

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?

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

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

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

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

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?

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

An order can be placed, shipped, delivered, cancelled or returned. How would you test this workflow?

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

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

Black-Box Test TechniquesMedium
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.
93

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

Black-Box Test TechniquesMedium
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.
94

What are the coverage criteria for state transition testing?

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

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?

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

Model an ATM PIN entry with three attempts as states and transitions. How many tests are needed for valid transitions coverage?

Black-Box Test TechniquesHard
Save to ▾
Show answer
States: Idle, WaitPIN, Try2, Try3, Access, Locked Idle --insert card--> WaitPIN WaitPIN --correct PIN--> Access WaitPIN --wrong PIN--> Try2 Try2 --correct PIN--> Access Try2 --wrong PIN--> Try3 Try3 --correct PIN--> Access Try3 --wrong PIN--> Locked There are 7 valid transitions. Access and Locked are final states, so each test ends there; covering all 7 needs at least 4 tests.
97

How do you use a state table to find invalid transitions?

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

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

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

Black-Box Test TechniquesHard
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.
100

An insurance premium depends on five Boolean conditions. The full decision table has 32 columns. How do you keep testing manageable?

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

What is statement testing and how is statement coverage calculated?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
Statement testing designs tests that execute the executable statements in the code. Statement coverage = statements executed by the tests / total executable statements x 100. Reaching 100 percent means every executable statement ran at least once, so a defect in any statement may be triggered. However, it does not guarantee that all decision logic is tested, for example the false outcome of an if without an else.
102

What is error guessing?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
Error guessing anticipates errors, defects and failures based on the tester's knowledge: how the application worked before, the types of mistakes developers tend to make, and failures seen in similar applications. A methodical form is the fault attack: list possible errors, defects and failures, then design tests to expose them. Examples include division by zero, empty inputs, very long strings, special characters and wrong date formats.
103

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

What is checklist-based testing and what are its risks?

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

A tester uses past experience to test division by zero, empty fields and invalid dates. Which technique is this?

White-Box, Experience and Collaboration-Based TestingEasy
Save to ▾
Show answer
This is error guessing, an experience-based technique. The tester anticipates mistakes based on knowledge of similar applications, typical developer errors and past failures. When done methodically by listing possible errors and designing tests for each, it is called a fault attack. It is not checklist-based testing unless the tester works from a prepared checklist of conditions.
106

How do you learn a new application quickly when you join a project?

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

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

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

What is the value of white-box testing?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
White-box testing considers the whole implementation, so it can find defects even when the specification is vague, outdated or incomplete. Coverage gives an objective measure of thoroughness. It can also be used in static testing, for example dry runs of code or pseudocode. Its main weakness is that it cannot detect omissions: if a requirement was never implemented, no white-box test will notice it.
110

Explain collaborative user story writing, the 3 Cs and INVEST.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
User stories are written collaboratively by business, development and testing. The 3 Cs are Card (the medium describing the story), Conversation (how the story will be used, documented or verbal) and Confirmation (the acceptance criteria). A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable. If stakeholders cannot say how to test a story, it is probably unclear or does not reflect real value.
111

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

Find the minimum tests for 100 percent statement and branch coverage of this code.

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
read(x) if x > 10: print('big') print('done') Statement coverage: one test with x = 15 executes every statement, so 1 test. Branch coverage: the if has a true and a false outcome, so tests with x = 15 and x = 5 are needed, 2 tests.
113

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

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

Write a test charter for an exploratory session on a checkout page.

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

Your tests achieved 100 percent branch coverage, yet users reported a defect. How is that possible?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
Coverage shows which code was executed, not that the code is correct or complete. The defect may come from a missing requirement that was never coded, which white-box testing cannot detect; from specific data values not used in tests; from integration or environment issues; or from wrong expected results. Coverage is a useful measure of thoroughness, but it must be combined with black-box and experience-based techniques.
117

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

White-Box, Experience and Collaboration-Based TestingMedium
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.
118

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

A new tester has no domain knowledge and no detailed test cases. How can checklists help, and what is the risk?

White-Box, Experience and Collaboration-Based TestingMedium
Save to ▾
Show answer
A checklist of high-level conditions, such as validations, error messages, navigation and security basics, gives the new tester structure and consistency while learning the domain. Each run can vary slightly, which increases coverage. The risk is that checklists wear out as developers learn to avoid listed defects, so the team should update them with new defect patterns and pair the tester with an experienced colleague.
120

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

White-Box, Experience and Collaboration-Based TestingMedium
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.
121

How does acceptance test-driven development (ATDD) work?

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

A test suite executes 8 of 10 executable statements and 3 of 4 branches. What are the coverage figures?

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

Prepare a fault attack list for a file upload feature.

White-Box, Experience and Collaboration-Based TestingHard
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.
124

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

White-Box, Experience and Collaboration-Based TestingHard
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.
125

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

White-Box, Experience and Collaboration-Based TestingHard
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.
126

What does a test plan contain according to CTFL v4.0?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
A test plan typically covers: context of testing (scope, objectives, constraints, test basis); assumptions and constraints; stakeholders with roles and responsibilities; communication; a risk register of product and project risks; the test approach (test levels, types, techniques, deliverables, entry and exit criteria, independence, metrics, test data and environments); and budget and schedule. It documents how test objectives will be met and is updated as the project changes.
127

What are entry and exit criteria? How do they relate to Definition of Ready and Definition of Done?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
Entry criteria define preconditions for starting an activity, such as available resources, testware, a stable build and a test environment. Exit criteria define what must be achieved to finish, such as coverage reached, unresolved defect counts, defect density and passed tests. Running out of time or budget can also be a valid exit. In Agile, exit criteria are often called the Definition of Done and entry criteria for a story the Definition of Ready.
128

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

What is risk, and how do project risks differ from product risks?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
A risk is a potential event or condition whose occurrence causes an adverse effect. Risk level is determined by likelihood and impact. Project risks affect the management and control of the project, such as staff shortages, delays, budget cuts, vendor problems or tool issues. Product risks relate to quality characteristics of the product, such as missing functionality, wrong calculations, slow response, poor security or bad usability.
130

Historically, development and test effort are in the ratio 3:2. Development is estimated at 600 person-days. Estimate the test effort.

Managing the Test ActivitiesEasy
Save to ▾
Show answer
This is estimation based on ratios. Test effort = development effort x 2 / 3 = 600 x 2 / 3 = 400 person-days. The ratio must come from similar past projects in the same organisation, because it changes with domain, risk and process maturity. I would also cross-check with another technique, such as Wideband Delphi, before committing to the number.
131

Classify as project or product risk: (a) test environment not ready on time, (b) report calculations may be wrong, (c) app may be slow on 4G, (d) budget is cut.

Managing the Test ActivitiesEasy
Save to ▾
Show answer
(a) Project risk, because it affects schedule and control of the project. (b) Product risk, because it concerns functional correctness of the product. (c) Product risk, because it concerns performance efficiency, a quality characteristic. (d) Project risk, because it affects resources and management. A simple test: if it is about the software's quality, it is a product risk; if it is about how the work is done, a project risk.
132

How do you prioritise your work when several tasks are urgent?

Managing the Test ActivitiesEasy
Save to ▾
Show answer
Situation: in my internship I had regression tests, a defect retest and a test case review due the same day. Task: finish what mattered most. Action: I asked my lead which item blocked the release, did the defect retest first since a fix depended on it, then the high-risk regression tests, and moved the review to the next morning with agreement. Result: the release stayed on track.
133

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

Which test estimation techniques are described in CTFL v4.0?

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

What test case prioritisation strategies are there?

Managing the Test ActivitiesMedium
Save to ▾
Show answer
Risk-based prioritisation orders tests by the results of risk analysis, running tests for the highest risks first. Coverage-based prioritisation orders by coverage, running tests that achieve the most coverage first; additional coverage prioritisation picks each next test by the extra coverage it adds. Requirements-based prioritisation follows the priorities of requirements set by stakeholders. Dependencies can force a lower-priority test to run first.
136

What happens in test monitoring, test control and test completion?

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

What is the difference between a test progress report and a test completion report?

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

Calculate a three-point estimate where optimistic is 6, most likely is 9 and pessimistic is 18 person-days.

Managing the Test ActivitiesMedium
Save to ▾
Show answer
E = (a + 4m + b) / 6 = (6 + 4 x 9 + 18) / 6 = (6 + 36 + 18) / 6 = 60 / 6 = 10 person-days SD = (b - a) / 6 = (18 - 6) / 6 = 2 Report the estimate as 10 +/- 2 person-days, which gives a range of 8 to 12.
139

How do you prioritise risks using a likelihood and impact matrix?

Managing the Test ActivitiesMedium
Save to ▾
Show answer
Score each risk for likelihood and impact on a scale such as 1 to 5, and multiply to get the risk level. Example: wrong interest calculation, likelihood 3 and impact 5, level 15; slow report export, likelihood 4 and impact 2, level 8; spelling errors, 4 and 1, level 4. Test the highest levels first and most deeply, using more rigorous techniques and earlier test execution.
140

Your CI pipeline takes two hours because most automated tests are UI tests. What do you suggest?

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

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

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

Managing the Test ActivitiesMedium
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.
143

Explain the testing quadrants.

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

Describe product risk analysis and product risk control.

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

Order these tests for execution: A (priority 1, depends on C), B (priority 2), C (priority 3), D (priority 2, depends on B). 1 is highest.

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

Outline a test completion report for a release.

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

Midway through the test cycle you are 30 percent behind schedule. What test control actions can you take?

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

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

Managing the Test ActivitiesHard
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.
149

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

You must estimate test effort for a new type of project with no historical data. How do you do it?

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

Describe a time you led a test team through conflicting priorities.

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

What are the objectives of a defect report?

Defect and Configuration ManagementEasy
Save to ▾
Show answer
A defect report gives the people responsible for handling and resolving the defect enough information to fix it. It also provides a way to track the quality of the work product, and it offers ideas for improving the development and test processes. A good report is clear, reproducible and neutral in tone, so that developers can act on it quickly and managers can analyse trends.
153

What information does a defect report typically contain in CTFL v4.0?

Defect and Configuration ManagementEasy
Save to ▾
Show answer
A unique identifier; a title with a short summary; date observed, issuing organisation and author; the test object and test environment; context such as test case, test activity and test data; a description for reproduction with steps, logs, screenshots, and expected and actual results; severity; priority; status such as open, deferred, duplicate, re-opened, closed or rejected; and references, for example to the test case.
154

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

Describe a typical defect life cycle.

Defect and Configuration ManagementEasy
Save to ▾
Show answer
A defect is logged as new or open, then triaged: it may be rejected, marked duplicate or deferred, or assigned for fixing. After the developer fixes it, it moves to awaiting confirmation testing. The tester re-tests; if it passes, the defect is closed, and if it fails, it is re-opened. Teams customise the workflow, but each status should have clear rules about who can move it and when.
156

A tester logs a defect titled 'Login broken' with no other details. How would you improve it?

Defect and Configuration ManagementEasy
Save to ▾
Show answer
A better title is 'Login - valid credentials - error 500 after clicking Sign in'. The report should add the build number and environment, browser and device, preconditions such as user type, numbered steps, test data used, expected result, actual result with the error message, a screenshot or log, severity, suggested priority, and a reference to the related test case. This lets a developer reproduce it immediately.
157

Write a sample defect report for a failed coupon code.

Defect and Configuration ManagementEasy
Save to ▾
Show answer
ID: DEF-1042. Title: Checkout - valid coupon SAVE10 rejected as expired. Build: 3.4.1, staging, Chrome 130 on Windows. Preconditions: logged-in user, cart value 1,500 rupees. Steps: open checkout, enter SAVE10, click Apply. Expected: 10 percent discount applied. Actual: error 'Coupon expired' although valid until 31 December. Attachments: screenshot, console log. Severity: major. Priority: high. Reference: TC-CHK-018.
158

What are false positives and false negatives in testing?

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

How does configuration management support testing?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
Configuration management identifies, controls and tracks work products such as test plans, test cases, scripts, test results, test data, environments and the test object itself. It ensures all configuration items are uniquely identified, version controlled, tracked for changes and related to each other so traceability is kept. Baselines can only be changed through formal change control. This lets testers know exactly which build and testware versions were tested.
160

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

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

Defect and Configuration ManagementMedium
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.
162

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

Defect and Configuration ManagementMedium
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.
163

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

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

Defect and Configuration ManagementMedium
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.
165

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

Testing found 80 defects and users found 20 more after release. What is the defect detection percentage?

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

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

Tell me about a time you missed a defect. What did you learn?

Defect and Configuration ManagementMedium
Save to ▾
Show answer
Situation: a defect in date formatting reached production after my testing. Task: understand why and prevent it. Action: I owned the miss, found my test data used only one locale, and added test cases for other date formats and locales. I also shared a checklist for locale testing. Result: no similar defect appeared in later releases, and I learned to review my test data as carefully as my test steps.
169

Your manager asks you to lower the severity of a defect to meet release targets. How do you respond?

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

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

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

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

Defect and Configuration ManagementHard
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.
173

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

Defect and Configuration ManagementHard
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.
174

How do you run an effective defect triage meeting?

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

Describe how you improved the defect management process in a team.

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

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

What is the format of the ISTQB CTFL v4.0 exam?

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

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

Are there prerequisites for CTFL, and does the certificate expire?

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

In the CTFL exam you have ten questions left and only five minutes. What should you do?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
There is no negative marking, so never leave a question blank. Quickly answer the easier ones first, eliminate obviously wrong options on the rest and pick the best remaining choice. Flag nothing new for review now. To avoid this situation, aim to spend about one minute per question in the first pass and skip long calculation questions to revisit later.
181

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

Test Tools and Exam PreparationEasy
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.
182

How do you register for the CTFL exam in India?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
Register through the ISTQB member board for India or an ISTQB-accredited exam provider. Create an account, choose CTFL v4.0, and pick either an online proctored exam or a test centre. For online exams, check your webcam, microphone and internet in advance, and keep a valid government photo ID ready. Results are usually shared soon after the exam, followed by the certificate.
183

Why did you decide to take the ISTQB Foundation certification?

Test Tools and Exam PreparationEasy
Save to ▾
Show answer
Model answer: I wanted a structured base in testing rather than learning only from tools. The CTFL syllabus taught me standard terms, test techniques like boundary value analysis and decision tables, and how testing fits into Agile and DevOps. It is recognised across many countries, so it helps me communicate with global teams. Preparing for it also improved how I write test cases and defect reports.
184

What are the benefits of test automation?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Automation saves time by reducing repetitive manual work such as regression runs, comparisons and data entry. It prevents simple human errors through greater consistency and repeatability. It gives more objective assessment, such as coverage, and access to measurements too complex for humans. It reduces test execution times, giving faster feedback and earlier defect detection, and frees testers to design new and deeper tests.
185

What are the risks of test automation?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Unrealistic expectations about what a tool can do; inaccurate estimates of the time, cost and effort to introduce and maintain it; using a tool where manual testing is better; relying on the tool too much and ignoring critical thinking; dependency on the tool vendor, which may go out of business or retire the tool; open-source tools being abandoned; and tools not compatible with the development platform or not meeting regulations.
186

What changed in CTFL v4.0 compared with the 2018 syllabus?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
v4.0 added Agile and DevOps content: the whole team approach, test-first approaches like TDD, ATDD and BDD, shift-left, retrospectives, collaboration-based test approaches, the test pyramid and testing quadrants. It renamed the pesticide paradox to 'tests wear out', removed use case testing and decision coverage, focused white-box testing on statement and branch coverage, and described test roles instead of job titles.
187

How are CTFL v4.0 exam questions distributed across chapters?

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

An exam question asks for the 'best' answer and two options seem correct. How do you decide?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Re-read the stem for keywords such as 'most likely', 'best', 'first' or 'not'. Compare both options strictly against the syllabus wording, not your company's practice. Often one option is partly true or too absolute, using words like 'always' or 'guarantees'. Choose the option that fully matches the syllabus definition. Practising official sample exams builds this habit.
189

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

Test Tools and Exam PreparationMedium
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.
190

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

How should you answer 'select TWO' questions in the CTFL exam?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Read the instruction carefully, because you must select exactly two options and usually get the point only if both are correct. Evaluate each option separately as true or false against the syllabus. Eliminate absolute statements and options that describe a different concept. If you are sure of one, compare the remaining options carefully. These questions appear in the exam, so practise them in sample papers.
192

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

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

How has ISTQB knowledge helped you in your job?

Test Tools and Exam PreparationMedium
Save to ▾
Show answer
Situation: our team wrote test cases with no clear technique, and suites kept growing. Task: improve efficiency. Action: I applied equivalence partitioning and boundary value analysis to the form validations and used decision tables for pricing rules, removing redundant tests. Result: we cut the regression suite by about 30 percent while finding more boundary defects, and my lead asked me to train two juniors.
195

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

Test Tools and Exam PreparationMedium
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.
196

What certification path can you follow after CTFL?

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

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

Test Tools and Exam PreparationHard
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.
198

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

A company uses its own testing terms that differ from ISTQB terms. How do you handle this in the exam and at work?

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

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

Test Tools and Exam PreparationHard
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.

Frequently asked questions

Is the ISTQB Foundation certificate useful for getting a testing job in India?

Yes. Many IT services companies, banks and global capability centres in India list ISTQB CTFL as preferred or mandatory for QA roles, and some client projects require certified testers. The certificate alone does not guarantee a job, but combined with hands-on practice in test case design, defect reporting, SQL basics and an API or automation tool, it makes your resume stand out for manual tester and QA analyst openings.

Who is eligible to take the CTFL v4.0 exam?

There are no formal prerequisites. Engineering and science students, BCA and MCA graduates, freshers, career switchers from other fields and experienced testers can all take it. Developers, business analysts and project managers also take it to understand testing better. Basic computer knowledge and some exposure to software projects make the syllabus easier to follow, but you do not need prior work experience.

How long does it take to prepare for ISTQB Foundation?

Most freshers need four to six weeks of steady study of one to two hours daily, covering all six chapters and solving technique problems. Working testers with a few years of experience often prepare in two to three weeks, focusing on syllabus terminology and K3 calculations. Whatever your background, plan to complete at least three full timed sample exams and review every mistake before booking.

Does the ISTQB certificate expire?

No. The Certified Tester Foundation Level certificate has lifetime validity and does not need renewal. However, syllabus versions change over time, so if you hold an older version you may want to study the v4.0 changes, such as DevOps, test-first approaches, the test pyramid and collaboration-based testing, because interviewers increasingly ask about them. CTFL is also the prerequisite for Advanced and most Specialist certifications.

Can I take the exam online from home?

Yes. Accredited exam providers offer online proctored exams as well as test centre options. For an online exam you need a laptop or desktop with webcam and microphone, a stable internet connection, a quiet private room and a valid photo ID. Run the provider's system check in advance. The exam content, duration and pass mark are the same in both modes.

What should I learn after ISTQB Foundation?

Build practical skills alongside the certificate: SQL for data checks, API testing with Postman, and an automation tool such as Selenium or Playwright with basic programming. Learn Jira and Agile workflows. Later you can take ISTQB Advanced Test Analyst, Technical Test Analyst or Test Management, or Specialist modules such as Test Automation Engineering, Performance Testing or Security Testing, depending on your career goal.