Chapter 1 builds the vocabulary for the whole exam. It explains what testing is and is not, why it is needed, the seven principles, the activities that make up a test process, the work products they create, and the skills and roles of the people who test. It carries 8 of the 40 exam questions.
ISTQB CTFL › 1. Fundamentals of Testing Syllabus v4.0.1 · updated 3 Nov 2026
| Exam weight | Questions | K-levels | Training time |
|---|---|---|---|
| 20% | 8 | 2 × K1, 6 × K2 | 180 minutes |
Keywords to remember (K1): coverage, debugging, defect, error, failure, quality, quality assurance, root cause, test analysis, test basis, test case, test completion, test condition, test control, test data, test design, test execution, test implementation, test monitoring, test object, test objective, test planning, test procedure, test process, test result, testing, testware, traceability, validation, verification.
1.1 What is testing?
Software testing is a set of activities to find defects and evaluate the quality of software work products. Whatever is being tested is called the test object: a piece of code, a whole system, a requirement document or a user story.
Two misconceptions appear in exam questions again and again:
- “Testing is just running tests.” Running the software is only one activity. Testing also includes planning, analysing requirements, designing test cases, reviewing documents, reporting and learning lessons.
- “Testing only checks that the system meets the specification.” That is verification. Testing also includes validation: checking that the system meets users’ and stakeholders’ real needs in its operational environment.
| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Checks against | Specified requirements | User and stakeholder needs |
| Example | The discount is 10% as the requirement says | Customers actually understand and use the discount screen |
Testing can be static (no execution: reviews and static analysis, see chapter 3) or dynamic (the software is executed, see chapter 4). It is also a managed activity that needs planning, estimating, monitoring and control (chapter 5), and it uses tools (chapter 6). Above all, testing is an intellectual activity that needs specialist knowledge, analytical skill, critical thinking and systems thinking.
1.1.1 Test objectives (K1)
Typical objectives of testing:
- Evaluating work products such as requirements, user stories, designs and code
- Causing failures and finding defects
- Ensuring the required coverage of a test object
- Reducing the risk of inadequate software quality
- Verifying that specified requirements are fulfilled
- Verifying compliance with contractual, legal and regulatory requirements
- Providing information so stakeholders can make informed decisions
- Building confidence in the quality of the test object
- Validating that the test object is complete and works as stakeholders expect
The objectives change with the context: the work product, the test level, the risks, the SDLC, and business factors such as time to market. For example, component testing mainly aims to find defects early, while acceptance testing mainly aims to build confidence and support a release decision.
“Proving that the software has no defects” is never a test objective. Testing can only show that defects are present (principle 1).
1.1.2 Testing and debugging (K2)
Testing and debugging are separate activities done for different reasons.
| Testing | Debugging | |
|---|---|---|
| Purpose | Trigger failures (dynamic) or find defects directly (static) | Find, analyse and remove the cause of a failure |
| Typically done by | Testers and developers | Developers |
| Output | Failures, defect reports, information about quality | A fixed defect |
When a dynamic test triggers a failure, debugging usually involves three steps: reproduce the failure, diagnose it (find the defect), and fix the defect. Afterwards, confirmation testing checks that the fix worked, ideally run by the person who ran the original test, and regression testing checks that the fix did not break anything else.
When static testing finds a defect (for example, a reviewer spots a wrong formula in a design document), debugging is simply removing it. There is no failure to reproduce or diagnose, because nothing was executed.
1.2 Why is testing necessary?
Testing is a form of quality control. It helps the team reach the agreed objectives within scope, time, quality and budget constraints. Testing is not only the test team’s job: anyone on the project can use testing skills.
1.2.1 Testing’s contributions to success (K2)
- Detects defects cost-effectively. Defects can then be removed by debugging, so testing contributes indirectly to better quality.
- Evaluates quality directly at each stage of the SDLC, giving data for decisions such as “can we release?”.
- Represents users indirectly. Testers bring the users’ view into the project, which is cheaper and more practical than involving many real users throughout development.
- Meets contractual, legal or regulatory needs, for example safety standards in medical or automotive software.
Example: an online banking team tests the funds-transfer feature before release. The tests find that transfers over ₹1,00,000 are rounded wrongly. Fixing this before go-live avoids financial loss and reputational damage, which shows testing’s value.
1.2.2 Testing and quality assurance (K1)
People often use “testing” and “QA” as if they meant the same thing. They do not.
| Testing | Quality assurance (QA) | |
|---|---|---|
| Focus | The product | The process |
| Approach | Corrective: find and help remove defects | Preventive: improve processes so fewer defects are made |
| Type | A major form of quality control (others are formal methods, simulation and prototyping) | Implementing and improving development and test processes |
| Who | Testers and developers | Everyone on the project |
| Use of test results | To fix defects | As feedback on how well the processes work |
1.2.3 Errors, defects, failures and root causes (K2)
This chain appears in almost every exam:
Root cause → error (mistake) → defect (fault, bug) → failure
- A human error (mistake) happens because of time pressure, complexity, tiredness or lack of training.
- The error produces a defect in a work product: in code, a requirement, a test script or even a build file.
- If defective code is executed, it may cause a failure: the system does something it should not do, or does not do something it should.
- The root cause is the fundamental reason the problem occurred, found through root cause analysis. Removing it prevents similar defects in future.
Example: a developer was given an unclear requirement (root cause), misunderstood the GST rule (error), and coded 18% instead of 12% (defect). A customer sees the wrong tax on an invoice (failure).
Important details:
- Not every defect causes a failure. Some only fail under specific conditions; some never fail.
- Failures can also be caused by environmental conditions, such as radiation or electromagnetic fields damaging firmware, without any human error in the code.
- Defects in early work products (requirements, designs), if not found, often lead to defects in later ones.
1.3 The seven testing principles (K2)
| # | Principle | What it means | Example |
|---|---|---|---|
| 1 | Testing shows the presence, not the absence, of defects | Testing reduces the chance of undiscovered defects but can never prove the software is defect-free | 500 passed tests do not prove the payment module has no bugs |
| 2 | Exhaustive testing is impossible | Testing every input and path is not feasible except in trivial cases; use techniques, prioritization and risk to focus effort | A 10-character password field has more combinations than you could ever run |
| 3 | Early testing saves time and money | Defects removed early do not cause defects in later work products, so the cost of quality drops | Reviewing the requirements finds a wrong rule before any code is written |
| 4 | Defects cluster together | A small number of components contain most defects (the Pareto principle) | 80% of production incidents come from the checkout module, so test it more |
| 5 | Tests wear out | Repeating the same tests finds fewer new defects; update tests and data, though repeated automated regression tests are still useful | The same 50 regression tests have passed for months but customers still report bugs |
| 6 | Testing is context dependent | There is no single right way to test; a game, a pacemaker and an e-commerce site need different approaches | Safety-critical software needs formal, independent testing; a startup MVP may not |
| 7 | Absence-of-defects fallacy | A system with no known defects can still fail if it does not meet users’ needs; verification is not enough, validation is also needed | A perfectly coded app that customers find too confusing to use |
“Please Eat Every Delicious Tomato Carefully All day”: Presence, Exhaustive, Early, Defects cluster, Tests wear out, Context, Absence-of-defects fallacy.
Older material calls principle 5 the “pesticide paradox”. The v4.0 syllabus uses “tests wear out”. Both describe the same idea.
1.4 Test activities, testware and test roles
1.4.1 Test activities and tasks (K2)
A test process is a set of test activities. The activities often look sequential, but in practice they are iterative and overlap, and they are tailored to the project.
| Activity | Key question | Main tasks |
|---|---|---|
| Test planning | What are we trying to achieve and how? | Define test objectives and choose an approach that meets them within the constraints |
| Test monitoring and test control | Are we on track? What must we change? | Monitoring: continuously compare progress with the plan. Control: take actions to meet the objectives |
| Test analysis | What to test? | Analyse the test basis, identify testable features, define and prioritise test conditions with their risks, find defects in the test basis, judge testability |
| Test design | How to test? | Turn test conditions into test cases and other testware (such as test charters), identify coverage items, define test data and environment requirements, identify tools |
| Test implementation | Is everything ready to run? | Create test data, organise test cases into test procedures and test suites, write manual and automated test scripts, build the test execution schedule, set up and verify the test environment |
| Test execution | What happened? | Run tests per the schedule, compare actual and expected results, log results, analyse anomalies and report defects |
| Test completion | What did we learn? | At milestones: create change requests for open defects, archive reusable testware, shut down the environment, gather lessons learned, write the test completion report |
Test analysis answers “what to test” (test conditions). Test design answers “how to test” (test cases). Questions often swap these two to trick you.
1.4.2 Test process in context (K2)
Testing is part of the organisation’s development process and is funded to meet business needs, so how you test depends on the context:
- Stakeholders: needs, expectations, willingness to cooperate
- Team members: skills, experience, availability, training needs
- Business domain: criticality, risks, market needs, legal regulations
- Technical factors: type of software, architecture, technology
- Project constraints: scope, time, budget, resources
- Organisational factors: structure, policies, practices
- SDLC: engineering practices and development methods
- Tools: availability, usability, compliance
These factors shape the test strategy, the techniques used, the degree of automation, the required coverage, the level of detail in testware and the reporting.
1.4.3 Testware (K2)
Testware is the set of work products created by the test activities. Configuration management (chapter 5) keeps it consistent.
| Activity | Typical testware |
|---|---|
| Test planning | Test plan, test schedule, risk register, entry and exit criteria |
| Monitoring and control | Test progress reports, documented control directives, risk information |
| Test analysis | Prioritised test conditions (for example acceptance criteria), defect reports about the test basis |
| Test design | Prioritised test cases, test charters, coverage items, test data requirements, test environment requirements |
| Test implementation | Test procedures, manual and automated test scripts, test suites, test data, test execution schedule, environment items such as stubs, drivers, simulators and service virtualisations |
| Test execution | Test logs, defect reports |
| Test completion | Test completion report, improvement actions, lessons learned, change requests (for example product backlog items) |
A risk register lists the risks with their likelihood, impact and mitigation.
1.4.4 Traceability between the test basis and testware (K2)
Traceability means keeping links between test basis items (requirements, user stories, risks), the testware for them (test conditions, test cases), the test results and the defects.
Why it matters:
- Coverage evaluation: tracing test cases to requirements shows which requirements are tested.
- Residual risk: tracing test results to risks shows how much risk remains.
- Impact analysis: when a requirement changes, you know which tests to update.
- Audits and IT governance: you can prove what was tested.
- Clear reporting: progress and completion reports can show status per requirement, which business stakeholders understand.
1.4.5 Roles in testing (K2)
The syllabus describes two principal roles:
| Test management role | Testing role | |
|---|---|---|
| Responsible for | The test process, the test team and leadership of test activities | The engineering (technical) side of testing |
| Main activities | Test planning, monitoring, control and completion | Test analysis, design, implementation and execution |
These are roles, not job titles. A team leader, test manager or development manager can play the test management role, and in Agile teams some management tasks are handled by the team itself. One person can hold both roles at the same time.
1.5 Essential skills and good practices in testing
1.5.1 Generic skills required for testing (K2)
| Skill | Why it helps |
|---|---|
| Testing knowledge | More effective testing, for example by using test techniques |
| Thoroughness, carefulness, curiosity, attention to detail, being methodical | Finding defects, especially hard-to-find ones |
| Communication, active listening, being a team player | Working with stakeholders and reporting defects so they are understood |
| Analytical thinking, critical thinking, creativity | More effective testing |
| Technical knowledge | More efficient testing, for example by using the right tools |
| Domain knowledge | Understanding and talking with end users and business representatives |
Testers often bring bad news, and people tend to blame the messenger. Confirmation bias makes it hard for authors to accept information that challenges what they believe. So testers should communicate defects constructively: describe facts, focus on the product rather than the person, and explain the impact.
1.5.2 Whole team approach (K1)
The whole team approach comes from Extreme Programming (XP). Any team member with the right skills can do any task, and everyone is responsible for quality. The team shares a workspace (physical or virtual).
Advantages:
- Better team dynamics, communication and collaboration
- Synergy from combining different skill sets
- Testers help business representatives write acceptance tests and agree test strategy and automation with developers
- Testing knowledge spreads across the team
It is not always appropriate: safety-critical systems, for example, may need a high level of independent testing.
1.5.3 Independence of testing (K2)
Independence makes testers more effective at finding defects because the tester’s cognitive biases differ from the author’s. It does not replace familiarity: developers can efficiently find many defects in their own code.
| Level of independence | Who tests |
|---|---|
| None | The author |
| Some | Peers from the same team |
| High | Testers outside the author’s team but inside the organisation |
| Very high | Testers from outside the organisation |
Most projects use several levels: developers do component and component integration testing, a test team does system and system integration testing, and business representatives do acceptance testing.
| Benefits | Drawbacks |
|---|---|
| Independent testers recognise different kinds of failures and defects because of different backgrounds, perspectives and biases | Isolation from the development team, leading to poor collaboration, communication problems or an adversarial relationship |
| They can verify, challenge or disprove assumptions made by stakeholders | Developers may lose their sense of responsibility for quality |
| Independent testers may be seen as a bottleneck or blamed for release delays |
Learning objectives checklist
| LO | Level | You should be able to… |
|---|---|---|
| FL-1.1.1 | K1 | Identify typical test objectives |
| FL-1.1.2 | K2 | Differentiate testing from debugging |
| FL-1.2.1 | K2 | Give examples of why testing is necessary |
| FL-1.2.2 | K1 | Recall the relation between testing and quality assurance |
| FL-1.2.3 | K2 | Distinguish root cause, error, defect and failure |
| FL-1.3.1 | K2 | Explain the seven testing principles |
| FL-1.4.1 | K2 | Explain the test activities and their tasks |
| FL-1.4.2 | K2 | Explain how context affects the test process |
| FL-1.4.3 | K2 | Differentiate the testware of each activity |
| FL-1.4.4 | K2 | Explain the value of traceability |
| FL-1.4.5 | K2 | Compare the test management and testing roles |
| FL-1.5.1 | K2 | Give examples of generic testing skills |
| FL-1.5.2 | K1 | Recall the advantages of the whole team approach |
| FL-1.5.3 | K2 | Distinguish benefits and drawbacks of independent testing |
Chapter 1 self-check (12 questions)
Which of the following is a typical objective of testing?
- A. Proving that the software contains no defects
- B. Building confidence in the quality of the test object
- C. Removing the defects that caused failures
- D. Improving the development process followed by the team
Show answer
Answer: B. Building confidence in the quality of the test object
Building confidence is one of the listed test objectives. Testing cannot prove the absence of defects (principle 1), removing defects is debugging, and improving processes is quality assurance.
A tester runs a test and the order total is wrong. A developer then finds the wrong line of code and corrects it. Which statement is correct?
- A. Both the tester and the developer were debugging
- B. The tester was debugging and the developer was testing
- C. The tester was testing and the developer was debugging
- D. Both the tester and the developer were testing
Show answer
Answer: C. The tester was testing and the developer was debugging
The tester’s test triggered a failure, which is testing. Finding, analysing and removing the defect that caused it is debugging.
A reviewer finds a wrong formula in a design document. Which debugging steps are needed?
- A. Reproduction, diagnosis and fixing
- B. Diagnosis and fixing only
- C. Only removing the defect
- D. None, because static testing defects are not fixed
Show answer
Answer: C. Only removing the defect
Static testing finds the defect directly and cannot cause a failure, so there is nothing to reproduce or diagnose. Debugging is just removing it.
Which statement best describes the relation between testing and quality assurance?
- A. Testing is process-oriented and preventive; QA is product-oriented and corrective
- B. Testing is product-oriented and corrective; QA is process-oriented and preventive
- C. Testing and QA are the same activity with different names
- D. QA is done only by the test team; testing is everyone’s responsibility
Show answer
Answer: B. Testing is product-oriented and corrective; QA is process-oriented and preventive
Testing is a form of quality control focused on the product. QA focuses on processes, aims to prevent defects and is everyone’s responsibility.
Under deadline pressure, a developer misreads a requirement and codes the wrong discount. Customers are later charged too much. What is the failure?
- A. The deadline pressure
- B. Misreading the requirement
- C. The wrong discount in the code
- D. Customers being charged too much
Show answer
Answer: D. Customers being charged too much
Deadline pressure is a root cause, misreading is the error, the wrong code is the defect, and the visible wrong behaviour in operation is the failure.
Which testing principle is best illustrated by “most of the production incidents came from the payment module”?
- A. Tests wear out
- B. Defects cluster together
- C. Early testing saves time and money
- D. Testing is context dependent
Show answer
Answer: B. Defects cluster together
A small number of components usually contain most of the defects or cause most failures, which is the Pareto-style defect clustering principle.
The same automated regression suite has passed for six months, yet customers keep reporting new defects. Which principle explains this?
- A. Exhaustive testing is impossible
- B. Absence-of-defects fallacy
- C. Tests wear out
- D. Testing shows the presence of defects
Show answer
Answer: C. Tests wear out
Repeating the same tests makes them less effective at finding new defects. The tests and test data need to be updated and new tests added.
In which test activity are test conditions identified and prioritised?
- A. Test planning
- B. Test analysis
- C. Test design
- D. Test implementation
Show answer
Answer: B. Test analysis
Test analysis decides “what to test” by analysing the test basis and defining prioritised test conditions. Test design then decides “how to test”.
Which work product is typically created during test implementation?
- A. Test completion report
- B. Risk register
- C. Test execution schedule
- D. Test conditions
Show answer
Answer: C. Test execution schedule
Test implementation produces test procedures, scripts, suites, test data and the test execution schedule. The completion report comes from test completion, the risk register from planning and test conditions from analysis.
A requirement changes late in the project. Which benefit of traceability helps the team most?
- A. It reduces the number of test cases needed
- B. It shows which test cases are affected by the change
- C. It removes the need for regression testing
- D. It guarantees that all defects are found
Show answer
Answer: B. It shows which test cases are affected by the change
Traceability between the test basis and the testware supports impact analysis, so the team knows which tests to update and rerun.
Which activity belongs mainly to the testing role rather than the test management role?
- A. Test planning
- B. Test monitoring and control
- C. Test design
- D. Test completion
Show answer
Answer: C. Test design
The testing role focuses on test analysis, design, implementation and execution. The test management role focuses on planning, monitoring, control and completion.
Which is a drawback of independent testing?
- A. Independent testers have the same biases as the developers
- B. Developers may lose their sense of responsibility for quality
- C. Independent testers cannot challenge stakeholder assumptions
- D. Independence always slows down defect detection
Show answer
Answer: B. Developers may lose their sense of responsibility for quality
A listed drawback is that developers may feel quality is “the testers’ job”. Independent testers have different biases and can challenge assumptions, which are benefits.
Next: Chapter 2: Testing Throughout the SDLC, or follow the preparation guide study plan.