SDLC & STLC

A reference for the two life-cycle frameworks every QA engineer is expected to know: SDLC (how the product gets built) and STLC (how the product gets tested). Useful for interview prep, planning meetings, and aligning across teams.

SDLC Phases

Key principle

QA is not a phase — it's a thread that runs through all six. The "Testing" phase is where formal verification concentrates, but shift-left moves QA activities earlier (review at requirements time) and shift-right moves them later (production monitoring and on-call rotation).

SDLC Models

V-Model — what each side maps to

Requirements ────────────────────── Acceptance Tests
   System Design ────────────── System Tests
       Architecture ────── Integration Tests
           Module Design ── Component Tests
               Coding

Reading top to bottom: dev work descends, then ascends back up through testing. Each test phase verifies the dev phase at its own level.

Agile vs Waterfall — at-a-glance

STLC Phases

The Software Testing Life Cycle — the QA-side mirror of SDLC. Six phases with explicit entry / exit criteria.

1. Requirement Analysis

Understand what's being tested before any test work starts.

2. Test Planning

Define the strategy, scope, schedule, and resourcing.

3. Test Case Design

Turn requirements into executable test cases.

4. Test Environment Setup

Stand up the infrastructure to execute against.

5. Test Execution

Run the tests, log defects, retest.

6. Test Closure

Wrap up the cycle, capture lessons.

Entry & Exit Criteria — Quick Reference

One table, all six STLC phases.

Test Deliverables by Phase

Test Strategy vs Test Plan

A common confusion — they're different documents.

The Test Plan inherits from the Test Strategy — it doesn't restate the org's standards, just references them.

QA Activities in Agile / Scrum

Agile compresses the STLC. Most phases happen continuously inside each sprint.

Per-sprint mapping

Definition of Done — testing criteria

A story isn't "done" until everything below is true. Treat this as a checklist on the story card.

□ All acceptance criteria verified manually or via automation
□ Unit-test coverage meets team threshold (e.g. ≥ 80 %)
□ Integration tests passing in CI
□ End-to-end / regression suite passing
□ No open critical or high-severity defects
□ Performance budget met (if perf-sensitive)
□ Accessibility checks passed (WCAG AA)
□ Cross-browser / cross-device tested per matrix
□ Code reviewed and approved
□ Docs updated (user-facing, API, runbook)
□ Telemetry / logging in place

The Test Pyramid in Agile

The cost-and-coverage shape of an Agile test suite. Layers, ratios, and what each layer is good at:

Anti-patterns to avoid:

• Ice-cream cone — heavy E2E, light unit. Slow, brittle, expensive to maintain.
• Hourglass — many unit + many E2E, almost no integration. Big behavioural gaps that don't show up until production.

Three Amigos meeting

When a story is unclear, get a developer, a tester, and a product person together (the "three amigos") to walk through it. The tester's role is to ask "what could go wrong?" and "what's the acceptance criteria for that case?" until the story is concrete enough to estimate.

Shift-left and shift-right

A mature Agile QA practice does both — find issues earlier and learn from production.