Software Development Life Cycle (SDLC)

Kid-level picture: building with LEGO instructions

Before you snap bricks together, you decide what you are building (requirements), sketch how rooms connect (design), assemble pieces (implementation), check whether doors really open (testing), show your parents (deployment), and repair loose plates later (maintenance). Software follows the same rhythm—just with code, databases, and APIs instead of plastic bricks.

Classic phases and what usually happens

1. Planning / feasibility: why build this? Budget, timelines, regulatory constraints. Testing tie-in: identify compliance needs (accessibility, audit trails) before architecture locks in.
2. Requirements analysis: capture behaviours, data rules, integrations. Testing tie-in: reviewers hunt ambiguity (“fast response”) that would become arguing bugs later.
3. Design: architecture, APIs, UX flows. Testing tie-in: testability features—feature flags, structured logs, mocking seams—are cheapest here.
4. Implementation (coding): developers ship increments. Testing tie-in: unit checks, pair review, static analysis, CI compilation—all qualify as quality work.
5. Testing (verification): integration, system, performance, security suites validate the integrated product against requirements.
6. Deployment / release: ship to staging, canary, or production; monitor telemetry.
7. Maintenance: patches, scaling events, dependency upgrades—each triggers selective regression.

Worked example: booking widget for barbershops

Requirements: customers choose stylist, slot length, and SMS reminders.

Design: REST endpoints for availability plus a lightweight web component embedded on partner sites.

Implementation & testing: engineers mock SMS providers in CI, testers script double-booking attempts, product validates UX with pilot shops.

Deployment & maintenance: rollout per geography; later upgrades adjust for daylight-saving bugs surfaced by real users—feeding maintenance testing.

Intermediate+: SDLC when phases overlap

CI/CD, trunk-based development, and DevOps compress the linear diagram into loops: tiny requirements feed tiny designs which ship behind toggles. Testing morphs into continuous automation, observability-driven experiments, and production experimentation—yet the underlying concerns remain (risk, evidence, governance).

Expert notes

Enterprise SDLC frameworks often add formal gates (architecture review boards, segregation-of-duty approvals). Test managers contribute evidence packs: coverage of regulatory clauses, defect trends, environment parity statements. Align vocabulary with SDLC models such as Waterfall or V-Model when negotiating staffing—each model shifts when testers formally enter (see SDLC Models lessons in this sidebar).

Takeaways

• SDLC names phases; your daily job is collaborating inside those phases—not waiting for a mythical “testing phase” at the end.
• Earliest phases determine how expensive fixes become—push clarity and test hooks upstream.
• Modern agility changes rhythm, not the need for disciplined verification before risky releases.