The SDLC: how software gets built

Nobody builds a house by grabbing bricks at random. There's an order: plan it, design it, lay the foundation, build the walls, wire it, inspect it, hand over the keys. Software is built in an ordered way too, and that order has a name: the Software Development Life Cycle, or SDLC. Understanding it tells you where your job as a tester actually plugs in.

The SDLC is simply the journey a piece of software takes from "someone has an idea" to "real people are using it" and beyond. Different teams slice it into slightly different phases, but the core ones are remarkably consistent.

The phases of the SDLC

• Requirements: the team figures out what the software needs to do and who it's for. Output: a clear description of the goals.
• Design: the team plans how to build it (the structure, the screens, the data). Output: a blueprint.
• Development: developers turn the blueprint into working code. Output: the actual software.
• Testing: testers check the software against what was promised and hunt for defects. Output: a verdict on whether it's ready.
• Deployment: the software is released to real users. Output: a live product.
• Maintenance: the team fixes new issues, makes improvements, and keeps it healthy. Output: a product that stays useful over time.

The models: different ways to walk the same path

Every project goes through those phases, but how it moves through them differs. A model is the strategy a team uses to march through the SDLC. Three are essential to know.

Waterfall: one phase fully finished before the next begins

The oldest and simplest model. You complete each phase fully, then "flow down" to the next, like water over a series of steps. Requirements are 100% locked, then all the design, then all the code, then all the testing. It's clear and easy to manage, but rigid: testing happens near the very end, so problems are found late (and we know how that goes). It suits projects where requirements are stable and well understood, like some hardware or government work.

V-model: testing planned in lockstep with building

Think of the V-model as Waterfall folded into a V shape. As you go down the left side (requirements, design, code), you plan the matching tests on the right side at the same time. Each building stage gets a partner testing stage. This is a big improvement on plain Waterfall because testing is thought about early, even if the actual test execution still comes later. It's a clean illustration of verification and validation lining up with each build stage.

Agile / Scrum: small slices, repeated quickly

The modern default for most teams. Instead of one giant pass through all the phases, Agile breaks work into short cycles (often one to four weeks) called sprints (in the popular Scrum flavour of Agile). Each sprint delivers a small, working slice of the product, and every sprint includes requirements, building, and testing. Testing isn't a final gate. It happens continuously, every cycle, alongside development. This is shift-left baked right into the way the team works.

Waterfall vs Agile, side by side

There's no single "correct" model. Each fits different situations, which is principle 6 again (testing is context dependent) showing up at the project level. That said, Agile is what you'll meet most often in 2026, so it's worth getting comfortable with the words sprint, backlog, and stand-up early.