SDLC and STLC

Development models

A development model is the “recipe” a team uses to move through the SDLC phases: in which order, how often and how strictly. The model decides when you, as a tester, get to see working software. That is why it matters so much to your day.

Waterfall

In the waterfall model, each phase is finished and signed off before the next begins, like water falling down a staircase. Requirements are written in full, then the whole design, then all the code, and only then does testing start.

• Good for: stable, well-understood requirements, strict documentation needs, fixed contracts.
• Weak at: change. If testers discover in month ten that a requirement was misunderstood in month one, a lot of work has to be redone, and there is usually little time left.

V-model

The V-model is waterfall bent into a “V”. The left side goes down through definition and design; coding sits at the bottom; the right side goes back up through test levels. Every phase on the left is paired with a test level on the right:

Left side (define)	Right side (test)
Requirements	Acceptance testingAcceptance testingTesting whether the product is ready to be accepted by the customer, users or business.Open in glossary →
System design	System testingSystem testingTesting the complete, integrated product as a whole against its requirements.Open in glossary →
Architecture	Integration testingIntegration testingTesting that different parts of the system work correctly together.Open in glossary →
Module design	Unit testingUnit testingTesting the smallest pieces of code, like a single function, usually by developers.Open in glossary →

The big idea: design the tests at the same time as the thing they will test. While the business writes “customers can apply one coupon per order”, testers already write the acceptance test for it. Writing a test is a great way to discover that a requirement is vague (“Is a free-delivery code a coupon too?”). The V-model is also a handy picture of two big questions: verificationVerificationChecking that we built the product right, according to its specification.Open in glossary → (“did we build it right?”, checked against the design) and validationValidationChecking that we built the right product, one that really meets users' needs.Open in glossary → (“did we build the right thing?”, checked against real needs). See Verification vs Validation. The four test levels get their own lesson: Levels of Testing.

Iterative and agile

Iterative models build the product in repeated cycles, adding and improving a bit each time. Agile is the most popular family of iterative approaches. Instead of one big release after a year, an agile team delivers a small, working, tested piece every few weeks and adjusts based on feedback.

Most agile teams use Scrum, which works in fixed time boxes called sprints, usually two weeks long:

In agile, testing is not a phase at the end. It is an activity that happens every day. The flip side: the app changes every sprint, so regression testingRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → keeps growing, and teams need a smart regression set (and usually some automation).

DevOps and continuous delivery

DevOps joins development (“Dev”) and operations (“Ops”, the people who run the servers) into one team with shared responsibility. A key practice is a pipeline: every time a developer pushes a change to the shared code, a server automatically builds the app and runs the automated tests (this is called continuous integration, or CI). If the change passes, it can be released quickly and safely (continuous delivery, or CD). Some web teams release many times a day; mobile teams are slower because app store releases need review, but they often ship weekly or every two weeks.

For a beginner, three things matter:

• Automated checks run on every change. A red (failed) pipeline means “not ready”.
• Manual testing doesn’t disappear. It moves to where humans add the most value: new features, exploratory testingExploratory testingLearning, designing and running tests at the same time, guided by curiosity and a goal.Open in glossary →, usability and risky areas.
• Production is watched closely. Crash reports, error logs and user feedback become a source of bugs, and new features are often switched on for a small group of users first.

The models side by side

Model	When you test	Best when
Waterfall	One big phase near the end	Requirements are fixed and well known
V-model	Design tests early, run them late	Strict quality or safety rules
Agile (Scrum)	Every day, inside each sprint	Requirements change and feedback matters
DevOps / CD	Continuously, mostly automated, plus manual for new work	Frequent, small releases

Real teams often mix: a “mostly agile” team with a waterfall-style release phase for a big launch is very common.

Why finding bugs late costs more

Imagine nobody wrote down the rule “one coupon per order”. Here is what fixing it costs at each stage:

The later a bug is found, the more it costs

Example: the coupon rule "one coupon per order" was never written down.

ReqsRequirements

DesignDesign

BuildDevelopment

TestTesting

LiveProduction

1. RequirementsEdit one sentence after a 5-minute chat.
2. DesignChange a mock-up or a diagram.
3. DevelopmentRewrite some code and its unit tests.
4. TestingBug report, fix, new build, retest, regression.
5. ProductionHotfix, app store review, support tickets, refunds, lost trust.

You may have seen charts claiming a bug costs “exactly 100 times more” in production. Be careful with precise numbers like that; they come from old studies of very different projects. The trend is what is real and widely agreed: the later a problem is found, the more work, people and risk its fix involves.

This is why modern teams shift left: they move testing activities earlier on the timeline. Shift-left doesn’t mean “test less at the end”. It means “also test at the beginning”: review requirements, discuss examples before coding, and test small pieces as soon as they exist.

Where testers get involved in each phase

SDLC phase	What a tester does
Requirements	Reads stories, asks “what if…?”, points out missing or untestable criteria
Design	Reviews mock-ups and flows, spots missing states (loading, error, empty)
Development	Plans testing, writes test cases, prepares data and devices, tests early builds
Testing	Runs tests, explores, reports bugs, retests fixes, runs regression
Deployment	Smoke tests the release candidate and then production
Maintenance	Tests hotfixes, checks user-reported bugs, updates the regression suite

The STLC: the testing life cycle

The software testing life cycle (STLC) describes the testing work itself, from “what are we testing?” to “here is what we found”. It runs inside the SDLC. (The ISTQB syllabus describes the same work as a “test process” with slightly different names, such as test analysis, test design, test implementation, test execution and test completion. The ideas match.)

Each phase has two kinds of rules:

• Entry criteria: what must be true before the phase can start. Like a recipe’s “you will need”: you can’t start baking without flour and an oven.
• Exit criteria: what must be true before the phase is “done”. Like “bake until golden and a toothpick comes out clean”. Without exit criteria, testing either never ends or ends whenever the deadline arrives.

SDLC vs STLC

	SDLC	STLC
Covers	Building the whole product	The testing work only
Who	Whole team	Mainly testers
Goal	Deliver working software	Find problems and give confidence
Relation	The big cycle	Runs inside it

How the STLC fits inside a 2-week sprint

Here is what the STLC looks like for a tester on a food delivery team, sprint goal: “Customers can apply coupons at checkout.”

The STLC inside one 2-week sprint

Phases overlap. Each story goes through its own mini cycle while the sprint moves on.

MTWTFMTWTF

Requirement analysis

Read the sprint stories, ask questions in planning and refinement.

Test planning

A light plan: which stories are risky, which devices, what regression to run.

Test case design

Write cases for each story while developers build it.

Environment setup

Install each new build on the test environment, smoke test it.

Test execution

Test stories as soon as each one is ready; retest fixes; regression at the end.

Test closure

Share results in the sprint review, raise process issues in the retro.

• Day 1 (planning): you read the three coupon stories, ask about expired codes and minimum order values, and note that you’ll need test accounts with order history. That is requirement analysis and test planning, done in an hour or two.
• Days 2-6: while developers build, you write test cases for each story and prepare coupon codes in the test environment. When the first story lands on day 4, you install the build, smoke test it and start testing.
• Days 4-9: you test each story as it arrives, log bugs, retest fixes the same day, and talk to developers constantly.
• Days 8-9: you run the regression set on the release candidate: login, cart, payment, order tracking.
• Day 10: you share a short summary in the sprint review (“all three stories pass; one low-severity layout bug left open”) and mention in the retro that stories arrived late.

The phases overlap, and each story runs through its own mini cycle. But all six are still there.