Software Development Life Cycle (SDLC)

What is SDLC?

The Software Development Life Cycle (SDLC) is a systematic process for planning, creating, testing, deploying, and maintaining software. It provides a structured framework that guides development teams from an initial idea through to a fully delivered, quality product.

SDLC is the parent process that contains STLC (Software Testing Life Cycle) within it. Understanding SDLC is essential for QA engineers because it defines when and how testing activities fit into the broader project flow.

SDLC Phases

Regardless of the model used, most SDLC frameworks share a common set of phases:

1. Requirement Gathering & Analysis — Understand what stakeholders need; document functional and non-functional requirements.
2. System Design — Translate requirements into architecture, database design, and UI wireframes.
3. Implementation (Coding) — Developers write the code based on design specifications.
4. Testing — QA verifies the software works as intended; defects are found, reported, and fixed.
5. Deployment — The validated build is released to production or a staging environment.
6. Maintenance — Ongoing bug fixes, performance improvements, and feature enhancements post-release.

SDLC Models

Different projects call for different approaches. Here are the four most widely used SDLC models in the industry today.

Waterfall Model

The oldest and most straightforward model. Development flows in one direction — like a waterfall — through sequential phases. Each phase must be fully completed before the next begins.

When it works well

• Requirements are fixed and well-understood upfront
• Short-duration projects with a clear end goal
• Regulated industries (medical, aerospace) where heavy documentation is required

Limitations

• Testing happens late — defects found in testing are expensive to fix
• No flexibility for changing requirements
• Customer sees the product only at the end

Agile Model

Agile is an iterative approach where software is built and tested in short cycles called iterations or sprints (typically 1–4 weeks). Working software is delivered at the end of each iteration.

Core Agile principles (from the Agile Manifesto)

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

QA in Agile

QA is embedded within each sprint. Testers work alongside developers, write test cases during sprint planning, execute tests as features are developed, and provide fast feedback. Regression testing is automated where possible.

Scrum Framework

Scrum is the most popular implementation of Agile. It introduces specific roles and ceremonies to manage iterative development.

Key Scrum roles

• Product Owner — Defines and prioritises the product backlog
• Scrum Master — Facilitates the process; removes blockers
• Development Team — Developers, QA, designers who build the product

Key Scrum ceremonies

• Sprint Planning — Team selects backlog items for the upcoming sprint
• Daily Standup — 15-minute sync: what did I do, what will I do, any blockers?
• Sprint Review — Demo of completed work to stakeholders
• Sprint Retrospective — Team reflects on process improvements

V-Model (Validation & Verification)

The V-Model extends Waterfall by mapping each development phase to a corresponding testing phase. Development and testing activities happen in parallel from the start.

The V-Model is popular in safety-critical domains (medical devices, aviation) where every requirement must be traced to a test.

QA's Role in SDLC

A QA engineer's involvement should not be limited to the Testing phase. Here's how QA can add value across all SDLC phases:

Model Comparison

Choosing the Right SDLC Model

Picking the wrong SDLC model is one of the most costly mistakes a project can make. Here is a practical decision guide based on project characteristics:

DevOps and Continuous Delivery in SDLC

Modern software teams increasingly adopt DevOps as an extension of Agile SDLC. Where Agile focuses on iterative development and testing, DevOps extends the lifecycle into automated deployment, monitoring, and feedback.

Key DevOps additions to SDLC

• Continuous Integration (CI) — Every code commit triggers an automated build and test run. Tools: Jenkins, GitHub Actions, GitLab CI.
• Continuous Delivery (CD) — Validated builds are automatically deployed to staging. A manual gate controls production releases.
• Continuous Deployment — Every passing build goes directly to production automatically. Requires high test automation coverage.
• Infrastructure as Code (IaC) — Environments (dev, staging, production) are provisioned via code (Terraform, Ansible), reducing "works on my machine" issues.
• Monitoring and Feedback — Production monitoring (Datadog, Grafana, Prometheus) feeds real-world defect data back into the backlog — closing the SDLC loop.

