Testing in the Context of an SDLC
Testing never happens in a vacuum - it's shaped by however the software around it gets built. This topic covers how testing adapts to different development models, and the modern practices (Shift-Left, DevOps, test-first development) that connect the two.
~8 min read
The core ideas, explained
Impact of the SDLC on Testing
The lifecycle model a project follows directly dictates when and how testing happens. Sequential models (Waterfall, V-Model) flow in a straight line from requirements to deployment, so test execution happens late and documentation is formal and exhaustive. Iterative and incremental models (Agile, Scrum) build software in small pieces and refine it repeatedly, so testing is continuous, documentation is lighter, and automation plus experience-based techniques like exploratory testing carry more weight.
A pacemaker's software follows the rigid, exhaustively documented phases of a V-Model release, while an e-commerce team ships a new shopping cart feature in a two-week Agile sprint with daily automated regression runs - the same testing discipline, applied through very different SDLC lenses.
Good Testing Practices That Apply Regardless of SDLC
Whatever lifecycle a project follows, a few practices hold up everywhere: every development activity should have a corresponding test activity (if architects design, testers review the design; if developers code, testers test the code); each test level - component, integration, system, acceptance - needs its own distinct objectives so effort doesn't overlap; test analysis and design should start as soon as requirements exist, not once code is ready; and testers should review early drafts of requirements or user stories, catching defects before a single line of code is written.
A tester reviews a draft user story and points out it has no rule for handling negative numbers, stopping a developer from coding the wrong logic before it ever reaches a sprint.
Testing as a Driver for Development
In modern SDLCs, tests are often written before the code, and used to drive how the code gets built. Test-Driven Development (TDD): a developer writes an automated unit test, watches it fail, writes the minimum code to pass it, then refactors. Acceptance Test-Driven Development (ATDD): the whole team - business, dev, and test - collaboratively writes acceptance tests before development, and code is written to satisfy them. Behavior-Driven Development (BDD): tests are expressed in plain, natural language anyone can read, typically as Given/When/Then.
Given a user is on the login page, When they enter valid credentials, Then they are redirected to the dashboard - a BDD scenario the whole team, not just developers, can read and agree on before any code exists.
DevOps and Testing
DevOps merges development and operations to enable fast, reliable delivery, and testing is the safety net that makes that speed survivable. Continuous Integration/Continuous Delivery (CI/CD) pipelines automatically build, deploy, and test every change. Automated tests give fast feedback the moment code is committed. Infrastructure as Code (IaC) keeps test environments consistent with production. And Shift-Right extends testing into the live environment itself, through monitoring, observability, and techniques like A/B testing.
A developer commits a change; within minutes a CI/CD pipeline has built it, deployed it to a staging environment, and run the full regression suite - telling them, before lunch, whether anything broke.
The Shift-Left Approach
Shift-Left means moving test activities as early as possible in the project timeline - to the "left" on a schedule - because prevention is cheaper than detection: a bug caught in a requirements review costs far less than the same bug caught in production. Typical Shift-Left activities include early specification reviews, static analysis of code as it's written, and designing test cases during the design phase, well before the system is built.
Running an automated security scanner directly inside a developer's IDE as they write code, instead of waiting for a penetration test right before launch.
Retrospectives and Process Improvement
Testing processes aren't fixed - they should evolve as a team learns. Retrospective meetings, typically held at the end of a sprint or project, are where a team discusses what went well, what went wrong, and what to change. The findings feed back into testware itself: updating test cases, automated scripts, and test data ahead of the next cycle, not just fixing the one defect that triggered the conversation.
During a retrospective, a team realizes a critical bug reached production because they had no test coverage for mobile browsers, so they create a task to add mobile emulation to their CI/CD pipeline going forward.
Key points to remember
- The SDLC model shapes the testing approach: sequential models mean formal, late-cycle testing; iterative/Agile models mean lightweight, continuous testing.
- Some testing practices are universal regardless of lifecycle - every development activity should have a matching test activity, and testers should get involved early.
- TDD, ATDD, and BDD are all "test-first" approaches, but with different focus: TDD is developer/unit-centric, ATDD is acceptance-criteria-centric, and BDD is behavior-centric (Given/When/Then).
- DevOps depends on automation - fast feedback loops and stable, automated CI/CD pipelines are what make rapid delivery safe.
- Shift-Left saves money: catching defects through early reviews and static testing is far cheaper than catching the same defects in production.
- Retrospectives should drive real process change - updating testware and practices based on lessons learned, not just closing out one defect.
Terminology
A few terms from this topic worth knowing precisely.
The overall model a project follows to build software - e.g. sequential (Waterfall) or iterative (Agile) - which directly shapes when and how testing happens.
A developer writes an automated unit test, watches it fail, writes the minimum code to pass it, then refactors - tests are written before the code they check.
The whole team - business, dev, and test - collaboratively writes acceptance tests before development starts, and code is written to satisfy them.
Expressing expected behavior in a natural-language format anyone can read, typically structured as Given/When/Then.
A culture that merges development and operations to enable fast, reliable delivery - testing (via CI/CD automation) is the safety net that makes that speed sustainable.
Pipelines that automatically build, deploy, and test every code change, giving fast feedback the moment it's committed.
Extending quality activities into the live production environment itself, through monitoring, observability, and techniques like A/B testing.
The practice of moving testing activities as early as possible in the SDLC, so defects are caught and prevented before they're built further into the system.
Every artifact produced or used during testing - test plans, test cases, scripts, test data, environments, logs, and reports.
Summary
Testing isn't an isolated phase - it has to integrate with whichever SDLC a project follows. Agile calls for continuous, automated testing; Waterfall calls for formal, phased testing - but practices like early tester involvement apply everywhere. Modern approaches push testing earlier (Shift-Left), use tests to drive development (TDD/ATDD/BDD), automate delivery pipelines (DevOps), and keep improving through retrospectives.
| Concept | One-line memory hook |
|---|---|
| SDLC impact | The dev model dictates test timing and formality |
| Universal practices | Every dev activity gets a test activity; start early |
| Test-first (TDD/ATDD/BDD) | Write the test before you write the code |
| DevOps | CI/CD pipelines, fast feedback, continuous delivery |
| Shift-Left | Test early to prevent bugs, not just find them late |
| Retrospectives | Learn from the past to improve future test processes |
Check your understanding
10 quick questions - click an option to see if you got it right.