Software Development Life Cycle (SDLC) & Software Testing Life Cycle (STLC) Tutorial
Every software product you use — your banking app, food delivery app, or a hospital management system — was built following a structured process. That process is called the Software Development Life Cycle (SDLC). Without SDLC, software development would be chaotic — deadlines would be missed, budgets would explode, and the final product might not even do what the customer wanted.
SDLC (Software Development Life Cycle) is a structured, systematic process used by software development organizations to plan, design, develop, test, deploy, and maintain software. It breaks the entire process into well-defined phases, each with specific goals, activities, and deliverables, ensuring high-quality software is delivered on time and within budget.
Why SDLC is Necessary
Imagine a construction company building a 20-story skyscraper without blueprints, no phase planning, no inspections. The result would be a disaster. Software development is equally complex — SDLC is the blueprint for building software.
Building a house follows phases: design blueprint → lay foundation → construct walls → install wiring/plumbing → interior finishing → final inspection → handover. Similarly, SDLC has phases: Plan → Analyze → Design → Develop → Test → Deploy → Maintain. Skipping any phase causes problems down the line.
Key Benefits of SDLC
Real-World Example
When Flipkart decides to add a "Buy Now, Pay Later" feature: Planning — product managers estimate cost, timeline, team size. Requirement Analysis — business analysts gather requirements from finance, legal, and customer teams. Design — architects design the payment flow, database schema, API contracts. Development — developers write the actual code. Testing — QA team tests payment flows, edge cases, failure scenarios. Deployment — feature is released to 1% of users (canary release) before full rollout. Maintenance — monitoring, bug fixes, performance tuning post-release.
SDLC vs Ad-Hoc Development
| Aspect | Ad-Hoc Development | SDLC-Based Development |
|---|---|---|
| Planning | Little or none | Detailed project plan, schedule |
| Requirements | Informal, often verbal | Documented in SRS/BRD |
| Testing | Manual, after coding | Integrated in every phase |
| Timeline | Unpredictable, often delayed | Defined milestones and deadlines |
| Cost | Overruns frequent | Estimated and controlled |
| Quality | Inconsistent | Verified via quality gates |
In interviews, SDLC is always one of the first topics asked. Be ready to explain it with a real example — use the app development example of any popular app like Swiggy or Zomato to make your answer memorable.
SDLC is typically divided into 6–7 phases. While different organizations may name them slightly differently, the core activities remain the same. Let's walk through each phase in detail using the example of building a Hospital Management System (HMS).
Phase 1 — Planning
This is the most critical phase. Before a single line of code is written, the team must understand what is being built, why, how long it will take, and how much it will cost.
The hospital director says "We need a digital system to manage patient records, doctor schedules, and billing." The project manager conducts a feasibility study: cost estimated at ₹50 lakhs, 8-month timeline, 10-person team. A formal Project Plan is created with milestones.
Phase 2 — Requirement Analysis
This phase answers: "What exactly should the software do?" Business analysts gather detailed functional and non-functional requirements from stakeholders and document them in a Software Requirements Specification (SRS) document — often called the "Bible" of the development team.
Poor requirement gathering is the #1 reason software projects fail. If a requirement is ambiguous or missing in the SRS, the entire downstream work (design, development, testing) will be built on a faulty foundation — extremely expensive to fix later.
Phase 3 — System Design
The requirements are turned into a technical blueprint. This phase defines architecture, database schema, UI wireframes, API contracts, and technology stack. There are two sub-levels:
Phase 4 — Implementation (Coding)
Developers write actual code based on the design documents. This is where the product takes shape. Coding guidelines, version control (Git), code reviews, and unit tests happen here.
Backend developers build REST APIs for patient registration, appointment booking, and billing. Frontend developers create React screens for doctor dashboards. The DevOps team sets up CI/CD pipelines so code is automatically built and tested on every commit.
Phase 5 — Testing
The QA team systematically tests the software to find defects. This is where STLC begins (covered in Topic 7–8). Types of testing include functional, regression, integration, performance, UAT, and more.
Phase 6 — Deployment
Once the software passes all quality checks, it's released to the production environment where real users can access it. Deployment strategies include:
Phase 7 — Maintenance
After deployment, the software enters its longest phase. Bugs discovered in production are fixed (corrective maintenance), new features are added per business needs (perfective maintenance), and performance is optimized as user base grows (adaptive maintenance).
According to industry studies, approximately 60–80% of total software lifecycle costs are spent in the Maintenance phase. This is why writing clean, well-documented, maintainable code is critical — the software will likely be maintained for years or decades.
SDLC is a framework — not a methodology. The way you execute the SDLC phases is determined by the SDLC Model you choose. Different models suit different project types. Choosing the wrong model for a project is one of the biggest mistakes teams make.
An SDLC Model is a specific approach or methodology that defines how the SDLC phases are organized and executed — whether sequentially, iteratively, in parallel, or in a risk-driven way. Common models include Waterfall, Agile, V-Model, Spiral, Iterative, and DevOps.
Comparison of Major SDLC Models
| Model | Approach | Best For | Testing When? | Flexibility |
|---|---|---|---|---|
| Waterfall | Linear, sequential | Small, well-defined projects | After development | Low |
| V-Model | Sequential + parallel testing | Safety-critical systems | Parallel to dev | Low |
| Iterative | Cyclic, improving each cycle | Projects with evolving requirements | Each iteration | Medium |
| Spiral | Risk-driven, iterative | Large, high-risk projects | Each spiral | Medium |
| Agile | Iterative sprints, flexible | Dynamic, customer-facing products | Every sprint | High |
| DevOps | Continuous integration/delivery | Teams needing rapid, frequent releases | Continuous | Very High |
How to Choose the Right Model?
In most modern product companies (Amazon, Google, Flipkart), Agile with Scrum is the dominant model. However, large government projects, defense software, or banking core systems often still follow Waterfall or V-Model due to compliance, documentation, and contractual requirements.
The Waterfall Model is the oldest and most straightforward SDLC model. It was formally introduced by Winston W. Royce in 1970. Like a waterfall where water flows only downward, in this model each phase must be 100% complete before the next phase begins. There is no going back.
A linear, sequential SDLC model where each phase must be completed and formally reviewed before the next phase starts. Requirements are gathered upfront, and the model assumes they will NOT change during development. Also called the "Classic SDLC".
Waterfall Phases (Sequential Flow)
The key characteristic is that phases do not overlap. The Testing phase only begins after all development is complete.
Building a bridge follows Waterfall logic: design blueprints first → lay foundation → construct pillars → lay road surface → safety inspection → open to traffic. You cannot start laying the road before the pillars are done. There's no "let's change the design while construction is halfway done."
Advantages of Waterfall
Disadvantages of Waterfall
When to Use Waterfall
Government portal development: Requirements are legally defined and won't change mid-project. Documentation is a regulatory requirement.
Embedded systems / firmware: Hardware constraints are fixed. Requirements are determined by hardware specs upfront.
Construction or manufacturing software: Process is well-understood, requirements are stable, heavy documentation required.
Many teams try to use Waterfall for customer-facing web/mobile applications where requirements evolve weekly. This is a recipe for failure. Waterfall is NOT suitable for startups, e-commerce, or any product where user feedback drives feature changes.
Agile was born in 2001 when 17 software developers signed the Agile Manifesto — a revolutionary document that changed how the world builds software. They were frustrated with heavyweight, documentation-heavy processes that delivered software too late or not meeting real user needs. Agile prioritizes flexibility, collaboration, and delivering working software in short cycles called Sprints.
Agile is an iterative and incremental SDLC model where software is developed in short cycles (sprints, typically 1–4 weeks). Each sprint delivers a potentially shippable product increment. Requirements evolve through collaboration between cross-functional teams and stakeholders.
The Agile Manifesto — 4 Core Values
Agile is NOT a single methodology — it is a philosophy. Scrum, Kanban, XP (Extreme Programming), and SAFe are all implementations of Agile principles. Most companies use Scrum as their Agile implementation.
Scrum Framework (Most Popular Agile Implementation)
Scrum organizes work into time-boxed sprints with three key roles:
Scrum Events (Ceremonies)
Sprint 1 (2 weeks): Build user login, product listing page. QA tests these features within the same sprint. Deploy to staging.
Sprint 2 (2 weeks): Add shopping cart, checkout flow. Customer reviews sprint 1 demo — requests UI change. Change is added to next sprint backlog.
Sprint 3 (2 weeks): Payment integration, order confirmation. The UI change from sprint 1 feedback is also done here.
Agile vs Waterfall — Key Differences
| Aspect | Waterfall | Agile |
|---|---|---|
| Requirements | Fixed upfront | Evolve through sprints |
| Delivery | Once at end | Every sprint (2–4 weeks) |
| Customer Involvement | Only at start & end | Continuous throughout |
| Testing | After all coding done | Every sprint, alongside coding |
| Change Handling | Very difficult, costly | Welcomed and expected |
| Team Size | Any size | Small teams (5–9 best) |
| Documentation | Heavy, formal | Light, just enough |
| Risk | High (issues found late) | Low (issues found early) |
Beyond Waterfall and Agile, two other important models are V-Model (critical for QA professionals) and Spiral (important for high-risk projects). Understanding these models helps you choose the right approach and gives you an edge in interviews.
V-Model (Verification and Validation Model)
An extension of the Waterfall model where each development phase has a corresponding testing phase. The process forms a "V" shape — the left side represents development phases going down, and the right side represents testing phases going up. Testing planning begins simultaneously with development.
V-Model Structure
← Development Side Testing Side → Requirements Analysis ←——→ Acceptance Testing (UAT) ↓ ↑ System Design ←——→ System Testing ↓ ↑ Architecture Design ←——→ Integration Testing ↓ ↑ Module Design ←——→ Unit Testing ↓ ↑ CODING (bottom of V)
The arrows ←——→ mean that for every development artifact on the left, there's a corresponding test plan created at the same time on the right. Testing is executed in reverse order — unit tests first, then integration, then system, then UAT.
When Airbus builds navigation software, V-Model is used. While developers are writing code for each module, QA engineers are simultaneously writing test plans for that module. Every single line of requirements has a corresponding acceptance test. FDA and aviation regulations mandate this level of traceability.
Spiral Model
A risk-driven, iterative model that combines elements of Waterfall and iterative development. Each iteration (spiral) goes through 4 phases: Planning → Risk Analysis → Engineering → Evaluation. Risk is analyzed and mitigated in every single spiral, making it ideal for large, complex, high-risk projects.
4 Phases of Each Spiral
Just as SDLC is the structured process for building software, STLC is the structured process for testing that software. Without a defined testing life cycle, QA teams would be doing ad-hoc, inconsistent testing — missing critical bugs and delivering unreliable software.
STLC (Software Testing Life Cycle) is a systematic, structured sequence of activities that the QA/testing team performs to ensure software quality. It defines what testing activities to do, when to do them, who performs them, and what deliverables to produce. Like SDLC, each STLC phase has specific Entry and Exit criteria.
Key Characteristics of STLC
STLC Phases at a Glance
STLC vs. Ad-Hoc Testing
A startup launches a payment app without following STLC. Testers randomly test features they "feel" are important. No test plans. No test cases documented. No regression testing. Two weeks after launch, a critical bug is discovered — users can checkout without actually being charged. Revenue loss: ₹50 lakhs in fraudulent orders before detection.
With STLC: Payment flows would have had formal test cases during Test Case Development phase. These critical scenarios would have been identified and covered systematically.
Role of QA Team in STLC
Modern best practice is "Shift-Left Testing" — involving QA from the Requirements Analysis phase (STLC Phase 1) rather than waiting for code. QA engineers review requirements and design documents to catch issues before code is written. This is the single most impactful practice for reducing defect cost.
Let's walk through all 6 phases of STLC in depth using the example of testing a Banking Mobile App (loan application feature).
Phase 1 — Requirement Analysis
This is where the QA team gets involved — ideally before development begins. The team analyzes the requirements from the SRS document to understand what needs to be tested and whether requirements are testable.
QA team reads the requirement: "Loan applicant must enter PAN card number." QA identifies: Is PAN validation needed (10-char alphanumeric)? What happens with invalid PAN? What if PAN field is empty? These clarification questions are raised with BA — ambiguities caught before a single line of code is written.
RTM — Requirement Traceability Matrix
RTM is a table that maps every requirement to its corresponding test cases. This ensures no requirement goes untested.
| Req ID | Requirement Description | Test Case ID | Status | |--------|-----------------------------|--------------------|---------| | REQ-01 | User can apply for loan | TC-101, TC-102 | Covered | | REQ-02 | PAN validation mandatory | TC-103, TC-104 | Covered | | REQ-03 | Loan amount min ₹10K max ₹1Cr| TC-105, TC-106, TC-107| Covered| | REQ-04 | EMI calculator | TC-108, TC-109 | Covered | | REQ-05 | Document upload (PDF/JPG) | TC-110 | Partial | ← REQ-05 has gap — only 1 test case for multiple scenarios
Phase 2 — Test Planning
The Test Lead or Test Manager creates the Test Plan — the master document that guides all testing activities. This is the most strategically important document in STLC.
Phase 3 — Test Case Development
QA engineers write detailed test cases for every requirement identified in the RTM. A good test case includes: Test Case ID, Description, Preconditions, Test Steps, Expected Result, Actual Result, Status.
Test Case ID : TC-103 Module : Loan Application — PAN Validation Requirement : REQ-02 Test Type : Negative Test Precondition : User is on Loan Application form page Test Steps : 1. Enter invalid PAN "ABCDE1234" (9 chars instead of 10) 2. Click "Proceed" Expected Result: Error message "Invalid PAN number. Please enter 10-character PAN" Actual Result : [To be filled during execution] Status : [Pass / Fail]
Phase 4 — Test Environment Setup
Before executing tests, the environment must be configured to match (as closely as possible) the production environment. This phase is often done in parallel with Test Case Development.
Phase 5 — Test Execution
The actual testing begins. Testers execute test cases against the application, log results, and report defects for any failures.
Phase 6 — Test Cycle Closure
When testing is complete (or when exit criteria are met), the team formally closes the testing cycle. This phase is about documentation, learning, and improvement.
Entry and Exit Criteria are among the most important concepts in STLC. They act as "Quality Gates" — checkpoints that prevent a team from moving to the next phase prematurely or finishing a phase incompletely. Think of them as doors you need a key to unlock before proceeding.
The set of prerequisite conditions that MUST be satisfied before a testing phase can begin. If entry criteria are not met, the phase should not start. This prevents wasted effort — e.g., you shouldn't start test execution if there's no stable build to test.
The set of conditions that must be achieved for a testing phase to be considered complete. These are measurable objectives that confirm the phase has been done thoroughly enough to move forward — e.g., 95% test cases executed, 0 critical open defects.
Entry Criteria = You need a valid boarding pass + ID to enter the security checkpoint (you cannot skip this). Exit Criteria = You must pass the metal detector with no alarms, laptop screened, liquids checked — only then you're cleared to proceed to the gate. No shortcuts allowed.
Entry & Exit Criteria for All 6 STLC Phases
| STLC Phase | Entry Criteria (Must have before start) | Exit Criteria (Must complete before end) |
|---|---|---|
| Requirement Analysis | SRS/BRS document available & signed off by stakeholders | RTM prepared, automation feasibility report ready, all ambiguities resolved |
| Test Planning | RTM available, automation feasibility report, project timeline confirmed | Test Plan approved by QA Manager, effort estimates signed off |
| Test Case Development | Approved Test Plan, SRS document, design documents available | All test cases written & peer-reviewed, test data prepared, RTM updated |
| Test Environment Setup | Test Plan approved, hardware/software requirements list available | Environment verified working, smoke test passed, test data loaded |
| Test Execution | Test cases reviewed, environment stable (smoke test passed), build deployed | All test cases executed, defects logged with details, test execution report ready |
| Test Closure | All test cycles complete, defect report final, all critical bugs resolved | Test Summary Report approved, test artifacts archived, retrospective done |
Real-World Scenario
A development team rushes and says "Testing is done, deploy to production!" But the exit criteria say: "95% test execution, 0 critical open bugs." Currently: 72% tests executed, 3 critical open bugs.
Without formal exit criteria, the project manager might override the QA team under schedule pressure. With exit criteria, the QA lead has documented evidence to block the release: "Deployment cannot proceed per agreed exit criteria — 3 critical defects are unresolved." This protects both the product quality AND the QA team.
In many organizations, exit criteria are formally defined in the Test Plan and must be approved by the client or project manager before testing begins. This prevents arbitrary "let's ship it" decisions that bypass quality standards. If exit criteria cannot be met due to schedule, a formal Risk Acceptance sign-off is required from management.
When a tester finds a problem during testing, it doesn't just get "fixed." It goes through a formal journey — the Defect Life Cycle (also called Bug Life Cycle). This structured process ensures defects are tracked, communicated, resolved, and verified systematically. Every defect has a current state at any point in time.
The Defect Life Cycle (Bug Life Cycle) is the complete journey of a defect — from the moment it is discovered and reported by a tester, through assignment, investigation, fixing, retesting, and final closure. Each stage has a specific status and responsible party.
Defect States & Flow
Tester finds bug
↓
[NEW] — Bug logged in tracker (JIRA/Bugzilla)
↓
[ASSIGNED] — Test Lead reviews & assigns to developer
↓
[OPEN] — Developer starts analyzing & working on fix
↙ ↘
[FIXED] [REJECTED] — Not a defect / Already fixed / Duplicate
↓ ↓
[PENDING RETEST] [DEFERRED] — Valid but postponed to next release
↓
Tester retests
↙ ↘
[VERIFIED] [REOPENED] — Fix didn't work, back to ASSIGNED/OPEN
↓
[CLOSED]
All Defect States Explained
Defect Severity vs Priority
These two are frequently confused — they are different concepts:
High Severity, Low Priority: A rarely-used admin report shows incorrect totals. Technically severe, but used by 2 people monthly — can wait till next release.
Low Severity, High Priority: Company logo is misspelled on the homepage. Technically minor (doesn't break anything), but extremely high business priority (brand reputation, fix immediately).
High Severity, High Priority: Users cannot log in — application crashes. Fix immediately, critical blocker.
Good Bug Report — What to Include
Bug ID : BUG-2024-089 Title : Payment fails with valid Visa card after OTP entry Severity : Critical Priority : High Module : Payment Gateway Environment : Chrome 118 / Windows 11 / Test Environment v2.4 Steps to Reproduce: 1. Add item to cart (iPhone 15) 2. Proceed to checkout 3. Select "Visa Card" payment 4. Enter valid test card: 4111111111111111 5. Enter correct OTP received on registered mobile 6. Click "Confirm Payment" Expected Result : Order placed successfully, redirect to confirmation page Actual Result : "Payment Failed. Please try again." error appears. Order NOT placed. Amount NOT deducted. Screenshot : [Attached: payment_error.png] Console Logs : [Attached: browser_console.txt] Reproducibility : 100% reproducible (tested 5 times)
SDLC and STLC are both critical, interconnected processes. SDLC is the parent — the complete software creation process. STLC is a subset — the testing dimension within SDLC. They work together, not independently.
STLC is a part of SDLC. Every SDLC will have an STLC embedded within it. They cannot be separated — the Testing Phase of SDLC is where STLC runs. In Agile, STLC runs inside every sprint of the SDLC.
| Aspect | SDLC | STLC |
|---|---|---|
| Full Form | Software Development Life Cycle | Software Testing Life Cycle |
| Purpose | Build high-quality software from scratch | Validate and verify that the built software meets requirements |
| Scope | Entire software lifecycle (planning to maintenance) | Only the testing activities |
| Team | Project Managers, Business Analysts, Developers, QA, DevOps | Test Manager, QA Engineers, Automation Engineers |
| Phases | Planning → Requirements → Design → Development → Testing → Deployment → Maintenance | Req Analysis → Test Planning → Test Case Dev → Env Setup → Execution → Closure |
| Output | Working, deployed software product | Test artifacts (plans, cases, reports) + defect reports |
| Primary Goal | Build what the customer needs | Ensure what was built matches what was needed and works correctly |
| Relation | Parent process | Subset/child process |
| Starts When | When business approves the project | When SRS document is available (sometimes earlier) |
| Ends When | Software is decommissioned | Test Closure Report is approved |
| Documents | Project Plan, SRS, SDD, Deployment Guide | RTM, Test Plan, Test Cases, Defect Report, Test Summary Report |
How SDLC & STLC Work Together in Agile
Sprint 5 of an e-commerce app:
Day 1–2 (STLC: Requirement Analysis): QA analyzes user stories for "Wishlist feature." Creates RTM. Identifies edge cases developers haven't thought of.
Day 1–4 (SDLC: Development): Developers code the Wishlist feature.
Day 3–4 (STLC: Test Case Development): QA writes test cases simultaneously while devs code.
Day 5 (STLC: Environment Setup): QA deploys build to test environment, runs smoke tests.
Day 5–8 (STLC: Test Execution): QA tests Wishlist — finds 3 bugs. Developers fix same day (bugs in sprint).
Day 9–10 (STLC: Test Closure + SDLC: Deployment): QA signs off, sprint demo, feature deployed to production.
Understanding SDLC and STLC theory is the foundation, but what separates an average QA/developer from a senior professional is understanding how these processes are applied in the real world. Here are industry-proven best practices used in top companies.
1. Shift-Left Testing
Shift-Left means involving QA as early as possible in the SDLC — starting from requirements review, not after development. The "left" refers to moving testing activities to the left side of the SDLC timeline.
2. Test Automation Strategy
Not every test should be automated. Use the Test Automation Pyramid as your guide:
⚠️ E2E / UI Tests ⚠️
(Selenium, Playwright)
Few, slow, brittle, expensive
—————————————————
Integration Tests
(API testing — Postman, RestAssured)
Medium count, medium speed
—————————————————
Unit Tests
(JUnit, pytest, Jest)
Many, fast, cheap, reliable
← MOST investment here →
Invest most in unit tests (fast, cheap, reliable). Moderate investment in integration/API tests. Minimal investment in E2E/UI tests — only for critical user journeys.
3. CI/CD Integration with Testing
Modern software delivery uses CI/CD pipelines (Continuous Integration / Continuous Delivery) where tests run automatically on every code commit:
Amazon deploys to production every 11.7 seconds on average. This is only possible because of their massive automated test suite in CI/CD pipelines — thousands of automated tests run before any code reaches production. QA engineers focus on test strategy, automation framework maintenance, and exploratory testing for new features.
4. Defect Prevention (Not Just Detection)
5. Test Metrics That Matter
Common SDLC/STLC Interview Questions
Always connect SDLC/STLC concepts to real tools. Mention: JIRA for project management & bug tracking; Confluence for documenting test plans; Selenium/Playwright for E2E automation; JMeter for performance testing; Git/GitHub Actions for CI/CD pipelines. This shows practical, industry-level knowledge.
🎉 You've Completed SDLC & STLC!
From SDLC phases and Waterfall to Agile sprints, V-Model, STLC phases, Entry/Exit criteria, and Defect Life Cycle — you now have a complete, interview-ready understanding of the full software lifecycle.
Explore More Tutorials →
