An online store decides to let customers pay with loyalty points: part of the order comes off the points balance, the rest goes on the card. Between "we decided" and "shoppers are using it" there is a road: the task was discussed, drawn, written, checked, shipped — and then patched for another month as complaints came in. That road is the software development lifecycle, or SDLC.
Inside it, testing has a shorter road of its own — the software testing lifecycle, or STLC. It does not start when there is finally a button to click; it starts much earlier, and it is travelled end to end for every single task. What follows walks both circles on that same loyalty-points feature.
The big circle is the product's path, the small one is the path of a single round of testing. The small circle turns many times inside the big one, and it starts at the requirements stage, not at the testing stage.
How a task travels from idea to maintenance
Requirements. The analyst turns "let people spend their points" into a task with acceptance criteria: where the balance comes from, what share of an order it may cover, what the shopper sees. You ask the awkward questions: what if the balance exceeds the order, do points come back when an order is cancelled, what happens on a double tap of "Pay".
Design. The designer draws the payment screen, the developers settle where the balance lives and what happens when two deductions arrive at once. You look at the mockup through the eyes of someone whose day is going badly: an empty balance, not enough points, the network dropping mid-deduction.
Development. Programmers write the code and produce a build — an installed version of the product with a number on it, which you can open and click through. Meanwhile you write the checks, prepare test data (no points, three hundred, a huge balance) and secure access to the environment.
Testing. Running the checks, filing bugs, re-checking fixes — and a clear answer to "can this ship or not".
Release. The build goes onto the real servers, and after the rollout you walk the main scenario on the real store: points payment works, card payment is not broken. If things go badly, the release is rolled back. Then comes maintenance — complaints and small improvements, a distinct kind of work covered below.
The stage names differ from team to team; the set of work barely does. How you travel them does: strictly in order and once, or in short two-week circles — that is what a development model is, and for you it changes one thing, the moment you join (development models, the circle inside a sprint).
The small circle inside the big one: STLC
Clicking around is nowhere near the first step of this job, and the order is easiest to remember through two questions: what has to exist for a step to start, and what it leaves you holding.
Analysing the requirements. Entry: a task description and a live analyst. You write down what is unstated: do spent points come back on a partial refund; if points expire on a date, what happens to them on an order placed but not paid. You leave with questions and answers in writing, in the task comments, not "we agreed on it in the corridor" (more on this).
Planning. Entry: the answers from the previous step. You decide what you check, what you leave alone and when you stop: "we check points payment and card payment; delivery is out of scope; we finish when every check has been run and no defect blocks payment". You leave with an agreement that grows into a test plan on a large task.
Designing the checks. Entry: knowing what is supposed to happen and how much you are covering. You leave with test cases or a checklist and test data: shoppers with a zero balance, with less than the order total, and with more.
Three steps are done and there is still nothing to click — no build exists, and that is the point: by the time one lands, you are ready. A case missed at the requirements stage spreads just as quietly: nobody discussed the double tap on "Pay", so the analyst wrote the requirement without it, the designer never drew the disabled button, the developer deducted the points twice, and you checked against that same requirement. When "you charged me twice" arrives from shoppers, all of it has to be redone at once (the cost of a bug).
Environment, access and accepting the build
A test environment (teams also call it staging) is a separate copy of the product: its own servers, database and data. You cannot test on the real store: you would be placing orders in the name of living people and spending real points. Teams often keep several: one for developers, one for testing, one close to production.
Three things are best secured in advance rather than on the day of the run: the address of the environment and access to it; accounts and admin rights, if you cannot see point transactions without them; and the number of the build deployed right now — half of all "it doesn't reproduce for me" conversations end with you and the developer looking at different builds.
A full run is premature: start with a short check that the build is usable at all — the store opens, you can log in, an item goes into the basket, the payment screen appears. That pass is called a smoke check and takes ten to fifteen minutes. If it falls apart, the build goes back with a description of the breakage: half a day of testing on a build where login is broken has to be repeated in full anyway.
Execution is a loop, not a straight line
You find that tapping "Pay" twice deducts the points twice, and you raise a defect. The developer fixes it and moves it to "fixed". You re-check that exact case on the new build: gone — you close it; still there or half gone — you send it back with a note on what remains. A second loop turns around the first: a fix may disturb something next to it, so checks of what used to work run alongside (defect statuses). Because of that loop "I'll check it in a day" is almost always wrong: a day is one pass, and passes equal the builds that arrive.
How the circle ends and how often it repeats
Finishing the work means saying three things out loud: what was checked, what was not and why, and what risk is left. "Points payment is checked for all three shopper types; partial refunds are not checked, refunds are not configured on the environment; the risk is moderate." Say nothing, and the team assumes everything was checked — and every risk in that silence becomes yours.
The big circle moves over months, while the small one you travel on every task: within a two-week sprint it completes several times. On a large task analysing requirements is an hour-long meeting; on "change the wording of an error message" the whole circle takes half an hour. The steps do not disappear, they shrink.
After the release: complaints and urgent fixes
A complaint arrives with no steps to reproduce: "points payment doesn't work, give me my money back" — no browser version, no time, no order number. Your job is to turn it into a defect: get details out of support, find the order, look at what was happening at that moment, and build steps that make the failure repeat. Quite often payment was never the problem: the points had expired the day before.
"Cannot reproduce" is no reason to close a complaint; more often it means you are trying it with different data. What helps is signing in as the same type of shopper, recreating the conditions (the same browser, country, delivery option) and looking at what the system recorded at the time of the complaint.
When points are deducted but no order is created, the fix does not wait in the queue for the next release — it ships separately and urgently, as a hotfix. The haste is exactly the danger: it was written fast and checked under time pressure, so afterwards you check that nothing around it broke.
In short
- SDLC is the product's road: requirements, design, development, testing, release, maintenance. STLC is the road of one round of testing inside it, travelled on every task and starting at the requirements — its first three steps happen while there is no code.
- Every step has an entry and a result: no description, access or build and the step cannot start; no questions, checks or verdict and it is not finished.
- The environment, access and test data are prepared in advance, and a new build is first put through a smoke check.
- Execution is a loop of "found → fixed → re-checked", with checks of what used to work running alongside.
- A case missed at the requirements stage spreads into the mockup, the code, the checks and the support queue — and all of it has to be redone at once.
What to read next
- Development models: waterfall, the V-model, iterations — the order teams travel the stages in.
- QA in Agile and Scrum — what the small circle looks like inside a two-week sprint.
- Test plans and test suites — what the planning step produces.
- Testing against requirements — the requirements-analysis step in detail.