The SDLC: From Idea to Release

You can't place testing inside a process you've never seen. Software doesn't leap from idea to app store in one bound — it moves through recognizable stages, and the industry calls the whole journey the software development life cycle, or SDLC. This chapter is a one-stop tour of that journey, told from the tester's seat: where your work fits, and why the answer has changed dramatically over the decades.

One honest note before we start: this is the compressed version. How software gets built is a whole discipline with its own book on this platform — Software Development from Zero — and this chapter takes only what a tester needs from it.

The Stages

Strip away the methodology wars and every piece of software passes through the same stages. Planning — someone decides the thing is worth building. Requirements — what exactly should it do? (The next-but-one topic is devoted to these — they're your raw material.) Design — how will it be shaped, technically and visually? Building — developers write the code. Testing — the comparison of is-versus-should that you now know well. Release — the software reaches users. And operation — it runs, gets fixed, and keeps evolving, usually for years. Most of a product's life is spent in that last stage, which surprises everyone the first time they hear it.

The stages themselves are uncontroversial. The fight — and it shaped the entire history of this industry — is about how to arrange them.

The Old Arrangement: Waterfall

The oldest arrangement runs the stages once, in strict order, each fully finished before the next begins — like water flowing down a staircase, which is why everyone calls it waterfall. Gather all the requirements, sign them off. Design everything, sign it off. Build everything. Then — and only then — test everything, release everything.

Be fair to waterfall: it's clear, it's plannable, and in some industries it genuinely fits — a hospital system built to a fixed regulatory contract, or the software in an aircraft, where requirements truly are pinned down years ahead. If you ever work in such a domain, you'll meet it alive and well. But notice where testing sits: at the end, after months or years of building.

Why Late Testing Hurts

Now connect this to the cost-of-defect curve from Chapter 1. In waterfall, the tester meets the product when every mistake in it is already months old — woven into design decisions, built upon by later code, as expensive to remove as a mis-poured foundation under a finished house. The requirement that two developers read two different ways back in January? You discover it in October, and the fix touches everything built on top of it since.

Think of writing a book with an editor who is handed the finished 400-page manuscript the week before printing — versus an editor involved from the outline, chapter by chapter. Same editor, same skills, wildly different value. The industry spent decades learning that lesson, and the modern arrangement is the result.

The Modern Arrangement: Small Loops

Modern teams run the same stages as a loop — a small one, over and over. Take a thin slice of the product (one feature, or less), plan it, build it, test it, and ship it, in a cycle measured in weeks or even days. Then repeat, forever. Each pass is tiny, so mistakes are found while they're young and cheap; each release is small, so a bad one is easy to trace and undo. This family of approaches is called iterative development, and its most famous member — agile — gets the whole next topic, because it defines the daily rhythm of nearly every team you'll interview with.

For a tester, the difference between the two arrangements isn't academic — it's the difference between two different jobs. In waterfall, testing is a phase and you're staffed onto it near the end. In iterative work, testing is an activity that happens continuously, inside every loop, on every slice. Same skills, completely different calendar.

What This Looked Like at Fernway

Fernway's double-discount disaster — the refund weekend that created your job — was partly a process failure. There was no deliberate testing stage at all: each developer tried their own changes before merging them, a sort of accidental mini-waterfall with the test step deleted. The promo code worked when Omar tried it. The member discount worked when Lucy tried it. Nobody's job was to try them together, so nobody did. Nadia's first process fix is exactly what this chapter is about: deciding, on purpose, where testing lives in Fernway's cycle — which, as you'll see next topic, means weaving it into every sprint rather than bolting it onto the end.