Software Testing Fundamentals
Software Testing Fundamentals tests whether you understand what testing is for and where it sits among quality activities. CAST questions in this domain are conceptual: definitions, the defect chain, test levels, and the principles that explain why exhaustive testing is impossible and why risk must drive coverage.
The core vocabulary
- Error → defect → failure. An error is a human mistake; a defect is the resulting flaw in a work product (requirement, design, code); a failure is the observable deviation from expected behaviour when the defect executes.
- Verification asks "did we build the product right?" against specifications and design. Validation asks "did we build the right product?" against user needs. Reviews and unit tests are verification; acceptance testing is validation.
- Quality assurance is process-oriented and preventive. Quality control and testing are product-oriented and detective.
- Testing vs debugging: testing finds and reports; debugging locates, fixes, and triggers retesting.
Principles that drive exam answers
- Testing shows the presence of defects, not their absence.
- Exhaustive testing is impossible; risk and priority decide what to cover.
- Test early - a requirements defect costs far less to fix than a production one.
- Defects cluster; a small number of modules usually carry most failures.
- Pesticide paradox: repeating the same tests stops finding new bugs.
- Testing is context dependent; a medical device and a marketing site need different rigour.
- Absence-of-errors fallacy: a bug-free product that does not meet user needs still fails.
Test levels
The sequence is unit → integration → system → acceptance. Each level has its own objective, owner, environment, and exit criteria. The V-model maps each development stage to a corresponding test level, so requirements work pairs with acceptance testing and design work pairs with integration testing.
Worked example
A requirement says: "The report must export to PDF in under 3 seconds." A tester reads the code and confirms the PDF library is invoked. Separately, a business user exports a 500-page report and times it.
Reasoning: the code inspection is verification against design. The timed user export is validation against the need. The 3-second measurement is a non-functional (performance) check at system or acceptance level. Neither activity alone proves both correctness and usefulness, which is exactly why levels are layered rather than substituted.
Traps that cost marks
- Treating verification and validation as synonyms.
- Claiming testing "proves" correctness.
- Confusing QA (process) with QC/testing (product).
- Assuming a low defect count at one level means the release is safe.