Test Levels, Test Types, and the Software Development Lifecycle
Domain focus
This domain examines how testing is organized by level and type across the software development lifecycle (SDLC). You must distinguish component, integration, system, and acceptance testing, and select functional, non-functional, structural, and change-related types.
Levels and types
- Component (unit) testing checks individual units in isolation, often with stubs and drivers.
- Integration testing checks interfaces and interactions between components or systems; approaches include big-bang, top-down, bottom-up, and sandwich.
- System testing checks end-to-end behavior of the complete system against requirements, including non-functional characteristics.
- Acceptance testing establishes readiness for use; forms include user, operational, contractual, regulatory, and alpha/beta.
- Functional testing checks what the system does; non-functional testing checks how well it does it (performance, security, usability, reliability).
- Change-related testing includes confirmation testing (does the fix work?) and regression testing (did the change break anything?).
SDLC context
Sequential models such as waterfall and the V-model emphasize phase gates and early test planning; the V-model pairs each development level with a test level. Iterative and agile models interleave testing with development, favor shift-left, and rely on automation and continuous integration. Test levels may overlap in agile, but the questions they ask remain distinct.
Worked example
An online shop calculates sales tax in a component, sends the order to a payment service, and displays a confirmation. A component test checks the tax function with boundary rates. Integration testing checks the order-to-payment interface, including timeout and duplicate-submit behavior. System testing runs a complete purchase journey with performance and security checks. Acceptance testing asks whether the business can go live. After a tax fix, a regression suite re-runs the purchase journey because the change could break checkout.
Traps
Confusing integration with system testing is common: integration focuses on interfaces, system on end-to-end requirements. Treating acceptance testing as only user acceptance ignores contractual and regulatory forms. Forgetting regression after a fix is a classic mark-loser.