Chapter 1 — Fundamentals of testing

How to read this track

This is not a first course in testing — Track 1 is. This is exam preparation: the same material arranged the way the paper asks about it, with the distinctions that decide marks pulled to the front.

Chapter 1 supplies 8 of the 40 questions in our practice paper, which makes it the third-heaviest chapter, and by some distance the cheapest to score on. Every objective here is K1 (recall) or K2 (explain, compare, classify) — there is no K3 in this chapter, so no question can require you to apply a technique or work anything out. If you find yourself calculating, you have misread the question.

The chapter has 14 learning objectives across five sections:

Section	Objectives	What it wants
1.1 What testing is	2	Test objectives; testing versus debugging
1.2 Why it is necessary	3	Contribution to success; testing versus QA; error → defect → failure
1.3 Testing principles	1	All seven, and what each one licenses
1.4 Activities, testware, roles	5	The activities, context, testware, traceability, roles
1.5 Skills and practices	3	Tester skills; whole-team approach; independence

Section 1.4 is over a third of the chapter. Weight your revision accordingly.

1.1 What testing is

Testing is more than running tests. It includes planning, analysing, designing, reporting and evaluating — and it includes static work (reviewing a document) as well as dynamic work (executing software). A question that defines testing as "executing software to find defects" is offering you a distractor.

Typical objectives of testing — the list worth being able to recognise:

• evaluating work products: requirements, designs, code, user stories
• causing failures and finding defects
• ensuring the required coverage of a test object
• reducing the level of risk of inadequate quality
• verifying that specified requirements have been met
• validating that the object works as users expect and is fit for purpose
• building confidence, and providing information for decision-making
• complying with contractual, legal or regulatory requirements or standards

Verification and validation are a standing exam favourite: verification asks whether it was built right, validation asks whether the right thing was built. A product can pass every requirement and still fail validation.

Testing versus debugging. Different activities with different owners:

	Testing	Debugging
Finds	A failure	The cause of the failure
Then	Reports it	Reproduces, diagnoses, fixes
After the fix	Confirmation testing checks it	—

Two nuances the paper likes. Static testing can find a defect directly, with no failure involved, so nothing needs reproducing — the fix is all that remains. And in a whole-team setting a tester may well help debug; that does not make debugging a testing activity.

1.2 Why testing is necessary

How it contributes to success. Testing reduces the risk of failures in operation, is a cost-effective way of finding defects, helps meet contractual or regulatory obligations, and — the part people forget — prevents defects when testers are involved early, because reviewing a requirement removes a defect before any code carries it.

Testing is not quality assurance. This distinction is examined more often than its size suggests:

	Focus	Nature
Quality assurance	The process — is a good process being followed?	Preventive
Quality control	The product — does what we built meet the bar?	Corrective
Testing	A major form of quality control	Corrective

Fixing a defect improves the product; changing how requirements are reviewed so that class of defect stops arriving is QA.

Error, defect, failure, root cause. The causal chain, and the two exceptions that carry most of the marks:

1. A person makes an error (a mistake).
2. The error produces a defect in a work product (a fault in code, a document, a design).
3. If the defective code is executed under the right conditions, a failure occurs — the observable wrong behaviour.
4. The root cause is the origin of the error: the reason the mistake was made, and the thing an improvement should address.

• Not every defect causes a failure. Code that is never executed, or is executed only under conditions that never arise, hides its defect indefinitely.
• Not every failure is caused by a defect. Environmental conditions — radiation, electromagnetic interference, pollution — can alter execution without anybody having made a mistake.

If a question asks what causes a failure and offers both "a defect in the code" and "an error made by a developer", read carefully: the error caused the defect, the defect caused the failure.

1.3 The seven principles

One objective, but a reliable one to two questions. Track 1's seven principles lesson teaches them; here is what each one is for, because the paper tests the consequence rather than the name:

1. Testing shows the presence of defects, not their absence. Passing tests never prove correctness. Testing reduces the probability of undiscovered defects; it cannot get it to zero.
2. Exhaustive testing is impossible. Except for genuinely trivial cases, you cannot test every input and combination — which is why techniques, prioritisation and risk exist. This principle licenses the rest of the syllabus.
3. Early testing saves time and money. Static and dynamic testing started early find defects while they are cheap; this is the shift-left argument.
4. Defects cluster together. A small number of modules usually contains most of the defects, which is what makes it rational to concentrate effort where defects have already been found.
5. Tests wear out. Repeating the same tests stops finding new defects — the principle formerly known as the pesticide paradox. The response is to revise and add tests, not to abandon regression testing.
6. Testing is context dependent. There is no universally correct approach; a safety-critical system and an internal reporting tool are not tested the same way.
7. The absence-of-defects fallacy. Finding and fixing many defects does not guarantee success — a system that meets every requirement can still be unusable, or the wrong system entirely. This is principle 1 and validation meeting each other.

