SDLC: Where Testing Fits

The software development life cycle (SDLC) is the sequence of activities a team goes through to turn an idea into running software and keep it running. As a tester you work inside that cycle, so you need to know its phases, the different ways teams organise them, and where your work slots in. In interviews, “where does testing fit in the SDLC?” is a screening question; the strong answer is “everywhere, but differently in each phase”.

The SDLC phases

Most descriptions of the SDLC use some variation of these phases. Names differ between companies, but the activities are the same.

Phase	What happens	Main outputs
Planning	Decide whether to build, estimate cost, scope and risk	Project charter, high-level estimates
Requirements analysis	Capture what the system must do and how well	Requirements, user stories, acceptance criteria
Design	Decide how: architecture, data model, UI, integrations	Architecture and design documents, API contracts, wireframes
Implementation	Write the code	Source code, unit tests
Testing	Evaluate the integrated product	Test results, defect reports, release recommendation
Deployment	Release to users	Deployed build, release notes
Maintenance	Fix, improve and operate in production	Patches, monitoring data, new requirements

The table makes testing look like one phase. That is the first misconception to drop. The “Testing” row is where the bulk of dynamic testing of the integrated system happens, but testers contribute in every row.

Testing activities in every phase

Planning

Testers help estimate testing effort, identify risky areas, and flag what environments, data and tools will be needed. If the project needs a performance lab or test devices, this is when to say so.

Requirements analysis

This is where testers prevent the most defects. Review each requirement and ask:

• Is it testable? “The page should load fast” is not; “the search results page renders within 2 seconds at the 95th percentile under expected load” is.
• Is it unambiguous? Does “users” mean logged-in users, guests, or both?
• Is it complete? What happens on invalid input, timeouts, or an empty state?
• Does it conflict with another requirement?

Questions raised here cost minutes. The same gaps found after implementation cost days.

Design

Review designs and API contracts for testability: can you set up test data, observe results, and isolate components? Ask for test hooks such as stable element identifiers and health endpoints. Start designing tests from the design documents.

Implementation

Developers write unit tests. Testers and SDETs write automated API and UI checks in parallel, pair on tricky areas, and test early builds or feature branches.

Testing

Execute integration, system and acceptance tests, run regression suites, do exploratory testing, report defects and give a clear status of risk.

Deployment

Run smoke tests against the deployed environment, verify configuration, and confirm that monitoring is in place.

Maintenance

Analyse production incidents, add regression tests for every escaped defect, and keep the test suite healthy as the product changes.

SDLC models

The phases are the same everywhere; what differs is how they are sequenced. The model a team follows changes when and how you test.

Waterfall

Phases run once, in order, and each phase finishes before the next starts. Testing is a distinct phase after implementation.

• Strength for testers: stable requirements and clear documentation to test against.
• Weakness: defects in requirements are discovered late, when the whole system is built. Changes are expensive. Testing time is often squeezed when earlier phases overrun.

Waterfall still fits projects with fixed, well-understood requirements and heavy regulation, but pure Waterfall is rare in product companies today.

V-Model

The V-Model is a Waterfall variant that makes testing explicit. Each development phase on the left arm of the V has a matching test level on the right arm. Test planning and design for each level start as soon as the corresponding development artefact exists.

Development artefact (left side)	Test level that verifies it (right side)
Business requirements	Acceptance testing
System requirements	System testing
Architecture / high-level design	Integration testing
Detailed design / units	Component (unit) testing

The key idea: you design acceptance tests while writing requirements, not after the code exists. That forces requirements to be testable and finds gaps early.

Iterative and incremental

The product is built in small increments, each going through requirements, design, build and test. Each increment adds features and the team gets feedback early. Testing happens in every iteration, and regression testing becomes critical because each new increment can break what was already delivered.

Agile (Scrum, Kanban)

Agile approaches are iterative and incremental, with short cycles (Scrum sprints are commonly one to four weeks), cross-functional teams and continuous collaboration with the business. For testers this means:

