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.
Senior engineer insight
The first time I sat in on a requirements review and caught a missing acceptance criterion, I realised that the conversation I'd just had was more valuable than two days of executing test cases would have been — the defect never made it into the build at all. What changed my thinking was understanding that my job in the requirements phase is not to approve requirements, it's to stress-test them: ask "what happens if...?" until someone in the room gets uncomfortable. That discomfort is where the real gaps live.
The most common mistake grad testers make is treating the SDLC as a handoff model — waiting for "their" phase to begin rather than recognising they're active contributors from the moment a user story is written.
From the field
On a large NZ government digital services project — Waterfall governance with Agile squads inside it — the team assumed UAT was the final quality gate and kept QA involvement light through the build phase. What they discovered during UAT was that three interconnected modules had each been built to different interpretations of the same requirements document: each passed its own functional tests, but the integrated flow didn't work at all. Six weeks of UAT blew out to fourteen. The lesson: in hybrid projects where governance is Waterfall but delivery is Agile, the seam between those worlds is where assumptions accumulate unchecked. Someone needs to own cross-squad integration testing from sprint one, not sprint twelve.
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.
Other models you'll hear named
Waterfall and Agile are the two you'll meet most, but interviewers and older codebases bring up a few more. You don't need to run these — you need to recognise the name and know where testing sits.
| Model | What it is | Where testing sits |
|---|---|---|
| V-Model | Waterfall folded into a V — each build phase on the left has a matching test phase on the right (requirements↔acceptance, design↔system, etc.). | Each test level is planned as its build phase is written, then run on the way back up. |
| Spiral | Risk-driven. The project loops through plan → design → build → evaluate, and each loop tackles the highest remaining risk first. Used on large, expensive, uncertain builds (defence, aerospace, big government platforms). | Risk assessment and a test/evaluate step end every loop — testers feed the risk picture that decides what the next loop builds. |
| Iterative / Incremental | Build the system in slices, each adding a working piece. Agile is one flavour of this. | Each increment is tested as it lands, plus regression on everything shipped so far. |
| DevOps | Develop, test, release, and operate as one continuous flow with automation and a tight feedback loop from production. | Continuous — testing runs in the pipeline (shift-left) and against production signals (shift-right). |
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.
Why teams fail here
- Treating the SDLC as strictly sequential in practice — testers idle during requirements and design, then scrambling when build drops with two days until release.
- Conflating "we do Agile" with "we don't need test planning" — sprints are short but the STLC still runs inside every one; skipping planning means no exit criteria and no definition of done for testing.
- Using UAT as a substitute for functional testing — business users find usability issues, not logic defects; by the time they're testing, the window to fix structural problems has closed.
- Not adapting when the stated methodology doesn't match reality — many NZ teams say "Agile" but run Waterfall with fortnightly meetings; orient to what the team actually does, not what the process deck says.
Key takeaway
The SDLC is not a waiting room — every phase has a testing activity, and a tester who only shows up at the test phase has already missed most of their leverage.
9 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about The SDLC & Where Testing Fits at the Grad level.
Q1. At which stage of the SDLC is it cheapest to fix a defect, and why?
Strong answer: Requirements and design — a defect found before any code is written costs only the time to correct a document. The cost multiplies at each subsequent stage: a bug found in unit testing costs hours; found in integration testing costs days; found in UAT costs a week plus reruns; found in production costs the fix, the patch release, and potentially the business impact of the failure. This is why shift-left testing — involving testers in requirements and design — provides the highest return on testing investment.
Q2. What is UAT and who is responsible for it?
Strong answer: User Acceptance Testing is the final testing phase where the customer or end users verify that the system meets their business requirements and is ready to go live. It is typically performed by business stakeholders, not the development team. The test team supports UAT by preparing test environments, providing test data, facilitating defect logging, and training UAT participants. UAT differs from system testing: system testing verifies technical requirements; UAT verifies business requirements in a realistic context.
Q3. What is the difference between verification and validation?
Strong answer: Verification asks "are we building the product right?" — checking that the product conforms to its specification. This includes code reviews, test execution against acceptance criteria, and static analysis. Validation asks "are we building the right product?" — checking that the product meets the user's actual needs. This includes user acceptance testing, usability testing, and production monitoring. A system can pass all verification checks but fail validation if the specification itself was wrong about what users needed.
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.