The SDLC & Where Testing Fits
Software doesn't appear by magic. It moves through a series of phases — from idea to production — and testing has a role in every single one. Understanding this cycle is the foundation of everything else you will learn.
1 The Hook
It's your first week at a Wellington software company. The developer sitting next to you says: "We're in sprint 3, UAT starts Thursday, and the BA signed off on the AC yesterday." You smile and nod. You have no idea what any of that means.
Three days later the test lead asks you to "review the requirements in the SDLC phase before build starts." Again — you smile and nod.
This happens to almost every new tester. The industry runs on shared vocabulary — SDLC, STLC, sprint, UAT, shift-left — and nobody explains it because everyone assumes you already know. This page fixes that.
Understanding the Software Development Lifecycle (SDLC) is not optional background knowledge. It is the map. Without it, you don't know where you are, what phase you're in, what your job is right now, or what comes next. With it, you can orient yourself in any team, in any methodology, on your first day.
2 The Rule
Testing does not start when the build is finished. Testing starts when the idea is first written down — and doesn't end until the software is retired.
This is the most important shift in thinking for a new tester. The SDLC is the whole journey from "we need a feature" to "that feature is running in production." The STLC — the Software Testing Lifecycle — is the testing thread that runs through it. They are not sequential. They overlap.
3 The Analogy
Building software is like building a house. The SDLC is the construction process. Testing is the building inspector.
A building inspector doesn't just turn up at the end to check the finished house. They check the foundations before the frame goes up. They check the frame before the walls go in. They check the wiring before it's hidden behind plasterboard. Finding a problem with the foundations after the roof is on costs ten times more to fix than finding it before the frame was built. Software works the same way. The earlier a defect is found, the cheaper and faster it is to fix. That's why testers are involved from the very beginning — not because we slow things down, but because we make the whole build cheaper.
4 The SDLC — The Six Phases
The Software Development Lifecycle describes the phases a piece of software moves through from concept to live system. Different organisations name these phases slightly differently, but the core sequence is consistent.
1. Requirements & Planning
The business defines what they want. Product managers, business analysts, and stakeholders write requirements, user stories, or specifications. Scope, timeline, and budget are agreed.
2. Design
Architects and developers design how the system will be built — database structure, API contracts, UI wireframes, integration points. The "blueprint" for what developers will actually code.
3. Development (Build)
Developers write the code. Features are built according to the design and requirements. Unit tests are (ideally) written alongside the code.
4. Testing
The completed build is handed to testers for verification. Functional testing, regression testing, integration testing, performance testing, and user acceptance testing (UAT) all happen here.
5. Deployment
The tested software is released to production — the live environment that real users interact with. This may be a full release, a staged rollout, or a feature flag deployment.
6. Maintenance & Operations
The software is live and in use. Bug fixes, minor enhancements, and security patches keep it running. The cycle restarts for the next feature or release.
5 Waterfall vs Agile
The SDLC phases stay the same. What changes between methodologies is how they're ordered, how long they take, and how much you can go back.
| Aspect | Waterfall | Agile (Scrum) |
|---|---|---|
| Structure | Linear. Each phase must be complete before the next begins. | Iterative. Short cycles (sprints) each deliver a working increment. |
| Requirements | Defined fully upfront. Changing them later is expensive. | Evolve throughout. New requirements can enter at the start of any sprint. |
| When testing happens | After development is complete — a dedicated test phase. | Within every sprint — alongside development, not after it. |
| Releases | One big release at the end of the project. | Potentially releasable increment every sprint (1–4 weeks). |
| Risk of late discovery | High — defects found late are expensive to fix. | Lower — short cycles surface problems early. |
| Where you'll see it in NZ | Government projects, large infrastructure builds, heavily regulated industries. | Most software product companies, startups, and modern enterprise teams. |
Many NZ organisations use a hybrid — Agile delivery with Waterfall-style planning and governance around it. Don't be surprised if the team says "we're Agile" but still produces a detailed project plan and has a dedicated UAT phase.
6 The STLC — Testing Has Its Own Lifecycle
Just as the SDLC describes how software is built, the Software Testing Lifecycle (STLC) describes how testing is planned, executed, and closed. It runs inside the SDLC — a cycle within a cycle.
Requirements Analysis
Review requirements to understand what needs to be tested. Identify testable and untestable requirements. Flag ambiguities early.
Test Planning
Define scope, approach, resources, timeline, and exit criteria. What will be tested? What won't? What tools? Who tests what?
Test Case Design
Write test cases, test scripts, or exploratory charters. Define test data. Prepare the test environment.
Test Environment Setup
Configure the environment where testing will run — test servers, databases, test accounts, mock services, and seed data.
Test Execution
Run the tests. Record results — pass, fail, or blocked. Log defects for anything that doesn't behave as expected.
Test Closure
Confirm exit criteria are met. Write a test summary report. Archive test artefacts. Run a retrospective on what worked and what didn't.
In an Agile team, you'll run through most of these phases every sprint — just faster and more informally than in a Waterfall project.
7 Shift-Left: Why Testers Get Involved Early
"Shift-left" means moving testing activities earlier in the SDLC — to the left on a timeline. Instead of testing being the last thing that happens before release, it starts at requirements and runs continuously.
The Rule of Ten
A defect found during requirements review costs roughly $1 to fix. The same defect found during development costs ~$10. Found during testing: ~$100. Found by a customer in production: ~$1,000. The numbers vary by system, but the ratio is consistent — early detection is dramatically cheaper. This is the entire economic case for shift-left testing.
Practically, shift-left means:
- Testers attend requirements and design reviews, not just test execution
- Acceptance criteria are reviewed and questioned before development starts
- Test cases are written while the feature is being built, not after
- Developers write unit tests as part of their definition of done
- Automated tests run on every code commit, not just before release
As a grad, you may not be driving this — but understanding why it matters means you'll ask the right questions and add value before anyone tells you to.
8 Common Mistakes
🚫 Waiting to be told when to start testing
Why it happens: New testers assume testing means executing test cases against a finished build.
The fix: Start engaging with requirements and user stories the moment they're written. Ask questions. Flag ambiguity. You're adding value before a single line of code exists.
🚫 Treating every project as if it runs the same methodology
Why it happens: You learned Agile in a course and assume that's what everyone does.
The fix: Ask your team lead on day one: "What methodology do we follow, and where does testing fit in our process?" Every team is different. Adapt.
🚫 Confusing UAT with "the testing phase"
Why it happens: UAT (User Acceptance Testing) is the most visible testing activity — the business signs off here — so it looks like the whole job.
The fix: UAT is one type of testing, and it happens near the end of the SDLC. By the time UAT starts, you should have already done functional testing, regression testing, and integration testing. UAT is not where testers do their work — it's where the business confirms the work is done.
🚫 Not knowing what phase you're in
Why it happens: Nobody tells you explicitly, and in fast-moving Agile teams the phases blur.
The fix: At any point you should be able to answer: what sprint are we in, what stories are in scope, what's the definition of done, and what's our exit criteria for testing this sprint? If you can't, ask.
9 Self-Check
Click each question to reveal the answer.
What does SDLC stand for, and what does it describe?
Software Development Lifecycle. It describes the phases a piece of software moves through from initial concept through to live production system and ongoing maintenance.
What is the key difference between Waterfall and Agile?
Waterfall is linear — each phase is completed before the next begins, with one big release at the end. Agile is iterative — short sprints each deliver a working increment, with testing happening within every sprint rather than after development is complete.
What does "shift-left" mean, and why does it matter?
Shift-left means involving testers earlier in the SDLC — at requirements and design, not just at the testing phase. It matters because defects found early are dramatically cheaper to fix than defects found late. The Rule of Ten: a defect costs roughly 10× more to fix at each successive phase.
What is the STLC?
The Software Testing Lifecycle — the testing-specific cycle that runs within the SDLC. It covers: requirements analysis, test planning, test case design, environment setup, test execution, and test closure. In Agile teams, a compressed version of this runs every sprint.
What is UAT and when does it happen?
User Acceptance Testing — testing performed by the business (not QA) to confirm the software meets their requirements before it goes live. It happens near the end of the SDLC, after functional and regression testing are complete. It is not the tester's primary phase — by UAT, QA has already done most of their work.
A developer says "we're in sprint 3." What does that tell you about where testing should be?
In sprint 3, you're in an active Agile iteration. Testing is happening now — within the sprint, not after it. You should be reviewing acceptance criteria, writing test cases for in-progress stories, testing completed stories, and preparing regression coverage for anything done in sprints 1 and 2. Testing is not a future phase — it's happening right now alongside development.