SDLC vs STLC
Building software (SDLC) and testing software (STLC) are two related but distinct life cycles that run alongside each other. SDLC covers the entire journey of a product from idea to maintenance. STLC is the testing-specific sub-process that happens, in some form, inside (or alongside) most of those SDLC phases. Understanding both — and how they overlap — explains why testing isn't just "something that happens at the end."
SDLC: Software Development Life Cycle
The six phases most SDLC models describe, using RecipeBox as the running example:
| Phase | What happens | RecipeBox example |
|---|---|---|
| 1. Requirements | Gather what the product needs to do | "Users must be able to add a recipe with a title, ingredients, steps, an optional photo, a category, and a prep time" |
| 2. Design | Plan the architecture, UI, and data model | Deciding the Add Recipe screen's layout and that a recipe has fields id, title, ingredients, steps, photoUri, category, prepMinutes |
| 3. Development | Write the actual code | Building the Add Recipe screen, the database layer, the save logic |
| 4. Testing | Verify the built product against requirements | Confirming the Add Recipe screen rejects an empty title, saves valid recipes, and shows them in the Recipe List |
| 5. Deployment | Release the product to real users | Publishing the RecipeBox update to the app store |
| 6. Maintenance | Fix bugs and add improvements post-release | Patching a crash reported by users who added a recipe with no photo |
STLC: Software Testing Life Cycle
STLC zooms into that one "Testing" box above and expands it into its own structured process:
| Phase | What happens | RecipeBox example |
|---|---|---|
| 1. Requirement analysis | Testers study requirements to understand what's testable, and raise questions about anything ambiguous | "What should happen if prepMinutes is left blank — is 0 assumed, or is it a required field?" gets asked and answered before writing test cases |
| 2. Test planning | Decide scope, approach, tools, timelines, and who tests what | Deciding that the Add Recipe screen will get both scripted test cases and a round of exploratory testing before release |
| 3. Test case development | Write the actual test cases (and test data) based on requirements | Writing test cases for valid recipe, empty title, negative prepMinutes, oversized ingredient list, etc. |
| 4. Test environment setup | Prepare the build, test devices, test accounts, and test data needed to run tests | Installing the latest RecipeBox build on a test device with a seeded test account and a few sample recipes already saved |
| 5. Test execution | Actually run the test cases and log results | Running each Add Recipe test case, marking pass/fail, logging any bugs found (e.g., blank title accepted) |
| 6. Test closure | Summarize results, evaluate exit criteria, document lessons learned | Confirming all critical bugs on the Add Recipe screen are fixed and verified before sign-off for release |
Side by Side
| SDLC phase | Roughly corresponds to STLC phase(s) |
|---|---|
| Requirements | Requirement analysis |
| Design | Test planning, early test case development |
| Development | Test case development, test environment setup (can run in parallel with coding) |
| Testing | Test execution |
| Deployment | Test closure (final sign-off before release) |
| Maintenance | A new, smaller STLC cycle often restarts for each fix or new feature |
Where Testing Fits: Waterfall vs Agile
| Model | Where testing happens |
|---|---|
| Waterfall | Testing is its own distinct phase, done only after development is "complete." All of RecipeBox would be built first, then handed to QA as one large batch. |
| Agile | Testing happens continuously, inside every sprint, alongside development. If "Add Recipe" is this sprint's feature, it gets test cases written, executed, and bugs fixed within that same sprint — not months later. |
Most real-world teams today — including the kind of team that would build RecipeBox — use some flavor of Agile, which is exactly why STLC activities like test planning and test case development need to start early and run continuously rather than waiting for a single "testing phase."