Software Testing Life Cycle (STLC): Phases, Roles, and Deliverables

A checkout discount can look correct on screen and still fail when a customer changes the basket, retries payment, or applies a second promotion. Finding those problems requires decisions well before someone clicks through a release candidate: which rules apply, which risks deserve attention, who prepares the data, and what evidence supports release.

The software testing life cycle (STLC) organizes that work. It covers understanding requirements, planning tests, designing and preparing them, executing them, and completing a testing cycle. Each activity produces something the next activity can use, such as an agreed rule, a reviewed test case, a reproducible failure, or a report of remaining risks. The activities can overlap and repeat as the product changes.

How STLC Fits Within Software Development

The software development life cycle (SDLC) covers the broader work of specifying, building, delivering, and maintaining software. STLC describes the testing work within that lifecycle. Reviewing a draft requirement is already a testing activity, even when executable software is unavailable. Later, testing evaluates the implemented behavior and supplies evidence for delivery decisions.

Six phases are a useful way to explain STLC: requirement analysis, test planning, test case development, environment setup, execution, and closure. They are a practical grouping rather than a universal prescribed sequence. ISTQB describes seven test-process activity groups, separating analysis, design, and implementation and treating monitoring and control as ongoing work. Environment preparation belongs within implementation in that model. The phase names matter less than covering the work and keeping feedback moving.

For the detailed activity model, consult the ISTQB Foundation Level syllabus, version 4.0.1. Its authors and the International Software Testing Qualifications Board are acknowledged as the source and copyright owners of the syllabus.

For a feature team, the following ownership assignments provide a starting point. They describe responsibilities to assign, not job titles every organization must employ. A small team may combine several roles.

STLC Phase	Suggested Coordinating Role	Useful Deliverables
Requirement analysis	Tester with product owner or business analyst	Clarified rules, prioritized test conditions, open questions
Test planning	Test lead or team member coordinating testing	Scope, risks, responsibilities, schedule, entry and exit criteria
Test case development	Tester with developer review	Reviewed cases, expected results, data needs, requirement links
Environment setup	Developer or platform engineer with tester verification	Identified build, prepared data, configuration record, smoke results
Test execution	Tester or developer for the assigned checks	Results, test logs, defect reports, confirmation and regression evidence
Test closure	Test lead or team member coordinating testing	Completion report, unresolved risks, reusable testware, improvement actions

Apply the Six STLC Phases to a Checkout Change

Consider an illustrative feature: a store introduces a discount code for eligible baskets. The specification and test data below are invented for explanation, not a customer case or reported benchmark. Following the same feature through the lifecycle shows how one decision becomes the input to another.

Requirement Analysis: Agree on Observable Rules

The initial story says, “As a shopper, I want to apply a promotion code before payment.” That sentence leaves too much unanswered. A tester reviews it with the product owner and developer: can codes combine, what happens after a basket edit, and which price determines eligibility?

Suppose they agree that a code applies only to an eligible merchandise subtotal of at least $50, before delivery charges. It cannot combine with another code, and eligibility must be recalculated after basket changes. They also need a precise rule for when the code expires, including the relevant time zone. Recording that rule prevents the developer and tester from choosing different interpretations of the same date.

The output is a set of test conditions, meaning the aspects or events to verify, plus unresolved questions and their owners. Examples include qualifying subtotal, expired code, incompatible promotions, and eligibility after removing an item. Link these conditions to the story and its acceptance criteria. A requirements traceability matrix is one possible representation; linked records can serve the same purpose.

Analysis can expose a defect in a requirement before code exists. Do not silently turn an unanswered question into an expected result. Ask the responsible stakeholder to settle it, or record the assumption and its effect on the testing scope.

Test Planning: Allocate Effort According to Risk

Planning defines the objectives, approach, resources, and constraints. For this checkout change, incorrect totals and stale discounts after basket edits deserve attention because they affect the amount charged. The team should also decide whether the change affects tax calculation, existing promotions, or the payment integration.

The person coordinating testing agrees who will check calculation logic, who will exercise the API and checkout interface, and who will verify the business rules. Developers might automate calculation checks while a tester explores changes in basket state. Business input is needed to confirm that expected outcomes reflect the intended promotion policy.

The deliverable can be a concise feature test plan rather than a large standalone document. It should record in-scope risks, exclusions, environments, responsibilities, timing, and completion conditions. Include dependencies such as payment sandbox access. An unavailable dependency should appear in the plan before it becomes a blocked test near release.

Monitoring and control start here and continue throughout the cycle. If the sandbox is delayed, the team may continue calculation tests with a substitute while keeping the untested payment interaction visible. Changing the schedule or test priority is a control action; reporting the delay alone does not resolve it.

Test Case Development: Turn Conditions Into Reproducible Checks

Test design translates the conditions into inputs, actions, and expected results. For the agreed threshold, useful illustrative baskets have eligible subtotals of $49.99, $50.00, and $50.01. State what happens to the discount and final payable amount in each case, using the agreed rounding and calculation rules. A vague expectation such as “discount works correctly” leaves execution open to interpretation.

Add cases for a basket that qualifies when the code is applied but falls below the threshold after an item is removed. Review combinations with existing promotions and the behavior of an expired code. Developers can identify implementation dependencies; product representatives can resolve disagreements about intended behavior.

Implementation then prepares the assets needed to run those designs: manual procedures, automated scripts where appropriate, test data, and a prioritized suite. Keep cases traceable to their source rules so a later change identifies the affected coverage. Exploratory charters can complement scripted cases, for example by directing a tester to investigate basket edits during checkout.