Principles 4 and 5 are the pair most often confused. Clustering is about where defects are; wearing out is about repetition losing its yield.

1.4 Test activities, testware and roles

The heaviest section: five objectives, and a third of the chapter's questions.

The activities. Seven of them, and they are not a strict sequence — they overlap, iterate, and in an iterative lifecycle run largely in parallel:

Activity	Produces	One-line job
Test planning	The test plan	Objectives, approach, resources, schedule
Test monitoring and control	Progress reports	Compare actual to plan; act on the difference
Test analysis	Test conditions	What to test — analyse the test basis
Test design	Test cases, coverage items	How to test it
Test implementation	Test procedures, data, suites, environment	Everything needed to be able to run
Test execution	Logs, defect reports	Run, compare actual to expected, report
Test completion	Completion report, archived testware	Close out, hand over, record lessons

Analysis versus design is the trap in this section. Analysis identifies what should be tested; design turns those conditions into concrete test cases. If a question describes deciding that the discount rule needs testing, that is analysis; deriving the boundary values for it is design.

Context shapes the process. Which activities you perform, how, and in what depth depends on the stakeholders and their expectations, the team's skills, the business domain, technical factors, project constraints (budget, time), the organisation, and the lifecycle in use. This is principle 6 as a process statement.

Testware is the output of the activities, and matching each artefact to its activity is directly examinable — the table above is that objective. Note the easy confusion: test cases come from design, test procedures and test data come from implementation.

Traceability between the test basis, test conditions, test cases and results is what lets you evaluate coverage, assess the impact of a change, audit the process, report status in terms stakeholders understand, and demonstrate that objectives were met. If a requirement changes, traceability tells you which tests are now suspect — that is its most examined benefit.

Roles, not job titles. Two roles: test management (planning, monitoring, control, completion reporting) and testing (analysis, design, implementation, execution). One person can hold both, and in a whole-team setting they can be spread across people who do not have "tester" in their job title.

1.5 Skills and good practices

Generic tester skills worth recognising: testing knowledge, thoroughness, curiosity and attention to detail, good communication (with developers and with stakeholders), analytical and critical thinking, domain knowledge, and technical knowledge. Communication is on the list deliberately — a defect nobody acts on was not usefully found.

The whole-team approach. Anyone with the necessary knowledge can perform any task, and everybody is responsible for quality. Benefits: better communication and collaboration, a quality mindset across the team, and testers contributing to requirements discussions where they prevent defects rather than find them. Its limitation is honest — it does not suit every context, which is principle 6 again.

Independence of testing, and it cuts both ways:

Benefits	Drawbacks
Independent testers recognise different kinds of failure	Isolation from the development team
They can challenge assumptions the authors cannot see	Developers may lose their sense of responsibility for quality
Bias is reduced — an author testing their own work is the weakest case	Independent testing can be seen as a bottleneck, and blamed for delay

A question asking for a drawback of independence is asking for one of the right column. "It costs more" is a plausible-sounding distractor that is not the syllabus's point.

The distinctions that decide marks

Everything above, compressed to what people actually get wrong:

Confused pair	The line between them
Testing / debugging	Finding a failure / finding and fixing its cause
QA / testing	Process, preventive / product, corrective
Error / defect / failure	Human mistake / fault in a work product / observed wrong behaviour
Verification / validation	Built right / built the right thing
Test analysis / test design	What to test / how to test it
Test cases / test procedures	Output of design / output of implementation
Defect clustering / tests wearing out	Where defects are / repetition losing yield
Role / job title	Two roles exist; one person may hold both

Drill it

Reading a chapter is not revision. Take the chapter 1 quiz — eight questions, untimed, every answer explained:

Chapter 1 quiz →

Score below 6 of 8 and the useful move is not re-reading this page, it is reading the explanations on the ones you missed and coming back tomorrow. Every explanation names the distinction being tested, and the distinctions are the chapter.

Next: Chapter 2 — testing throughout the software development lifecycle.