Test Levels and Test Types
Test Levels and Test Types
This domain checks that you can place a given test activity at the correct level, choose an integration strategy, and classify a test as functional, non-functional, structural or change-related. Questions are often scenario-based: a description of who tests what, and against which document.
Levels
- Component (unit) testing: smallest testable units, usually by the developer, driven by detailed design; needs stubs and drivers.
- Integration testing: verifies interfaces between components or subsystems. Strategies are big-bang (all at once, hard to localise faults), top-down (uses stubs, upper control flow tested early), bottom-up (uses drivers, low-level logic tested early), and sandwich/hybrid (combines both, meeting in the middle).
- System testing: end-to-end against the requirements specification, usually by an independent team, in an environment close to production.
- Acceptance testing: judges fitness for use. Alpha runs at the developer's site with user participation; beta runs at the user's site without developers present; contract and regulatory acceptance are formal variants with defined criteria.
Types
- Functional: features, business rules, data handling, interoperability.
- Non-functional: performance efficiency, reliability, security, usability, compatibility, maintainability, portability.
- Structural: white-box techniques applied to code structure.
- Change-related: confirmation (re)testing proves a specific fix works; regression testing checks that unchanged areas still work; smoke testing is a shallow build-acceptance check before deeper testing starts.
Worked example
A system has a stable top-level control module that schedules calls to lower subsystems, and the interface to the database is the riskiest area. Reasoning: a top-down strategy exercises the control flow early but needs stubs for every missing lower module; bottom-up exercises database access early but needs drivers. Because the control module is stable and available, top-down is chosen for the upper layers, then the database-critical subsystem is integrated bottom-up and the two meet using the sandwich approach. Counting artefacts: in a pure bottom-up build of m modules in a strict hierarchy, drivers equal the number of non-leaf nodes; in top-down, stubs equal the number of missing lower modules called.
Traps
Swapping alpha and beta; treating smoke testing as a synonym for regression; believing regression means re-running every test (impact analysis selects a subset); assuming unit tests are only about functions, not classes or components.
Key ideas
Each level answers a different question, and each has an owner and a reference document - the exam regularly asks which document a level is based on.