Summary of "ISTQB-FL | 1.1 Why is Testing necessary ?"
Concise summary
This video (part of an ISTQB Foundation Level series) covers Chapter 1.1: “Why testing is necessary.” It briefly mentions exam logistics, explains why software testing is important, how defects arise, when and where testing should happen, what testing achieves (quality, confidence, compliance, learning), and how to decide when you’ve done “enough” testing. The presenter also walks through two short example/exam-style questions.
Exam logistics (brief)
- Exam fee in the presenter’s country: 600 EGP.
- Registration via the Egyptian ISTQB website (not the international one).
- Example exam location: ITIDA in Smart Village; sessions often held the first Thursday of each month.
- Chapter 1 of the syllabus has 7 exam questions and is divided into 5 parts — the series covers each part separately.
Why testing is necessary
Software can behave unexpectedly (example: WhatsApp outage). Unexpected behavior can cause:
- Financial loss (fix costs and lost revenue).
- Damage to business reputation (users switching to competitors).
- Time and resource costs.
- Safety harm — injury or death in the worst cases (examples referenced).
Not every defect causes an immediate visible failure; many defects can exist without immediate impact. Detecting and fixing defects early reduces risk at release/operation time.
Defect lifecycle and terminology (key exam terms)
- Error (mistake / mis-implementation): a human action (e.g., a programmer makes a mistake).
- Fault / Defect: the incorrect code or state that results from the error.
- Failure: the observable incorrect behavior at runtime (the system does not meet a requirement).
Typical mapping emphasized for exam questions: error → fault/defect → failure
The presenter stresses these mappings and that exam questions often ask which term fits a given scenario.
Causes of faults / why defects appear
Common causes:
- Human error (everyone makes mistakes).
- Time pressure / tight schedules (rushed work).
- Complexity of code or system.
- Organizational or infrastructure issues (poor processes, poor communication).
- Changes in external technologies/platforms (e.g., new OS version).
- Integration/interactions between subsystems or external systems.
- Environmental/external factors beyond control (e.g., electromagnetic interference).
When and where testing happens
Testing is not a single moment; it occurs throughout the lifecycle:
- During development (unit/module/component testing).
- During defect-fix cycles.
- During operation (maintenance and monitoring).
Regression testing: re-running tests after changes to reduce the risk of introducing new problems.
What testing achieves / role of testing
Testing helps to:
- Reduce operational risks and the incidence of problems after release.
- Improve product quality by detecting and enabling correction of defects before release.
- Provide confidence in the product — when tests find few/no issues, stakeholders’ confidence increases.
- Ensure contractual, legal, and industry-specific compliance (country regulations, domain standards).
- Enable learning and process improvement: root-cause analysis supports preventing recurrence (quality assurance).
Distinction:
- Quality control (QC): focuses on the product — software testing is predominantly QC.
- Quality assurance (QA): focuses on improving processes across the organization.
Testing vs quality
- Testing and quality control are closely related; in many practical cases testing ≈ quality control (though they are not identical).
- Test results are relative — they describe the system in a given context and do not guarantee absolute quality.
Measuring correctness vs performance
- Functional correctness: does the feature do what it should? (e.g., a light turns on when a condition is met).
- Non-functional performance/efficiency: how well does it perform? (e.g., app load time, battery life).
A system can be functionally correct but perform poorly — which can still be a failure from a user or quality perspective.
When is testing “enough”? (stop-testing criteria and decision factors)
Stopping testing is not simply “when money/time run out.” Two main groups of factors determine adequacy of testing:
-
Risk level (most important)
- Technical risk: reliability, safety, security, and other technical concerns.
- Business risk: time-to-market, competitive positioning, and business impact.
-
Project constraints / context
- Timescale (deadlines), available resources (budget, people), scope.
Objective: provide enough information to stakeholders/decision-makers so they can decide whether the product is ready for release. Safety-critical systems require much more testing and different weighing of risks.
Exam-related advice and example logic
- Pay attention to exam vocabulary and the mappings (error → fault/defect → failure).
- Example question logic:
- Cause: programmer wrote wrong code (error).
- Result: a defect/fault exists (e.g., incorrect boundary handling).
- Observable: boundary value causes misbehavior (failure).
- Understand which term matches each step in the chain; English comprehension is required for the ISTQB exam.
Practical lessons and recommendations
- Test early and often, including regression testing after changes.
- Use defect root-cause analysis to improve processes and prevent recurrence.
- Consider both functional correctness and non-functional/performance aspects.
- Make release decisions based on risk assessment and the testing information provided; communicate clearly to stakeholders.
Speakers / examples referenced
Primary speaker: the course presenter (unnamed in subtitles).
Examples/organizations referenced by the presenter:
- WhatsApp (outage example)
- Samsung (battery/explosion example)
- Valeo (manufacturer referenced in an accident example)
- Volkswagen (example about not meeting industry/legal requirements)
- Uber and Careem (regulatory/market example)
- ITIDA (exam location example)
- Egyptian ISTQB website (registration)
Note: these are referenced as examples by the presenter; no other speakers are heard in the subtitles.
Category
Educational
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.