Topic 3 — The software development and testing lifecycle

Goal: Understand how software is built and where testing fits in.

Lesson 3.1 — The assembly line the feature rides on

On her third day at FreshCart, Nadia got handed a build to test and froze. Where did this thing come from, and what am I supposed to hand back? Marcus, her mentor, drew six boxes on a whiteboard and connected them with arrows. "Every feature you'll ever touch rides along this," he said. "Knowing where you are on it is half the job."

He'd drawn the Software Development Life Cycle (SDLC) — the repeatable path a piece of software travels from idea to live product:

1. Requirements — decide what to build. Tom, the PM, writes a spec: "Customers can apply a promo code at checkout."
2. Design — plan how it works and looks. Where does the code box go, what does the screen show, what happens when the code is invalid.
3. Development — Priya, the senior developer, writes the actual code.
4. Testing — Nadia checks that it does what the spec promised. This is your stage.
5. Release / Deployment — it goes live; real customers start using it.
6. Maintenance — ongoing fixes, tweaks, and improvements once it's out there.

Two things made it click for Nadia. QA sits in the middle of a chain, not off to the side: she receives work from development and hands findings back to it. And that position carries weight — if she sits on a build for three days, the whole release slips three days. Her timing is the team's timing.

QA doesn't work in a vacuum. You take the baton from development and pass it back, which means everyone downstream is waiting on how fast and how carefully you run.

It was the same instinct that made Nadia good at the pharmacy: a prescription moved through a fixed set of checks, and the person verifying it was a link in a chain, not a bystander.

Lesson 3.2 — Why nobody waits until the end anymore

Marcus erased the tidy line of boxes. "There's an old way to read that diagram," he said, "and it'll get you a job in 2005."

The old way ran every box once, in order, start to finish: spend months on requirements, months on design, months coding, then hand the finished thing to QA at the very end to find everything wrong with it. The trouble is obvious once you've lived it — by the time testing starts, a mistake made back in requirements has had months to harden into a hundred places in the code. Catching it then is brutally expensive.

So FreshCart, like most modern teams, works in an agile way. Instead of building the entire app and testing it once at the end, the team builds in short cycles called sprints — at FreshCart, two weeks each — and tests continuously as small pieces get finished.

A sprint is a fixed, repeating window. The team picks a handful of small items ("apply a promo code," "show the driver's position on the map"), builds them, tests them, and ships them inside those two weeks. Then the next sprint starts. The SDLC stages still happen — requirements, design, development, testing — but in miniature, over and over, on small slices instead of once on the whole product.

For Nadia, the difference is when she shows up. She isn't summoned at the end of a six-month march; she's in the room on day one of the sprint, when Tom is still explaining what "apply a promo code" should do. Other tracks teach agile in depth. For QA, the part that matters is simple: you participate from the start of every sprint, not the finish.

Lesson 3.3 — Shift left: testing earlier, on purpose

In Nadia's first sprint planning meeting, Tom read out a requirement: "Customers can apply a promo code at checkout." Marcus, beside her, raised a hand. "What happens if they apply two codes? What if the code expired yesterday? What if the cart's empty?"

Nadia thought testing started when there was something to test. Marcus was testing the sentence, before a single line of code existed.

That move has a name: shift left. Picture the SDLC as a timeline running left to right, requirements on the left, release on the right. Shifting left means dragging testing activity earlier — toward the start — instead of leaving it bunched at the right edge. Concretely, it means QA reviewing requirements, asking the awkward questions, and planning tests before the code is written, not only checking the product after.

The reason is the cost rule from Topic 1, made specific. A defect caught in requirements is a one-sentence edit. The same defect caught after release is an emergency: a broken checkout, refunds, an engineer paged at midnight. The industry rule of thumb is that a bug gets roughly ten times more expensive to fix at each stage it slips through — cheap in requirements, painful in QA, ruinous in production.

The cheapest bug is the one you stop in a sentence before anyone writes the code.

Marcus's three questions cost the team two minutes in a meeting. If the promo-code feature had shipped without anyone thinking about an expired code, FreshCart could have handed out broken discounts to thousands of real carts. That's the whole argument for shift left: a QA who thinks early and collaborates is worth far more than one who only inspects finished work at the gate.

