Software Testing Fundamentals and Process Models
Software Testing Fundamentals and Process Models
This domain tests whether you understand what testing is for, which principles constrain it, and which activities and documents make up a controlled test process. Expect definition questions, principle-recognition questions, and document-identification questions.
Definitions and objectives
- Myers' classic definition: testing is executing a program with the intent of finding errors. Testing is destructive in intent, not confirmatory.
- Testing shows the presence of defects, never their absence; exhaustive testing is impossible except for trivial inputs.
- Testing finds the problem; debugging locates the faulty statement and fixes it. Independence of the test team raises the chance that defects surface.
- The purpose changes by level: unit testing verifies code units, system testing validates end-to-end behaviour against requirements, acceptance testing judges business fitness.
Principles that generate exam questions
- Early testing: defects found in requirements cost orders of magnitude less than those found in operation.
- Defect clustering: a small number of modules contains most defects (Pareto effect), so risk-based sampling is rational.
- Pesticide paradox: the same tests stop finding new defects; they must be reviewed and extended.
- Context dependence: safety-critical and web-commerce systems need different depth and techniques.
- Absence-of-errors fallacy: a defect-free system that does not meet user needs is still a failure.
The test process
Typical activities are planning; monitoring and control; analysis (what to test); design (how, i.e., conditions and cases); implementation (scripts, data, environment); execution; and closure (lessons learned, testware archiving). Entry and exit criteria gate each transition, and the test plan records them.
Worked example
A question asks which document records, during execution, what was run, by whom, and with what result. Reasoning: a test case specification defines inputs and expected results in advance; a test procedure specification gives the execution order; a test log records actual execution events; a test incident report is raised only for a discrepancy. The answer is the test log. Related documents from the test documentation standard family include the test plan, test design specification, test case specification, test procedure specification, test item transmittal report, and test summary report.
Process models
- V-model: mirror test levels, early design.
- W-model: testing runs in parallel with every development phase, including requirements and design reviews (static testing).
- H-model: independent modules are developed and tested in parallel, then integrated.
- TMM: five maturity levels - initial, phase definition, integration, management and measurement, optimization.
Traps
Assuming a zero-defect product is releasable; treating static review as not testing; thinking an independent team removes the developer's duty to test their own code.
Key ideas
Principles and process vocabulary are quoted verbatim in stems, so learn the exact conditions under which each principle applies.