1.1 What Testing Does

Testing Is Evaluation, Not Just Execution

In the ISTQB CTFL v4.0 syllabus, testing is defined as a set of activities to discover defects and evaluate the quality of software work products. The word evaluate is deliberate: testing is broader than running a finished application and seeing whether it crashes. Testing evaluates work products such as requirements, user stories, design specifications, source code, testware, configuration data, and the running software itself.

A frequent exam trap equates testing with execution only. The syllabus separates two complementary forms:

• Dynamic testing executes the software and observes its actual behavior against expectations.
• Static testing examines a work product without executing code — for example, reviewing a requirement for ambiguity or running a static analysis tool over source code.

Reviewing a requirement to remove an ambiguity is testing even though no program ever runs. Both forms find different kinds of problems at different times, which is why mature teams use both.

Objectives of Testing

The syllabus lists typical test objectives. Memorize these because questions ask which objective a scenario serves:

The exact objectives depend on context. Safety-critical medical software, an internal reporting script, and a casual mobile game do not need the same evidence or rigor. A K2 question may ask you to recognize that the purpose of a given test activity is, say, building confidence rather than finding defects.

What Testing Cannot Do

A foundational and heavily tested idea: testing does not prove the absence of defects. Passing tests provide evidence only under the conditions that were tested. They do not show that every possible input, state, environment, timing sequence, and integration is defect-free. CTFL answer options that claim testing guarantees perfection, removes all defects, or proves correctness are almost always wrong.

Error, Defect, Failure, Root Cause

The causal chain is one of the most examinable ideas in Chapter 1:

The chain runs: a developer makes a human error (for example, misunderstands a requirement); that error introduces a defect into code or design; when the software is executed under the right conditions, the defect causes a failure that a tester, user, or monitor observes. Not every defect causes a failure — a defect in unreachable code may never trigger one. Root cause analysis asks why the error happened, often revealing a process weakness (such as unclear requirements) so the team can prevent whole classes of similar defects.

Failures can also arise from environmental conditions such as radiation, electromagnetic fields, or pollution affecting the hardware.

How To Answer These Questions

Look for wording such as evaluate, work product, defect, failure, confidence, information, and risk. Be cautious with absolutes like all defects, complete proof, or only execution. The foundation message is balanced: testing is powerful evidence-gathering that makes quality and risk visible, but it is not a mathematical guarantee of perfect software, and the tester is far more than a simple defect finder.

Test Bases, Test Objects, and Coverage

Two more terms appear constantly in Chapter 1 and are worth fixing now. The test basis is the body of knowledge used as the basis for designing tests — requirements, user stories, design documents, risk analyses, or even an existing system. The test object is the work product being tested, such as a component, integration, or whole system. Testing evaluates a test object against a test basis. When the syllabus speaks of achieving coverage, it means the extent to which the test basis (requirements, risks) or the structure of the test object (such as code statements) has been exercised by tests, measured as a percentage.

Coverage is never about proving correctness; it is a measurable indicator of how much has been checked.

Why Testing Is Necessary

The syllabus gives a clear rationale for why testing is necessary at all. Rigorous, risk-focused testing of components, systems, and their documentation helps reduce the likelihood of failures occurring during operation. When defects are detected and subsequently fixed, testing contributes to the quality of those components or systems. In addition, testing may be required to meet contractual or legal requirements, or to comply with regulatory standards — for instance, in aviation, medical devices, or finance, where independent testing evidence is mandated.

The cost of failures in operation can be far higher than the cost of finding the defects beforehand: financial loss, damage to reputation, injury, or even death in safety-critical contexts. This economic and safety argument is exactly why the seven principles (covered later) stress early and risk-based testing, and why test objectives such as reduce risk and comply with rules sit at the heart of the discipline.

Static and Dynamic Testing Together

Because static and dynamic testing find different defects, the syllabus treats them as complementary rather than competing. Static testing can find defects in requirements and design before any code exists — gaps, ambiguities, contradictions — that would be expensive to fix later. Dynamic testing finds defects that only appear when code runs, such as incorrect calculations, memory issues, or performance problems. A team that reviews its requirements (static) and then executes risk-based tests (dynamic) gains broader, earlier, and cheaper defect detection than one relying on execution alone.

Exam questions sometimes ask which technique can find a particular defect category; the rule of thumb is that anything detectable only at runtime needs dynamic testing, while specification defects are best caught statically.