A program doesn't appear all at once. It goes through a path: someone came up with the idea, someone described what's needed, developers wrote the code, testers checked it, the product was shipped and is maintained afterward. This path is called the development lifecycle — in English, SDLC (Software Development Life Cycle).
Testing isn't a separate island at the end but part of this path, and it has its own inner cycle — STLC (Software Testing Life Cycle). You need to understand both to see at what moment, and how, you plug in.
The development stages (SDLC)
The classic stages that any product goes through one way or another:
- Requirements. They decide what and why we're building. The analyst and the customer describe how it all should work.
- Design. They figure out how to arrange it technically: screens, data structure, architecture.
- Development. The programmers write the code.
- Testing. They check that what came out is what was intended, and look for bugs.
- Release (deployment). The product is rolled out to users.
- Maintenance. They fix what's found in the field, add new things.
On paper the stages go in order; in practice they interweave and repeat. But the set of work is always roughly this.
Waterfall and Agile — two ways to go through these stages
There are two approaches to how you move through the stages.
Waterfall — strictly in order: first all the requirements, then all the design, then all the development, then all the testing. Like a waterfall, down and without going back. The problem: testing sits at the very end, and if a mistake was baked into the requirements, it's found very late and very expensively.
Agile — in small pieces. The product is made in short cycles (sprints) of one to two weeks: each cycle takes a small feature and runs it through all the stages — from requirements to testing — at once. Testing goes together with development, not after it. This is how most teams work today; more on it in the article QA in Agile and Scrum.
For a tester the difference is fundamental: in Agile you plug in constantly and early, rather than waiting until "everything's written".
The testing lifecycle (STLC)
Inside the big cycle, testing has its own, smaller one. When a new feature comes in, the tester goes through roughly these steps:
- Analyzing requirements. Understand what needs to be checked at all, and ask questions if something is unclear.
- Planning. Estimate what to test and how, and how much time is needed — this is the future test plan.
- Test design. Write test cases and checklists, prepare test data.
- Execution. Run the checks, file bugs on what's found.
- Closure. Re-check what's fixed, sum up: what's checked, what's left, whether it can be shipped.
These steps don't have to be long and formal — on a small task they'll take half an hour. But the train of thought is always the same: understand → plan → design checks → check → sum up.
Why a tester is needed from the very start
The temptation is to bring in the tester at the end: "we'll build it, then you check". That's expensive. The nastiest bugs are baked in at the requirements stage: if it wasn't agreed what should happen on a repeat payment, both the code and the tests will be wrong, and it'll be understood in the field.
When a tester reads the requirements in advance, they ask awkward questions: "what if the user clicks twice?", "what about cancellation after payment?". These questions cost ten minutes at the requirements stage and save weeks at the maintenance stage. That's exactly why, in modern teams, the tester takes part in discussing the task from the very beginning, rather than receiving a finished product.
Where this applies
Knowing the lifecycle helps you understand when to do your work and why things go the way they do. When the team plans a sprint — you estimate what you'll manage to test. When a new feature is discussed — you're already asking questions. When a release is being prepared — you say whether it can ship. All of these are your points in the overall cycle.
Where beginners stumble:
- They consider testing the "last stage" and wait for a finished product. That's not how Agile works — you plug in early and constantly.
- They skip analyzing requirements and jump straight to checking. Then it turns out they were checking the wrong thing.
- They don't sum up. "I sort of clicked around everything" isn't a result. You need to clearly say what's checked, what isn't, and what risks there are.
What to learn next. Now that the whole picture is clear, move to the heart of manual work: test levels (what's checked and at what scale) and types of testing.