Lesson 3.4 — The testing pyramid

A week in, Nadia asked the question everyone new asks: if I'm testing the app by hand, what are all those "tests" the developers keep mentioning? Dev, the automation engineer, sketched a triangle.

The testing pyramid is a picture of the levels at which software gets tested, stacked from small-and-many at the bottom to large-and-few at the top. The shape is the point: wide at the base, narrow at the peak.

Level	What it checks	Speed & count
Unit (bottom)	one tiny piece of code in isolation	hundreds, run in seconds
Integration (middle)	two pieces working together	fewer, a bit slower
System / end-to-end (top)	the whole product, like a real user	few, slow, costly

Reading bottom to top:

• Unit tests check a single tiny piece of code on its own — does the function that adds up the cart total return the right number? Hundreds of them run in seconds, on every commit, and Priya writes them as she writes the feature. They're the wide base because they're fast and cheap.
• Integration tests check that separate pieces work together — does FreshCart's checkout correctly talk to the payment service and get back a "paid" confirmation? Fewer of these, and a little slower.
• System / end-to-end (E2E) tests drive the whole product the way a customer would: open the app, fill a cart, apply a promo code, pay, watch the driver appear on the map. Slow and expensive, so you keep them few — the narrow tip.

The wide-to-narrow shape carries the lesson: many fast cheap tests at the bottom, few slow costly tests at the top. A team that inverts it — a handful of unit tests and a mountain of slow E2E ones — ends up with a suite that takes an hour to run and breaks constantly. (Above the pyramid sits one more check, acceptance / UAT, which we'll place next.)

Lesson 3.5 — Where you actually stand

Nadia looked at Dev's triangle and asked the only question that mattered to her: "So which layer is mine?"

Dev pointed at the top two. Manual QA spends most of its time at the system / end-to-end and acceptance levels — testing the real, assembled product the way a customer would — while developers like Priya own the lower, code-level unit and integration tests. That division is worth memorizing, because it tells you exactly where a manual tester adds value and where they don't.

The reason is clean. A unit test can confirm the promo-code math is correct, but it can't tell you the discount field is invisible on a small phone, or that the "Apply" button does nothing on a slow connection. Catching that takes a human using the product. That's Nadia.

The top of the picture is acceptance testing, often called UAT (User Acceptance Testing). This is the final confirmation that the product meets the requirements and is acceptable to the business or the user, usually the last check before release. Where unit tests ask "is this code correct?", acceptance asks "is this the thing Tom actually asked for, and would a customer accept it?" It's less about hunting bugs than signing off against the original spec.

So the full stack, bottom to top: developers guard the code with unit and integration tests; Nadia exercises the whole product at the system / E2E level; acceptance is the final yes against the requirements. Living at the top is the layer closest to the real customer experience, and the one no automated unit test can cover.

Worked example — One promo code, all the way up

Watch a single FreshCart feature travel the entire topic. Tom writes the requirement: "A customer can enter a promo code at checkout and get the discount, unless the code is expired or the cart is empty."

Shift left, before any code. In sprint planning, Nadia and Marcus pick the requirement apart: What about two codes at once? A code typed in lowercase? An expired code? Tom hadn't decided on the expired case, so he adds a line to the spec right there. A whole class of bug, fixed in a sentence — cost: thirty seconds.

Down at the base. Priya builds the feature and, as she goes, writes unit tests: given a 20%-off code and a $50 cart, the discount function returns $40. Hundreds of these run in seconds when she commits.

The middle. An integration test confirms checkout and the payment service agree on the final discounted total — that the two pieces, wired together, hand each other the right number.

Nadia's floor. She runs the system / end-to-end test by hand: open the app, build a real cart, type the promo code, and watch what the customer would see. The math is right, but the discount line renders off-screen on a small phone, and an expired code shows a blank error instead of a message. Neither bug exists in the code's logic — both only appear when a human uses the assembled product. She files them.

The final yes. After fixes, acceptance / UAT checks the feature against Tom's spec line by line: discount applies, expired code is rejected with a clear message, empty cart is handled. It matches. The feature ships.

One requirement. Every level of the pyramid. And the highest-value catches — the off-screen discount, the blank error — came from the human at the top, exactly where a manual QA lives.