What Is Testing? CTFL Test Objectives and Testing vs Debugging
Software testing is a set of activities to discover defects and evaluate the quality of software work products, called test objects — and it covers far more than running the software. This CTFL lesson covers syllabus section 1.1: what testing includes (static and dynamic testing, verification and validation), the typical test objectives and why they change with context, and how testing differs from debugging, including what happens after a defect is fixed.
- Define software testing and the test object, and explain why testing is more than executing tests.
- Distinguish static testing from dynamic testing and verification from validation.
- Identify the typical test objectives and recognise activities that are not test objectives.
- Explain how the work product, test level, risks, SDLC and business context change test objectives.
- Differentiate testing from debugging and describe the debugging steps: reproduction, diagnosis and fixing.
- Explain why defects found by static testing need no reproduction or diagnosis, and what confirmation and regression testing check after a fix.
What is software testing?
Software testing is a set of activities to discover defects and evaluate the quality of software work products. Whatever is being tested at the moment is called the test object: a component, a whole system, but also a requirements specification, a user story, a design or a piece of code.
Two common misconceptions are worth correcting early, because both show up in exam options:
- Testing is not only running tests. Executing the software and checking results is one activity among many. Testing also includes analysing what to test, designing tests, preparing environments, reviewing work products and reporting, and it has to be aligned with the software development lifecycle (SDLC) in use.
- Testing is not only verification. It checks the product against its specification and against what stakeholders actually need (see verification vs validation below).
Testing also cannot prove that software is free of defects. A set of passing tests reduces the chance of undiscovered defects; it never shows that none remain. (Why that is so is the subject of the testing principles lesson.)
Static and dynamic testing
Testing can be dynamic or static, and both count as testing.
| Dynamic testing | Static testing | |
|---|---|---|
| Is the test object executed? | Yes — the software runs | No — nothing is executed |
| What it reveals | Failures, which are caused by defects | Defects, found directly in the work product |
| Typical work products | Components, integrated systems, running services | Requirements, user stories, designs, code, test cases |
| Examples | Running a component's automated tests in a CI pipeline; a load test of a search service | An inspection of an architecture document; a linter reporting unreachable code |
So testing can start long before the first build exists: finding an ambiguous acceptance criterion while reviewing a user story is testing. A static analysis tool examines the code without running it, so it is static testing too — and what it reports is a defect, not a failure.
Verification vs validation
Verification checks whether the system meets its specified requirements. Validation checks whether the system meets users' and other stakeholders' needs in its operational environment. Testing involves both.
| Verification | Validation | |
|---|---|---|
| The yardstick | The specification (requirements, design, interface definitions) | The real needs of users and other stakeholders |
| Short form | Are we building the product right? (a common memory aid, not syllabus wording) | Are we building the right product? (same memory aid) |
| Examples | Running tests derived from a functional specification; inspecting a database schema against the data model it was meant to implement | Beta users trying a release in their own workplaces; a prototype walkthrough with a product owner to check that a screen flow suits the business process |
The difference is the yardstick, not the technique. Validation does not require executing the system: a prototype walkthrough with a product owner involves no execution of the system and is still validation. Equally, verification can be dynamic (running specification-based tests) or static (checking a design against requirements).
A system can pass verification and fail validation. Conforming to every documented requirement is not the same as meeting every real need: if the specification itself is incomplete or wrong, verification against it cannot reveal that, while validation against stakeholders' needs can.
Typical test objectives
A test objective is the reason for testing. The CTFL syllabus lists these typical objectives:
- Evaluating work products such as requirements, user stories, designs and code
- Triggering failures and finding defects
- Ensuring the required coverage of a test object
- Reducing the level of risk of inadequate software quality
- Verifying whether specified requirements have been fulfilled
- Verifying that a test object complies with contractual, legal and regulatory requirements
- Providing information to stakeholders so they can make informed decisions (for example, a test completion report that a go/no-go decision is based on)
- Building confidence in the quality of the test object
- Validating whether the test object is complete and works as stakeholders expect
What is not on the list matters as much. These are not test objectives:
- Locating, analysing or correcting a defect in the code — that is debugging.
- Proving the software has no defects — testing cannot do that.
- Assigning developers to fix defects or deciding fix priority — that is defect and project management.
- Improving the development process so fewer defects are introduced — that is a quality assurance concern (covered in the next lesson).
Several objectives can sound alike. "Providing information for decisions" is about giving stakeholders what they need to choose (release or not); "building confidence" is about the level of trust in quality; "reducing risk" is about lowering the chance of quality problems reaching users; "ensuring coverage" is about how much of the test object the tests exercise. Match the objective to what the testing result is actually used for.
Why test objectives vary with context
Test objectives are not fixed; they depend on the context. The syllabus names these factors:
- the work product being tested
- the test level (for example, component vs acceptance testing)
- the risks
- the SDLC being followed
- the business context: corporate structure, competitive considerations, time to market
The test level alone shifts the emphasis. Component testing of a single module usually concentrates on finding defects early and achieving the required coverage of that component; acceptance testing of the whole system leans towards validation and building confidence that it is fit for use. Neither emphasis is better; each fits its level.
Risk and business context shift the emphasis just as much. Testing an infusion-pump controller for a medical device puts reducing the risk of harm and verifying compliance with safety regulations at the front, with demanding coverage targets. Testing an internal reporting tool used by a handful of staff, with a launch date tied to a sales conference, puts fast feedback on the few product risks that matter most and enough information to make the release decision on time ahead of exhaustive coverage. The work product, level and SDLC can be identical in both cases; the context alone changes which objectives come first.
Test objectives are defined as part of test planning, so they guide what is tested and how much.
Testing vs debugging
Testing and debugging are separate activities. Testing shows that a problem exists; debugging finds and removes its cause.
| Testing | Debugging | |
|---|---|---|
| Purpose | Trigger failures caused by defects (dynamic) or find defects directly (static) | Find the causes of failures (defects), analyse them and remove them |
| Examples | Running an end-to-end test of a booking flow; a static analysis run; logging a defect report | Stepping through the code with a debugger to trace a wrong total back to its source; editing the faulty condition |
| Output | Information: failures, defects, coverage, quality evaluation | A corrected work product |
The split is about the activity, not the job title. Developers test (unit tests, code reviews) and testers may help reproduce a failure, but finding and removing the cause is debugging whoever does it. A useful check: if the activity locates or changes the defect, it is debugging; if it reveals or reports a problem, it is testing.
The debugging process after a failure
When dynamic testing triggers a failure, the typical debugging process has three steps, in this order:
- Reproduction — get the failure to occur again so it can be investigated, using the information the tester recorded. Without a reliable way to trigger the failure, the cause cannot be confirmed, so this step leads the process.
- Diagnosis — find the root cause of the failure, including the defect behind it. (Root causes and defects are distinguished in the next lesson.)
- Fixing the cause — change the work product to remove the defect.
Reproduction is part of debugging, not just the code change. Recording what went wrong belongs to testing; everything done to locate and remove the cause, starting with getting the failure to recur, belongs to debugging.
Defects found by static testing
When static testing identifies a defect, debugging is simply removing it. There is no reproduction or diagnosis, because static testing finds the defect directly and cannot cause a failure — there is nothing to reproduce and the location is already known. An undefined term spotted in an inspection of a design document, or a hard-coded password reported by a static analysis tool, is simply corrected.
| Problem found by | Reproduce? | Diagnose? | Fix? |
|---|---|---|---|
| Dynamic testing (a failure) | Yes | Yes | Yes |
| Static testing (a defect) | No | No | Yes — remove it |
After the fix: confirmation and regression testing
Debugging ends with the fix; testing then picks up again with two follow-up activities. Both are testing, not part of debugging.
| Confirmation testing | Regression testing | |
|---|---|---|
| Question it answers | Did the fix resolve the original problem? | Did the fix cause failures anywhere else? |
| What is run | Typically the test cases that failed before the fix are executed again against the changed software; new tests for the change may be added | A wider set of tests across the rest of the test object that the change could affect |
| Who | Preferably the same person who performed the initial test | Anyone; often automated |
The general rule: confirmation testing is preferably performed by the person who ran the initial test, and regression testing then checks the other parts of the test object for unintended side effects of the change. The details of these two test types (and how much regression testing to do) belong to the test types lesson in Domain 2.
Testing is also managed work
Testing is not only a technical activity. It also has to be planned, managed, estimated, monitored and controlled. Estimating how much test effort a release will need, for instance, is as much a part of testing as executing the tests themselves.
Two of those terms are easy to blur. Test monitoring is the ongoing checking of actual test progress and results against the test plan (how many tests have run, how many defects are open, how much coverage has been reached). Test control is taking corrective action when that comparison shows a deviation, for example re-prioritising tests, adjusting the schedule or changing the test environment. Both are test management activities and therefore part of testing, not a separate project task; chapter 5 of the syllabus covers them in detail.
Testers use tools, but testing remains largely an intellectual activity: it needs specialised knowledge, analytical skills, critical thinking and systems thinking. The individual test activities and the roles that carry them out are covered in the lesson on test activities, testware and test roles.
Tip. Questions on this topic are mostly short recall and classification items. Expect to pick the statement that BEST describes testing, to spot which goal in a list is or is NOT a typical test objective, and to classify an activity as static or dynamic testing, verification or validation, or testing or debugging. Scenario items describe what a person does after a failure or a review finding and ask which activity it is, which step comes first, or which follow-up is best. Some use roman-numeral sets of statements to judge as true or false. Distractors swap the definitions of near-twin terms, so read each option for which yardstick or activity it really names.
- Testing = activities to discover defects and evaluate the quality of work products (test objects); it is more than running tests.
- Static testing examines work products without executing them and finds defects directly; dynamic testing executes the software and triggers failures.
- Verification checks against the specified requirements; validation checks against stakeholders' real needs in the operational environment — either can be static or dynamic.
- Typical test objectives include evaluating work products, finding defects, ensuring coverage, reducing risk, verifying requirements and compliance, informing decisions, building confidence and validating.
- Locating or correcting defects, proving there are no defects, and assigning fixes are not test objectives.
- Test objectives vary with the work product, test level, risks, SDLC and business context (corporate structure, competition, time to market).
- Debugging finds, analyses and removes the causes of failures: reproduce, diagnose, fix.
- A defect found by static testing is just removed — no reproduction or diagnosis.
- After a fix, confirmation testing (preferably by the original tester) checks the fix; regression testing checks nothing else broke.
- Testing is also planned, managed, estimated, monitored and controlled.
Frequently asked questions
What is the definition of software testing in ISTQB CTFL?
In the CTFL syllabus, software testing is a set of activities to discover defects and evaluate the quality of software work products, which are called test objects while they are being tested. It includes static testing (reviews and static analysis, without execution) as well as dynamic testing (executing the software), and it is also planned, managed, estimated, monitored and controlled.
What is the difference between testing and debugging?
Testing reveals problems: dynamic testing triggers failures caused by defects, and static testing finds defects directly. Debugging is the separate activity of finding, analysing and removing the causes of failures — typically by reproducing the failure, diagnosing its root cause and fixing it. Who performs the activity does not change which one it is.
What are the typical test objectives in CTFL?
The typical test objectives are evaluating work products, triggering failures and finding defects, ensuring required coverage, reducing the risk of inadequate quality, verifying that specified requirements are fulfilled, verifying contractual, legal and regulatory compliance, providing information so stakeholders can make informed decisions, building confidence in quality, and validating that the test object is complete and works as stakeholders expect.
Why do test objectives differ between projects?
Test objectives depend on context: the work product being tested, the test level, the risks, the software development lifecycle followed, and business factors such as corporate structure, competitive pressure and time to market. Component testing and acceptance testing of the same system, for instance, usually pursue different objectives.
What is the difference between verification and validation?
Verification checks whether a system meets its specified requirements; validation checks whether it meets users' and other stakeholders' needs in its operational environment. The difference is the yardstick, not whether the software runs: a prototype walkthrough with users is validation even though the system is not executed.
Does a defect found in a review need to be reproduced and diagnosed?
No. When static testing such as a review or static analysis finds a defect, debugging only removes it. Static testing finds defects directly and cannot cause failures, so there is no failure to reproduce and no root cause to search for.
Who should perform confirmation testing after a defect is fixed?
Preferably the same person who performed the initial test that revealed the failure. Confirmation testing checks that the fix resolved the problem; regression testing then checks that the change did not cause failures elsewhere. Both are testing activities, not part of debugging.
Source
This lesson covers the "Fundamentals of Testing" domain of the official CTFL exam guide. Vendors revise their guides — check the source for the current version.
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.