Testing Throughout the Software Development Lifecycle

Different SDLC models organize work differently — and that affects when and how testing is performed.

Sequential models (e.g. waterfall, V-model)

Each phase ends before the next begins. The V-model pairs each development activity with a corresponding test level (e.g. requirements ↔ acceptance tests, design ↔ system tests).

Iterative and Incremental models

Software is built in increments; each increment is tested and the system grows over time. Examples: RUP, Spiral, Prototyping.

Agile / DevOps

Short iterations, continuous feedback, test-first practices (TDD, BDD, ATDD), CI/CD pipelines, and a whole-team approach to quality.

Good testing practices that apply to all SDLCs

• For every development activity there is a corresponding test activity.
• Each test level has specific and different test objectives.
• Test analysis and design begin during the corresponding development activity.
• Testers are involved in reviewing work products as soon as drafts are available.

Shift-left

Performing testing activities earlier in the lifecycle (e.g. reviewing requirements, writing tests before code) to find defects sooner and reduce cost.

Retrospectives

Periodic meetings (often after an iteration) where the team identifies what went well, what didn't, and improvement actions — a key mechanism for continuous process improvement.

Test Levels

• Component testing (unit testing): tests individual components in isolation; usually done by developers.
• Component integration testing: tests interactions between components.
• System testing: tests the integrated system end-to-end against requirements.
• System integration testing: tests interactions of the system with external systems and services.
• Acceptance testing: validates fitness for use, typically by users / customers (UAT, contract, regulation, alpha/beta, operational AT).

Each level has its own test basis, test objects, defects, approach and responsibilities.

Test Types

• Functional: what the system does (features, business rules).
• Non-functional: how well the system does it (performance, usability, security, reliability, portability, maintainability, compatibility).
• Black-box: based on specifications; no knowledge of internals.
• White-box (structure-based): based on internal structure (code, architecture).
• Change-related: confirmation and regression testing.

Confirmation vs Regression Testing

Confirmation testing re-executes tests that failed previously to verify a defect has been fixed. Regression testing checks that changes have not introduced or uncovered defects in unchanged areas.

Once deployed, software is enhanced, corrected or adapted. Maintenance testing covers both changes to the system and the migration/retirement of systems.

Triggers

• Modifications (planned enhancements, corrective changes, hot fixes)
• Migration (e.g. new platform), conversion of data, integration of new components
• Retirement (e.g. archiving data, validating procedures for system shutdown)

Impact Analysis

Identifies areas of the system that may be affected by a change. Drives the scope of regression testing.