• Testing is a continuous activity inside each sprint, not a phase at the end.
• Testers join refinement and planning to shape acceptance criteria.
• A story is usually not “done” until it is tested; this is written into the team’s Definition of Done.
• Automation is essential, because manual regression cannot keep up with frequent releases.
• Documentation is lighter: checklists, charters and acceptance criteria often replace long test plans.

A useful planning aid in Agile teams is the testing quadrants model (from Brian Marick, popularised by Lisa Crispin and Janet Gregory), which reminds teams to cover business-facing and technology-facing tests, both those that guide development and those that critique the product.

DevOps and continuous delivery

DevOps extends Agile into operations. Code is integrated continuously and can be deployed many times a day through automated pipelines. Testing becomes largely automated quality gates in a CI/CD pipeline:

A typical pipeline order (each stage must pass before the next runs)

1. Lint and type-check        static analysis, seconds
2. Unit tests                 fast, run on every commit
3. API tests                  service-level checks against a test environment
4. UI smoke tests             a small set of critical end-to-end journeys
5. Deploy to staging
6. Full regression / exploratory session
7. Deploy to production
8. Post-deploy smoke tests and monitoring

Testers in DevOps teams spend more time building and maintaining these checks, improving test reliability, and analysing production signals.

Shift-left and shift-right

Two phrases you will hear constantly:

• Shift-left means moving testing activities earlier in the cycle: reviewing requirements, testing APIs before the UI exists, running tests on every commit. The aim is to find defects when they are cheapest to fix.
• Shift-right means testing in and after production: monitoring, canary releases, feature flags, A/B tests, synthetic checks against live systems. The aim is to learn how the system behaves under real usage that no test environment fully reproduces.

They are complementary. A mature team does both.

Comparing the models

	Waterfall	V-Model	Agile	DevOps
When testing starts	After implementation	Test design starts with requirements	From sprint planning	From the first commit
Feedback speed	Slow	Slow for execution, early for design	Every sprint	Every commit / deploy
Documentation	Heavy	Heavy, with traceability	Light	Light, encoded in pipelines
Automation need	Optional	Moderate	High	Very high
Change cost	High	High	Low	Low

No model is “best”. Context decides, which is principle 6 from the previous lesson.

Practice exercise

You join a team building a mobile banking feature: “Users can schedule a transfer for a future date”. The team runs two-week Scrum sprints and deploys through a CI/CD pipeline.

Write a short plan (a bullet list is fine) answering:

1. What will you do during refinement, before the story enters the sprint?
2. What automated checks should run in the pipeline, and in what order?
3. What will you do after release (shift-right)?

A good answer has at least two concrete questions for refinement, a pipeline ordered from fastest to slowest, and at least one production-side check. The Test Plan Generator can help you structure a longer version.

Show a model answer

Refinement

• What is the maximum future date allowed? What happens with today’s date or a past date?
• What happens if the balance is insufficient on the execution date, not the scheduling date?
• Which time zone defines “the date”: the user’s device or the bank’s?
• Can a scheduled transfer be edited or cancelled, and until when?
• Agree acceptance criteria that cover these, written as testable examples.

Pipeline

1. Lint and type checks.
2. Unit tests for date validation and scheduling logic (boundaries: today, tomorrow, max date, max date + 1).
3. API tests: create, list, cancel scheduled transfer; reject invalid dates; authorisation checks.
4. A UI smoke test for the happy path on one device profile.
5. Full regression on staging before production.

After release

• Monitor failure rates of scheduled transfers on their execution date.
• Use a feature flag to roll out to a small percentage of users first.
• Add a synthetic check that schedules and cancels a transfer on a test account daily.

Key takeaways

• The SDLC phases are planning, requirements, design, implementation, testing, deployment and maintenance. Testers contribute in all of them.
• Requirements review is where testers prevent the most defects cheaply.
• The V-Model pairs each development artefact with the test level that verifies it; use it to explain test levels.
• In Agile and DevOps, testing is continuous and heavily automated, and regression risk rises with release frequency.
• Shift-left finds defects earlier; shift-right learns from production. Good teams use both.