For teams managing this work in Jira, Sherlock Test Management describes an AI-assisted workflow for drafting cases from selected Jira issues, Confluence pages, files, and a plain-language testing goal. A tester could supply the clarified promotion story, review the proposed cases for the basket-edit risk, and approve the useful coverage into a versioned baseline. These review and baseline capabilities come from the app rather than native Jira. Approval establishes the test design; the team still needs to execute the checks and record results against the tested build. The Sherlock product workflow explains how proposals become approved cases.

Environment Setup: Establish What the Results Will Describe

Environment preparation can begin while cases are being developed. For the coupon feature, arrange the identified application build, feature configuration, eligible and ineligible products, promotion records, and access to the payment sandbox. Document configuration differences that could affect the behavior being assessed.

The environment needs to represent the conditions relevant to the test objective. A calculation check may run in isolation, while a checkout integration check needs the relevant services working together. Passing an isolated check does not provide evidence that the full payment interaction works.

The tester verifies readiness with appropriate smoke checks, such as opening checkout, adding a product, and reaching the sandbox payment step. Keep the build identifier, configuration, data version, and readiness results with the run. If an expired promotion remains cached after data setup, investigate that condition before treating every related failure as a defect in the new code.

Test Execution: Record Outcomes and Investigate Failures

During execution, a person or an automated test runner performs the checks and compares actual behavior with expected behavior. Record the outcome against the case and the build tested. Keep failed and blocked outcomes distinct: a promotion calculation that returns the wrong total has failed; a check that cannot reach an unavailable sandbox is blocked.

Imagine the illustrative basket-edit test shows that a discount remains after the subtotal falls below the threshold. The report should include the relevant case, exact basket data, build and environment, reproduction steps, expected and actual totals, and useful logs or screenshots. Developers need enough information to reproduce and diagnose the anomaly. Triage establishes whether the cause is product code, configuration, test data, or an incorrect expectation.

After a fix, confirmation testing checks that the reported problem has been resolved. Regression testing checks for adverse effects elsewhere, such as other promotions or the undiscounted checkout path. Select regression scope using change impact and risk rather than assuming every fix needs an identical full-suite rerun. Record both kinds of evidence; passing one does not substitute for the other.

Test Closure: Communicate Coverage and Remaining Risk

Closure, also called test completion, gathers the evidence needed at a milestone such as an iteration or release. Compare completed testing with the original objectives and criteria. Summarize the scope exercised, failures investigated, unresolved defects, blocked checks, and relevant deviations from the plan.

For the coupon feature, the report should distinguish verified basket recalculation from a payment interaction that remains untested. A high overall pass count would not answer that specific release concern. The people authorized to make the release decision need to see the gap and its possible consequences.

Preserve useful cases and scripts for future regression, retain the run's configuration references, and assign improvement actions. If data preparation caused repeated delays, give someone responsibility for a reusable promotion fixture. Completion should leave the next cycle better prepared, even when some defects are deferred through an explicit decision.

Set Entry and Exit Criteria for the Activity

Entry criteria state the preconditions for starting an activity. Exit criteria state what must be achieved to declare it complete. Define both around the test objective and level of testing. They should expose missing prerequisites and incomplete evidence without forcing every activity to wait for every other activity.

For checkout integration testing, useful example entry criteria are:

• The intended build is deployed and its feature configuration is recorded.
• Promotion rules and expected outcomes are sufficiently clear for the planned checks.
• Required basket data, service access, and payment sandbox connections are available.
• Readiness checks confirm that the relevant checkout path can be exercised.

Possible exit criteria include completing the agreed risk-focused coverage, investigating failed results, confirming blocking fixes, and documenting any untested areas. Agree what counts as a release-blocking issue before reviewing the results. Do not treat a universal pass-rate percentage as proof of readiness: it hides which risks remain unresolved.

When a criterion cannot be met, record the gap and escalate it to the appropriate decision-maker. Extending testing, changing scope, withholding the feature, or explicitly accepting a residual risk are different decisions. Preserve the actual test outcome even if the business chooses to proceed. Accepted risk does not turn a blocked check into a pass.

Repeat the Lifecycle Within Agile Delivery

In Agile delivery, these activities overlap and recur for small changes. Requirement analysis can happen during refinement, case design alongside coding, and automated execution after a change is integrated. A tester can explore an available slice while another dependency is being prepared. Exploratory testing can combine learning, design, and execution within the same session.

Suppose the product owner later changes the promotion to include a previously excluded product category. The team revisits the rule, assesses the affected calculations and risks, updates cases and data, and runs the necessary checks again. Requirement-to-test links help identify that work. Previous results remain evidence for the earlier version; they do not prove the revised rule works.

Assign responsibility for the loop rather than handing all quality work to a tester. ISTQB distinguishes test management responsibilities from technical testing responsibilities, but those responsibilities can be shared or combined. In Scrum, the cross-functional team creates the Increment, and the Definition of Done establishes its required quality measures. Story acceptance criteria describe the particular feature's behavior; they do not replace that broader quality commitment.

Automation supports this cadence when runnable tests and suitable environments exist. A system that generates test cases or plans a run has produced testing assets, not proof that the software passed. Connect planning and execution through identifiable cases, builds, results, and defects so the team can inspect what was tested after each change.

Start With One Traceable Risk

For the next feature, choose one important failure condition and follow it through the lifecycle. Write down the agreed behavior, assign the testing work, prepare the required data and environment, and preserve the result against the tested version. Then make the remaining uncertainty visible to whoever decides whether to release.

For the coupon change, that condition could be a basket dropping below the eligibility threshold after the discount is applied. If the team can trace that risk through its rule, case, execution, defect handling, and final decision, it has a practical STLC to extend. Add process detail where it improves those decisions, and keep the activities moving as requirements and evidence change.