Software and Testing Lifecycles
Software is never conjured into existence in a single burst. It travels through a series of defined stages — from a vague idea in someone’s head to a working product in a customer’s hands — and testing has its own matching journey that runs alongside. Understand both lifecycles and you can answer the question every interviewer eventually asks: “Where exactly does testing fit in the process, and why does it matter when?” This module gives you that map.
Learning objectives
By the end of this lesson you will be able to:
- Describe each phase of the Software Development Life Cycle (SDLC) and what happens in it.
- Compare Waterfall, V-model, Iterative/Incremental and Agile — their strengths, weaknesses, and when each suits.
- Walk through the six phases of the Software Testing Life Cycle (STLC) in order.
- Write concrete entry and exit criteria for a testing phase and explain why they matter.
- Show how STLC maps onto SDLC and explain “shift-left” in terms of real money saved.
The Software Development Life Cycle (SDLC)
The SDLC is the overall roadmap a team follows to turn an idea into working, maintained software. Different teams rearrange or overlap the stages, but almost every project passes through the same six fundamental activities. Think of it like building a restaurant: you decide what food you will serve, you draw up the kitchen and dining room, you build it, you check everything works, you open the doors, and then you keep it running day after day.
- 1. Requirements gathering & analysis
- The team works out what the product must do and why. Analysts talk to stakeholders and users, and the result is usually a requirements document. Testers who join here can already spot vague or contradictory requirements — the cheapest bug fix of all.
- 2. Design
- The team decides how to build it: the architecture, the database structure, the screens, the way components talk to each other. This is the blueprint stage.
- 3. Development (coding)
- Developers write the actual software according to the design. This is usually the longest-visible phase and where the code — and its defects — are born.
- 4. Testing
- The software is exercised to verify it meets the requirements and to find defects before users do. In older models this is a distinct block; in modern ones it runs throughout.
- 5. Deployment
- The finished, tested software is released to real users — pushed to production servers, published to an app store, or shipped to a customer.
- 6. Maintenance
- After release, the team fixes newly discovered issues, adapts to changing needs, and adds improvements. Most software spends the majority of its life here.
An analogy that will stick
Building software is like building a house. Requirements is the conversation with the family about how many bedrooms they need. Design is the architect’s drawings. Development is the construction crew laying bricks. Testing is the inspector walking the finished rooms. Deployment is handing over the keys. Maintenance is the years of repairs, repaints and extensions that follow. Notice that an inspector who only shows up on handover day — after the walls are sealed — can only find problems that are now expensive to fix. The whole argument for modern lifecycles is: let the inspector in earlier.
Common SDLC models
A “model” is simply the shape in which you arrange those six activities — in a straight line, in a loop, or in tiny repeating slices. The model you choose dramatically changes when and how testing happens.
Waterfall
The oldest and simplest model. Each phase is completed fully before the next begins, flowing downward like water over steps: requirements, then design, then development, then testing, then deployment. It is easy to understand and manage, and works well when requirements are crystal clear and unlikely to change — for example, a project with strict regulatory specifications fixed up front. The fatal weakness for testers is that testing sits near the very end, so defects born in the requirements phase may not surface until months later, when they are at their most expensive to fix. There is also little room to accommodate change once you have “flowed” past a phase.
V-model (Verification and Validation model)
An evolution of Waterfall that bends the straight line into a V. As you go down the left side through the development phases, you simultaneously plan the matching test phase on the right side. So while requirements are written, acceptance tests are designed; while the high-level design is drawn, system tests are planned; and so on. Each development stage has a corresponding test stage facing it across the V. The big win is shift-left: test planning starts at the very beginning even though test execution still happens later. Its weakness is the same rigidity as Waterfall — it struggles when requirements change mid-project.
Iterative / Incremental
Instead of building the whole product in one pass, the team builds it in chunks. In an incremental approach each chunk adds a new slice of functionality; in an iterative approach each pass refines and improves what already exists. A working (if partial) product appears early and grows. This gives earlier feedback and reduces the risk of building the wrong thing, but it needs good planning to decide how to slice the work, and the architecture must be able to absorb repeated additions.
Agile / Scrum
The dominant approach in modern industry. Work is broken into short cycles called sprints (often two weeks), each producing a small, potentially shippable increment. Requirements are expected to evolve, and the customer gives continuous feedback. Testing is not a separate phase at the end — it is woven into every sprint, with testers and developers collaborating daily. Agile excels when requirements are uncertain or likely to change, and it delivers value fast. Its trade-offs are a need for disciplined communication, and less up-front documentation, which can be uncomfortable for fixed-scope or heavily regulated projects.
| Model | How it works | Pros | Cons | Best when… |
|---|---|---|---|---|
| Waterfall | Linear; each phase finishes before the next starts. | Simple, well-documented, easy to manage. | Testing is late; very poor at handling change. | Requirements are fixed and well understood. |
| V-model | Linear, but each dev phase is paired with a planned test phase. | Test planning starts early (shift-left); clear structure. | Still rigid; change is costly. | Requirements are stable and quality/traceability is critical (e.g. medical, defence). |
| Iterative / Incremental | Product built in repeated chunks that grow or refine it. | Early working software; earlier feedback; lower risk. | Needs careful slicing and a flexible architecture. | A large product can be delivered in meaningful pieces. |
| Agile / Scrum | Short sprints; continuous feedback; testing throughout. | Embraces change; fast value; testing is continuous. | Needs strong communication; lighter documentation. | Requirements are uncertain or evolving (most modern apps). |
The Software Testing Life Cycle (STLC)
Just as development has its lifecycle, testing has its own structured sequence that runs inside the SDLC. The STLC ensures testing is planned and systematic rather than a last-minute scramble. It has six phases.
- 1. Requirement analysis
- Testers study the requirements to understand what needs to be tested and to identify what is testable. This is where you catch ambiguous or untestable requirements — for example, “the page should load quickly” is not testable until “quickly” becomes “within 2 seconds.”
- 2. Test planning
- The test lead defines the scope, approach, resources, schedule and risks, and captures it in a test plan. This answers: what will we test, what will we not test, who does it, with what tools, and by when?
- 3. Test case design (and development)
- Testers write detailed test cases — step-by-step scenarios with inputs and expected results — and prepare the test data they will need. Cases are reviewed so defects in the tests themselves are caught early.
- 4. Test environment setup
- The hardware, software, network and data needed to run the tests are prepared — a controlled space that mimics production. This phase can often run in parallel with test case design.
- 5. Test execution
- Testers run the cases against the build, compare actual results to expected results, mark each case pass or fail, and log defects for the failures. Fixed defects are re-tested and surrounding areas are regression-tested.
- 6. Test cycle closure
- The team evaluates whether the testing met its goals, produces a summary report (what was tested, defect trends, coverage), and captures lessons learned so the next cycle is better.
Tutor tip: planning and execution are not the same instant
A point that confuses beginners: in good lifecycles, test planning and design start long before there is any software to run. You can write test cases from the requirements while developers are still coding. That is the practical heart of shift-left — by the time the build arrives, your tests are already waiting, sharpened, and ready to execute on day one.
Entry and exit criteria
Each STLC phase has entry criteria (conditions that must be true before you start) and exit criteria (conditions that must be true before you declare it finished). These turn fuzzy arguments like “are we done testing yet?” into objective, defensible decisions. Think of them as the gates between stations on a train line: you do not leave a station until the signal is green.
| STLC phase | Example entry criteria | Example exit criteria |
|---|---|---|
| Test planning | Requirements are reviewed and reasonably stable. | Test plan is written, reviewed and signed off. |
| Test case design | Test plan approved; requirements understood. | Test cases and test data written and peer-reviewed. |
| Environment setup | Hardware/software list and test data are ready. | Environment is up and a smoke test passes. |
| Test execution | Test cases written, environment ready, build deployed. | All planned cases run; critical/high defects fixed and re-tested; results reported. |
| Test cycle closure | Execution complete; defects triaged. | Summary report delivered; lessons learned recorded. |
Without clear exit criteria, “when is testing done?” becomes a matter of opinion — and opinion loses to deadline pressure. With them, the answer is a checklist, not an argument.
Entry/exit criteria in the real world
Imagine a team about to start test execution on a new payments screen. One tester pushes to start immediately, but the entry criteria are not met: the build is deployed, but the test environment is pointing at a stale database with no test accounts that have a saved card. If they charge ahead, half their cases will fail for reasons that have nothing to do with the product — wasted time and noisy, misleading results. Honouring the entry criteria (“valid test data present”) prevents a whole day of false failures. Criteria are not bureaucracy; they are how you avoid testing against a broken setup and blaming the code.
How STLC maps onto SDLC
The two lifecycles are not rivals — the STLC lives inside the SDLC. The cleanest way to see this is the V-model, where every SDLC development phase on the left faces a testing activity on the right:
| SDLC phase (left of the V) | Matching STLC activity (right of the V) |
|---|---|
| Requirements | Requirement analysis → design acceptance tests |
| High-level design | Plan and design system / integration tests |
| Detailed design / coding | Design component (unit-level) tests |
| Build complete | Environment setup & test execution |
| Deployment / maintenance | Test cycle closure & regression on changes |
In Agile the same activities happen, just compressed into every sprint rather than spread across one long timeline: within a two-week sprint you analyse the stories, design cases, set up data, execute, and close out — then do it all again next sprint. The phases do not disappear; they simply repeat quickly.
Shift-left: why earlier testing saves money
You met the cost-of-defect idea in Module 1; here is how the lifecycles put it into practice. Shift-left means deliberately moving testing activities toward the left (earlier) end of the timeline. Instead of waiting for a finished build, testers review requirements for ambiguity, help write acceptance criteria, and design test cases while code is still being written.
The payoff is directly financial. A defect caught when a requirement is being reviewed costs a quick edit to a sentence. The same defect, if it slips through design and coding and is only caught after release, requires an emergency hotfix, re-deployment, support tickets, possible data cleanup, and lost customer trust — often 100 times the cost or more. Models like the V-model and Agile are popular precisely because they bake shift-left into their structure, catching defects while they are still cheap. Waterfall’s late testing is exactly the expensive pattern shift-left was invented to escape.
Common mistakes to avoid
- Confusing SDLC with STLC. SDLC is how the software is built; STLC is how the testing is organised within it.
- Thinking a “model” changes the activities. Requirements, design, coding, testing still all happen — the model only changes their order and rhythm.
- Believing Agile means “no documentation” or “no planning.” Agile has less heavy up-front documentation, but planning and testing are continuous, not absent.
- Starting a phase before entry criteria are met. Testing against a broken environment produces false failures and wasted effort.
- Treating test execution as the start of testing. Planning and design are testing too — and they begin far earlier.
- Assuming Waterfall is always “bad.” It is a poor fit for changing requirements, but perfectly reasonable when the scope is genuinely fixed.
Hands-on exercise
Your team is adding a “Forgot password” feature to a web app. Work through both lifecycles for it:
- For each SDLC phase, write one sentence describing what would happen for this specific feature.
- Choose the SDLC model you would use and justify it in two or three sentences.
- Write one testable requirement for the feature (avoid vague words like “fast” or “easy”).
- List two items you would put in the test plan’s scope and one item you would explicitly put out of scope.
- Define one entry criterion and one exit criterion for the test execution phase of this feature.
- Explain, in two sentences, how shift-left could have caught a weak requirement for this feature before any code was written.
Knowledge check
- Name the six phases of the SDLC in order.
- Why is Waterfall considered riskier for testing than the V-model?
- List the six STLC phases in order.
- What is the difference between entry criteria and exit criteria? Give one example of each for test execution.
- In Agile, why is testing described as “continuous” rather than a single phase?
- In one sentence, explain how shift-left saves money.
Show answers
- Requirements gathering & analysis → Design → Development (coding) → Testing → Deployment → Maintenance.
- Because Waterfall puts all testing near the end, so defects created early (e.g. in requirements) surface only months later when they are far more expensive to fix; the V-model plans tests from the start.
- Requirement analysis → Test planning → Test case design → Environment setup → Test execution → Test cycle closure.
- Entry = conditions needed to start a phase (e.g. the build is deployed and the environment is ready). Exit = conditions needed to finish it (e.g. all planned cases run and critical defects fixed and re-tested).
- Because work is delivered in short sprints and testers test each increment within every sprint, collaborating with developers throughout rather than waiting for one big testing block at the end.
- By catching defects while they are still cheap to fix — a reworded requirement instead of a post-release hotfix with support and reputation costs.
Key takeaways
- SDLC is the roadmap for building software: requirements, design, development, testing, deployment, maintenance.
- Models arrange those phases differently — Waterfall (linear), V-model (paired test planning), Iterative/Incremental (chunks), Agile (sprints). Each has clear pros, cons and best-fit situations.
- STLC is testing’s own six-phase lifecycle that runs inside the SDLC: requirement analysis, planning, case design, environment setup, execution, closure.
- Entry and exit criteria make phase transitions objective — they end the “are we done?” argument.
- STLC maps cleanly onto SDLC (most visibly in the V-model); in Agile the same activities repeat every sprint.
- Shift-left — testing earlier — is the structural reason modern models save real money.
Go deeper
A few concepts that live just outside the core lifecycle picture but come up constantly on real teams and in interviews.
- The Spiral model. Beyond the four models above sits a risk-driven model: each loop of the spiral does a little planning, a little building, and — crucially — an explicit risk assessment and prototype before committing to the next loop. It suits large, expensive, high-uncertainty projects where the biggest danger is building the wrong thing at scale. Think of it as Iterative/Incremental with a formal “what could go badly wrong?” gate on every lap.
- Test plan vs test strategy. The module introduced the test plan (project-specific: scope, schedule, who tests what, by when). Its often-confused sibling is the test strategy — a higher-level, usually organisation-wide document describing how the company tests in general (standards, tools, levels, environments). One project has many test plans over time but typically inherits a single, stable strategy.
- Traceability (the RTM). How do you prove every requirement was actually tested? A Requirements Traceability Matrix links each requirement to the test cases that cover it. Run it forwards to find untested requirements; run it backwards to find “orphan” tests that check nothing anyone asked for. It is how exit criteria like “100% requirement coverage” stop being a guess.
- Shift-left has a twin: shift-right. Modern teams also test after release, in production — monitoring, feature flags, canary releases and A/B tests observe real user behaviour under real load. Shift-left catches defects early and cheaply; shift-right catches the ones that only appear with real traffic. Mature teams do both.