At Viasat, our SDLC included a full CI/CD pipeline: unit tests ran on every commit, integration tests ran nightly, and our Ansible-managed environments meant QA always tested on a consistent, reproducible stack. This dramatically reduced environment-related false failures.

Common QA Mistakes in SDLC

After 6+ years of working across different SDLC models and organisations, these are the most damaging QA mistakes I've seen teams repeat:

• Joining late. QA brought in only after development is complete — the most expensive pattern. Requirements defects caught during development cost 10–100x less to fix than those caught in production.
• Testing only the happy path. Scripted tests cover the known scenarios. The bugs that slip to production almost always live in the edge cases — invalid inputs, network failures, race conditions, unexpected user sequences.
• No regression strategy. New features ship without protecting existing functionality. Without a regression suite, every release is a gamble.
• Environment mismatch. QA passes, production fails — because the test environment differed from production in OS version, config, or data. Solved by IaC and environment parity practices.
• Treating test closure as optional. Skipping the test closure report means lessons aren't captured. The same mistakes repeat on the next project.

QA's Role Across SDLC Phases

A QA engineer who only tests is only using half their value. The most impactful QA professionals engage across every SDLC phase — preventing defects upstream rather than just catching them downstream. Here is a detailed breakdown of what effective QA involvement looks like at each stage.

Requirements Phase

This is where QA can prevent the most expensive class of defect: the wrong feature built correctly. During requirements review, QA engineers look for requirements that are untestable, ambiguous, or missing acceptance criteria entirely.

Consider the difference between these two requirements. An untestable requirement reads: "The login page should be fast." There is no pass/fail condition — "fast" is subjective and unmeasurable. A testable requirement reads: "The login page must load and be interactive within 2 seconds on a 4G connection." This has a concrete metric, a defined condition, and a clear pass/fail boundary.

QA engineers in this phase build the initial Requirement Traceability Matrix (RTM), flag missing edge cases — "what happens when a user enters special characters in the username field?" — and push back on requirements that assume happy-path only. This early involvement can reduce rework cost by an order of magnitude compared to catching the same issues in UAT.

Design Phase

During system and architecture design, QA contributes to decisions that will define what can be tested later. This includes participating in test environment design — identifying what infrastructure is needed to replicate production conditions — and defining a test data strategy that covers realistic volumes, edge cases, and PII-safe synthetic data sets. QA also reviews architecture decisions for testability risks: a microservices design with no distributed tracing will make integration defects extremely hard to reproduce and diagnose.

Development Phase

While developers write code, QA should be writing test cases in parallel — not waiting for the first build to drop before starting. CI hooks are configured so automated tests trigger on every pull request. QA also reviews unit test coverage reports: if a new payment module has 30% unit test coverage, that is a risk flag that should be raised before integration testing begins, not after.

Testing Phase

This is the phase most people associate with QA, but by the time you reach it, the groundwork should already be done. Test execution follows the test plan: functional tests, then integration, then regression. Bugs are logged with full reproduction steps, severity, and environment details. Retesting validates fixes without reopening already-passed cases. Regression ensures no new code broke existing functionality.

Deployment Phase

QA's role does not end when the build goes to production. Smoke tests in the live environment confirm that the deployment itself was successful — that the app starts, critical flows function, and no environment-specific configuration was missed. For canary releases (rolling out to 5% of users first), QA defines the pass/fail criteria for expanding the rollout and the rollback criteria if error rates spike above a defined threshold.

Maintenance Phase

After release, production bug reports feed back into the regression suite. Any defect found in production that was not caught in testing reveals a gap in the test suite — that scenario should be codified as a test case immediately, so it can never slip through again. QA also monitors bug trend data: if the same module consistently generates post-release defects, that is a signal to increase test depth there on the next release cycle.