6.3Testing and quality assurance

The idea that "testing can all be lumped together at the end" does not hold for a level-4 designer. A systems architect is responsible for designing which test at which stage of development (unit, then integration, then whole-system, then requester acceptance) guarantees what, and for judging from data whether testing progress itself is converging normally. Getting the test-process design wrong lets fatal defects surface only after go-live, sending rework cost soaring.

6.3.1Unit, integration, system, and acceptance testing

• Unit testing verifies the smallest unit—a function, class, or module—in isolation. Developers themselves conduct it, and it can closely check internal logic branches and boundary values, but it cannot detect defects in the interaction between modules (such as interface mismatches).
• Integration testing verifies, by combining multiple already unit-tested modules, whether the interfaces between them (data hand-off, call order, etc.) work correctly. System testing verifies, in an environment close to actual operation, whether the whole integrated system satisfies the business requirements and non-functional requirements (performance, availability, etc.).
• Acceptance testing is a final confirmation, led by the users or requester who commissioned the development, of whether the system is complete as required and usable in actual business operation. Unlike the developer-side tests, it differs in who conducts it, and the pass/fail criterion is whether the acceptance criteria agreed to by the requester are met.