Fundamentals of testing
Chapter summary
Chapter 1 of the ISTQB Foundation Level syllabus covers what testing is and why it is necessary, the seven testing principles, the test process and its work products, traceability, the roles involved in testing, and the essential skills and practices testers rely on. The chapter carries 180 minutes of training time and accounts for 8 of the 40 exam questions (20% of the exam).
This page covers the main concepts in the chapter at a level that complements the full Chapter 1 guide.
What testing is
Testing is a set of activities designed to discover defects and evaluate the quality of software work products. The thing being tested is called the test object. Testing includes activities beyond running the software: test analysis, test design, planning, implementation, monitoring, and completion are all part of testing.
Testing can be dynamic (running the software and observing what happens) or static (examining a work product without running it, such as reviewing a requirements document). Both count as testing under the syllabus definition.
Testing is not the same as debugging. Testing finds failures and provides information about quality. Debugging is the activity of finding the cause of a failure and fixing it. After a fix, confirmation testing checks whether the fix worked, and regression testing checks that the fix did not break anything else.
Why testing is necessary
Testing contributes to project success by finding defects early, evaluating quality at defined points in the lifecycle, and giving stakeholders information to make release and go/no-go decisions. It also gives users an indirect voice in the product when involving real users directly is impractical.
Testing and quality assurance are different things. Testing is product-oriented and corrective. Quality assurance is process-oriented and preventive. The same test results can serve both purposes: testers use them to fix defects, and quality assurance uses them as feedback on how well the development process is working.
Errors (human mistakes) can cause defects in work products, and defects can cause failures when the software runs. Not every defect causes a failure. Some defects exist in code that is never executed under normal conditions. Some failures come from environmental causes rather than defects. Root cause analysis looks for the underlying reason a problem occurred, not just the immediate trigger.
The seven testing principles
The syllabus describes seven general principles about how testing behaves. In brief:
Testing shows the presence of defects but cannot prove their absence. Exhaustive testing is impossible except in trivial cases. Early testing saves time and money. Defects tend to cluster in a small number of components or areas. Repeating the same tests becomes less effective over time. Testing must be adapted to its context. Fixing all known defects does not guarantee a successful system.
These principles are worth understanding rather than memorizing as a list, because exam questions test whether you can recognize them in a described situation rather than simply recall their names.
Test activities, testware, and traceability
The test process consists of groups of activities: planning, monitoring and control, analysis, design, implementation, execution, and completion. In practice these groups overlap and are often revisited rather than completed in strict sequence.
Testware is the collective term for work products created during testing. A test plan, a risk register, test conditions, test cases, test scripts, test procedures, test logs, defect reports, and completion reports are all examples of testware.
Traceability links test basis elements (such as requirements or user stories) to testware (such as test conditions and test cases), test results, and defects. Maintaining traceability makes it possible to evaluate coverage, assess the impact of changes, and communicate testing status in meaningful terms to stakeholders.
Roles in testing
The syllabus describes two principal roles. The test management role covers planning, monitoring, control, and test completion. The testing role covers analysis, design, implementation, and execution. In practice, one person can hold both roles, and how they are divided depends on the context. In Agile teams, test management responsibilities are often shared across the whole team.
Skills and good practices
Effective testing requires analytical and critical thinking, attention to detail, communication skills, and domain knowledge alongside technical knowledge of tools and techniques. Testers often report unwelcome news, and the syllabus emphasizes communicating results constructively, focused on the product rather than the person who created it.
The whole team approach, from Extreme Programming, means any team member with the right skills can take on any task, and everyone shares responsibility for quality. Co-location and close collaboration between testers, developers, and business representatives supports this.
A degree of independence helps testers find defects that authors of a work product might overlook, because independent reviewers bring different assumptions and cognitive biases. The syllabus describes a spectrum from no independence (author tests their own work) to very high independence (testers from outside the organization).
Exam weight and K-levels
Chapter 1 contributes 8 questions to the exam (20%). All learning objectives in this chapter are K1 or K2. The focus is on recall and understanding rather than applying procedures. See the full Chapter 1 guide for a complete breakdown of each sub-topic and the learning objectives page for the full objective-by-objective breakdown.
Last reviewed: June 2026.