SDLC and the Test Lifecycle

A common interview opener is: 'describe the software development lifecycle and where testing fits.' The weak answer recites a list of phases from memory. The strong answer starts by naming the model, because testing's placement depends entirely on which lifecycle the team runs — and every company asks this expecting you to know the difference.

In the Waterfall model, phases run in sequence: requirements, design, implementation, testing, deployment, maintenance. Testing is a late, discrete phase — a formal test cycle happens after a complete build exists. The consequence is well documented: requirement ambiguities survive until the test phase, when fixing them means revisiting contracts, designs, and finished code. Waterfall persists in safety-critical and contract-driven work where each phase produces signed artifacts, so you must still be able to describe its test cycle even if you have only worked in agile shops.

The V-model is Waterfall with an explicit commitment that testing starts at the beginning. Each development stage on the descending left arm pairs with a test level on the ascending right arm, and each pair produces its artifacts before coding starts. The pairings:

The interview-relevant idea is that on the V-model, test design begins while requirements are still being written — you write acceptance criteria before a line of code exists, which is the original form of shift-left.

In iterative and agile models, testing is continuous: every sprint contains requirement review, test design, execution, and regression, and each potentially shippable increment passes through the same activities at smaller scale. CI pipelines run unit and integration suites on every commit; system and acceptance testing run against the sprint increment. The lifecycle does not disappear — it compresses into a repeating loop, and the discipline of entry and exit criteria matters more, not less, because the loop is fast.

The modern DevOps picture extends the loop further left (developers run tests pre-merge, requirement tests become automated checks) and further right (production monitoring, canary analysis, and automated rollback act as post-release test levels). When an interviewer asks where testing happens in DevOps, the answer is everywhere: the lifecycle phases became automated gates rather than calendar events.

Whatever the model, the test activities themselves follow a stable order — requirement analysis, test planning, test design, implementation, execution, defect reporting, closure — and that sequence is what the rest of this roadmap trains. Your job in an interview is to place that sequence inside the model the interviewer names, and to be honest about what each model buys and costs: Waterfall gives auditable artifacts at the price of late feedback; agile gives fast feedback at the price of requiring discipline to keep artifacts lightweight.

A test phase without entry and exit criteria is an event with a start time and no definition of done. 'System testing begins Monday' tells you nothing about whether the build is testable; 'system testing is complete' tells you nothing about whether it is safe to ship. Criteria convert both into binary decisions the whole team can check.

Entry criteria state what must be true before a phase may start. Typical ones for a system test cycle:

• Build 4.12.0 compiled and deployed to the test environment, smoke suite passed in under 30 minutes
• All planned features merged; feature freeze confirmed by the release owner
• Unit test pass rate 100% and integration suite green on the release branch
• Requirement traceability matrix updated: every in-scope requirement linked to at least one designed test case
• No open severity-1 defects from the previous cycle

If an entry criterion fails, you do not start — or you start with the failure documented and accepted by the release owner. That negotiation is itself a professional judgment: executing a system test cycle on a build that fails smoke testing produces noise, not information, because every defect report then carries the same 'cannot test, build broken' shadow.

Exit criteria state what must be true before the phase may be called complete. They must be measurable — 'testing went well' is not an exit criterion:

The subtle skill is the dispositions: when a test case fails, 'fix in this release', 'known issue, deferred with product approval', and 'test case is wrong, updated' are three different outcomes, and exit criteria force you to write down which one applies to each failure. Un-triaged failures are how teams ship with a red suite and call it done.

Criteria also create the defect-fix loop: a failed exit criterion sends the build back to development with open defects, the fix returns, regression re-runs, and the criteria are re-evaluated. The phase is complete when the criteria pass — not when the calendar says so. This is the concrete meaning of the feedback arrow people draw on V-model diagrams.

In interviews, expect to be asked to 'define exit criteria for system testing' cold. Reach for the five rows above — coverage, defect state, pass rate, regression, sign-off — and attach numbers. A candidate who says 'all tests pass and no critical bugs' gives the right shape; a candidate who adds 'and every minor failure has a written disposition from triage' gives the answer interviewers remember.

Six weeks after release, a customer reports that password reset emails arrive in the spam folder. In the post-incident review, someone opens the requirements document, finds the requirement, and discovers the painful truth: the requirement existed, it was marked covered, and no executed test ever touched it. The defect escaped not because testing was bad, but because nothing traced the requirement to the test that verified it.

Requirement traceability is the practice of linking each requirement to the test cases that verify it, in both directions. Forward traceability (requirement → tests) proves coverage. Backward traceability (test → requirement) exposes orphan tests — cases that verify something nobody asked for, eating execution time for no reason. A Requirements Traceability Matrix (RTM) records both:

Reading that table left to right takes ten seconds and answers the release questions that matter: REQ-104 has no test at all, REQ-102 has a failing test tied to an open defect. Without the matrix, both facts are hidden in spreadsheets and tribal memory until a customer finds them.

Building an RTM is mechanical, which is why it is a great early-career QA contribution: export requirements from the spec or user stories, assign stable IDs, design test cases with IDs, and record the links in a spreadsheet or a test-management tool (Zephyr, TestRail, or even the requirements system itself when it supports two-way links). The discipline that makes it work is change control: when a requirement changes mid-sprint, the matrix is the alarm system — it tells you exactly which test cases must be added, updated, or re-executed, instead of you re-reading the whole spec hoping to notice. In practice, a stale RTM is worse than none, because it launders outdated coverage into false confidence.

Traceability scales with the lifecycle. In acceptance-driven agile teams, each story's acceptance criteria function as the requirement rows and each criterion maps to a test (often an automated BDD scenario), so the RTM is effectively the story-to-automation mapping maintained by the pipeline. In regulated domains — medical devices, finance, aviation — the RTM is a compliance artifact auditors request by name; 'no requirement ships without a verified test' is a contractual obligation, not a best practice.

Interview framing: 'how do you ensure every requirement is tested?' deserves a tool-agnostic, concrete answer — assign IDs, maintain a forward-and-backward matrix, treat requirement changes as triggers to re-check linked tests, and review coverage percentage at every exit-criteria checkpoint. Mention a real tool only after the mechanics, because interviewers are listening for the discipline, not the vendor. From lifecycle mechanics, the natural next step is Test Levels and Test Types, where the paired test levels of the V-model become concrete suites you can name and run.