Fundamentals of Testing
Understand what testing really is, why it matters, the seven guiding principles, and the difference between errors, defects and failures.
Fundamentals of Testing video walkthrough
A guided overview of chapter 1, connecting the exam language to practical testing decisions.
Briefing focus
What is software testing, really?
This is a structured lesson briefing. Real video/audio can be added later as a media source.
Estimated time
8 min
- 1What is software testing, really?
- 2The seven testing principles
- 3Error · Defect · Failure — the chain of cause
- 4The fundamental test process
Transcript brief
Understand what testing really is, why it matters, the seven guiding principles, and the difference between errors, defects and failures. The walkthrough introduces the core concept, works through a realistic project example, and closes with the mistakes learners most often make in quiz and exam questions.
Key takeaways
- Recognise the exam wording for this chapter.
- Apply the concept to a real software delivery situation.
- Know which detail to check first when a scenario question feels ambiguous.
What is software testing, really?
Software testing is the process of evaluating a product to uncover differences between what it actually does and what it is supposed to do. But testing is about far more than just finding bugs — it is how teams build evidence that a product is fit for purpose, safe to release and aligned with business expectations.
A common misconception is that testing proves software works. In reality, testing can only show the presence of defects, never their absence. The goal of a professional tester is therefore to reduce risk to an acceptable level before release.
Real-life scenario · E-commerce
The £40,000 checkout bug
Situation. A UK fashion retailer launched a ‘Buy Now, Pay Later’ option on Black Friday. The feature worked perfectly in staging. In production, shoppers whose basket totalled exactly £0.00 after a voucher were still charged a £12 delivery fee — but the order confirmation showed ‘Free delivery’. Testing had focused on happy paths; no one had tested the £0 boundary with vouchers.
Lesson. Testing reduces risk, not just defects. One missed equivalence class cost £40,000 in refunds and a PR apology. Boundary and voucher-combination testing would have caught it in minutes.
The seven testing principles
The ISTQB syllabus builds its foundation on seven principles. Learn them by heart — they appear in the exam and in almost every real project.
| # | Principle | What it means in practice |
|---|---|---|
| 1 | Testing shows defects, not their absence | Passing tests never prove the system is bug-free — only that known risks were not triggered. |
| 2 | Exhaustive testing is impossible | You cannot test every input combination. Use risk-based prioritisation instead. |
| 3 | Early testing saves time and money | A requirement defect caught in a review costs ~1x; the same defect in production costs 30–100x. |
| 4 | Defects cluster together | A small number of modules usually contain most defects (Pareto 80/20 rule). |
| 5 | Beware of the pesticide paradox | Running identical tests repeatedly stops finding new defects — regularly review and refresh the suite. |
| 6 | Testing is context-dependent | Medical software needs different rigour than a social-media meme generator. |
| 7 | Absence-of-errors fallacy | A system with zero defects can still be a commercial failure if it doesn’t meet user needs. |
Exam tip
Be ready to match a short scenario to the correct principle. The exam rarely asks you to recite the principle list — it asks you to recognise it in a story.
Error · Defect · Failure — the chain of cause
- Error (mistake)
- A human action that produces an incorrect result. Example: a developer misreads a spec.
- Defect (bug, fault)
- An imperfection in a work product — e.g., the wrong formula written into the code.
- Failure
- The observable incorrect behaviour when the defective code is executed — e.g., VAT is calculated at 22% instead of 20%.
Real-life scenario · Banking
Interest mis-calculated for 3 months
Situation. A developer (error) misread the specification for a savings account and coded the compound interest formula as simple interest (defect). For 90 days, customers saw the wrong balance every night at 02:00 when the batch ran (failure). Root-cause analysis showed requirements were ambiguous — a reviewable defect-source, not just a coding one.
Lesson. Finding the failure is not enough. Professional testers investigate the root cause and feed it back to prevent recurrence.
The fundamental test process
- Test planning — define scope, objectives, approach and exit criteria.
- Test monitoring and control — track progress against the plan; raise alerts.
- Test analysis — ‘What will we test?’ Identify test conditions from the basis.
- Test design — ‘How will we test it?’ Derive high-level test cases.
- Test implementation — prepare test data, environments and executable scripts.
- Test execution — run tests, log defects, compare actual vs. expected.
- Test completion — archive artefacts, run retrospectives, report lessons learned.
Why testers study root cause analysis
If defects cluster (Principle 4) and early testing is cheapest (Principle 3), then understanding the source of defects is the single highest-leverage skill a QA engineer can develop.