LEARN. PRACTICE. GROW.Concept and mechanism
Component tests observe isolated parts; component integration evaluates internal interactions; system tests observe the complete system; system integration addresses relationships between distinct systems; acceptance evaluates suitability for relevant needs. Level is not type: functionality, performance, security, and other characteristics can be evaluated at different levels. After fixing a defect, confirmation revisits the failing behavior. Regression seeks adverse effects of the change in related or previously working areas. Selection should follow impact and risk, not merely team structure.
Guided application
For a database migration, identify affected queries, transactions, recovery behavior, and consumers even if functional requirements do not change. Prepare data and environments representing the risks. Earlier requirement review and fast pipeline tests reduce feedback delay but do not prove that later testing can be removed. In short cycles, connect each increment to acceptance criteria and retain a sustainable regression strategy. Use retrospectives to improve the approach based on observed problems.
A rounding fix passes for the reported currency. Because the library is shared, select regression across other rules and channels before recommending release.
Common pitfalls
Confusing confirmation and regression; skipping tests on a migration without new features; treating unit tests as proof of the whole system.
Related topics: Review before code · Design cases and measure coverage
Relate each change to corrected behavior, possible side effects, and the required evidence level.
Reference: ISTQB CTFL syllabus v4.0.1 · CTFL v4.0; syllabus v4.0.1 (2024-09-15)