# What is the software testing life cycle (STLC)? The software testing life cycle (STLC) is the sequence of testing phases in a project, from requirement analysis and planning to execution and closure. Last updated September 29, 2026, 8 min read ## Learning objectives After reading this article you will be able to: - Define the software testing life cycle - Explain each phase and what it produces - Compare the STLC with the SDLC ## Related content - [What is software testing?](https://specstory.com/learning/testing/software-testing) - [What is QA testing?](https://specstory.com/learning/testing/qa-testing) - [What is acceptance testing (UAT)?](https://specstory.com/learning/testing/acceptance-testing) - [What is test automation?](https://specstory.com/learning/testing/test-automation) ## What is the software testing life cycle (STLC)? The software testing life cycle (STLC) is the series of phases that testing moves through in a project. The usual six phases are requirement analysis, test planning, test case development, test environment setup, test execution, and test closure. Each phase produces its own work product, e.g. a test plan, and has conditions for starting and finishing. STLC is an industry term, not an ISTQB one. The International Software Testing Qualifications Board (ISTQB) [Foundation Level syllabus](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/) describes a test process of seven activity groups instead. It adds that these activities often overlap and usually need tailoring to the project. The STLC organizes [software testing](https://specstory.com/learning/testing/software-testing) inside one project or release. It makes a team agree on what to test and on what counts as finished, before testing starts. ## How does the software testing life cycle work? The six common phases usually run in this order: 1. **Requirement analysis.** Testers read the requirements, e.g. a [product requirements document](https://specstory.com/learning/ai-coding/prd-for-coding-agents), and list what can be tested and where the gaps are. Many teams start a traceability matrix that later maps each requirement to its tests. 2. **Test planning.** A test lead writes the test plan, which sets the scope and the conditions for finishing. The plan also names the test types to run, e.g. [accessibility testing](https://specstory.com/learning/testing/accessibility-testing). 3. **Test case development.** Testers write test cases with inputs and expected results, often with a technique, e.g. [boundary value analysis](https://specstory.com/learning/testing/boundary-value-analysis). 4. **Test environment setup.** The team installs the build and its data, often in a [staging environment](https://specstory.com/learning/environments/staging-environment), and a [smoke test](https://specstory.com/learning/testing/smoke-testing) checks that it runs. 5. **Test execution.** Testers run the cases, log the results, and file a defect report for each confirmed failure. They rerun each failed case after its fix. 6. **Test closure.** The test lead compares the results with the plan and its exit criteria. A test completion report, also called a test summary report, records the defects and risks still open. Cases worth keeping join the [regression tests](https://specstory.com/learning/testing/regression-testing). Diagram: The six phases of the software testing life cycle Each phase uses the output of an earlier one. Execution repeats after each fix until the exit criteria set during planning are met, or until the stakeholders accept the remaining risk. Closure follows. Six of the ISTQB syllabus's seven activity groups map roughly onto these phases. The seventh is test monitoring and test control, which compares progress with the plan. The syllabus also names two roles. A test management role leads planning, monitoring, control, and completion. A testing role, often held by a quality assurance ([QA](https://specstory.com/learning/testing/qa-testing)) engineer, does analysis, design, implementation, and execution. One person can hold both. ## What is an example of the software testing life cycle? Here is an illustrative example. Acme Co. sells furniture online. Its product owner asks the team to "Let customers edit their delivery address during checkout." A QA engineer takes the change through the six phases: 1. The QA engineer asks what should happen to the cart. The owner says the cart must keep its items, and that rule joins the requirements. 2. The test plan's exit criteria are that the 6 planned test cases have run and no severe defect is open. 3. Of the 6 cases, 2 use addresses of 100 and 101 characters, on the field's limit and one past it. Case CO-3 checks that 2 items stay in the cart. 4. The team deploys the build to `staging.shop.example.com`, and a smoke test passes. 5. Five cases pass and CO-3 fails. The address saved, but the cart emptied. A developer has a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) fix the session code, and the 6 cases then pass on the fixed build. 6. The completion report shows 6 cases passed and 1 defect fixed, and CO-3 joins the regression suite. This example is simplified. A real release would test many changes at once, and its phases would overlap. ## What changes when a coding agent writes the code? A coding agent merges the middle of the cycle into one session. It can write test cases, run them, and edit the code until they pass. Test case development and execution become one loop, and the tests often run in the agent's own workspace, not on a staging build. The phases at the two ends can get skipped. When the agent generates tests from the prompt alone, nobody checks the requirements for gaps first. Closure can become the agent's report that the work is "done," with no exit criteria agreed in advance. In the Acme example, the cart rule came from the owner during requirement analysis, not from the request. A practical adjustment is to keep people at both ends. Write the requirements before the agent starts, and record the exit criteria in the team's [definition of done](https://specstory.com/learning/verification/definition-of-done-for-coding-agents). At closure, check the agent's evidence against those criteria, not against its own summary. ## What are exit criteria? Exit criteria are the conditions that must be met before a testing phase or task counts as finished, e.g. that every planned test has run. The ISTQB [defines exit criteria](https://glossary.istqb.org/en_US/term/exit-criteria) as the set of conditions for officially completing a defined task. The test plan sets them for each test level. The syllabus names two kinds. A measure of thoroughness sets a target for a number, e.g. the count of unresolved defects. A condition that is true or false names a state, e.g. that all regression tests are automated. The ISTQB [defines entry criteria](https://glossary.istqb.org/en_US/term/entry-criteria) as the matching conditions for officially starting a defined task. Typical entry criteria are a ready test environment, requirements clear enough to test, and a build that passes its smoke test. Agile teams often call exit criteria the definition of done, and entry criteria the definition of ready. A [quality gate](https://specstory.com/learning/ci-cd/quality-gate) in a pipeline can check the exit criteria that a machine can measure. ## What are the limits of the STLC? The STLC organizes testing, but it does not make the tests good. Its main limits are: - **It assumes settled requirements.** The phases run in order only when the requirements are fixed before testing. On teams that ship small changes often, the phases overlap and a long plan goes out of date. - **It can start too late.** When testing waits for a finished build, a defect in the requirements shows up late. [Shift-left testing](https://specstory.com/learning/ci-cd/shift-left-testing) moves test activities earlier. - **Finished phases do not show that the software works.** The tests check only what the test cases name. - **A report can stand in for evidence.** A completion report can mark weak exit criteria as met, e.g. a bare count of tests run. ## How is a test strategy different from a test plan? A test strategy describes how an organization or product tests in general, and a test plan applies it to one project or release. The ISTQB [defines a test strategy](https://glossary.istqb.org/en_US/term/test-strategy) as a description of how to perform testing to reach test objectives under given circumstances. It [defines a test plan](https://glossary.istqb.org/en_US/term/test-plan) as documentation that describes the test objectives, the means, and the schedule for coordinating testing. A strategy sets lasting rules for many projects, e.g. that each change gets automated regression tests. A plan follows the strategy, or explains why it departs from it, and adds the details of one release. Small teams often keep both in one document. ## How is the STLC different from the SDLC? The software development life cycle (SDLC) covers all the work of building software, from requirements to release and maintenance. The STLC covers only the testing work, and it runs inside the SDLC. The ISTQB syllabus treats each test level, e.g. [acceptance testing](https://specstory.com/learning/testing/acceptance-testing), as its own run of the test process. It also says that each development activity should have a matching test activity, e.g. a review of the requirements while they are written. The SDLC model sets the shape of the STLC. In a sequential model, e.g. waterfall, test execution waits until the code is finished. In iterative and agile models, each iteration runs a short version of the whole cycle, with lighter documents and more [test automation](https://specstory.com/learning/testing/test-automation). With continuous integration and delivery ([CI/CD](https://specstory.com/learning/ci-cd/ci-cd)), a pipeline runs the automated part of test execution on each change. ## FAQs ### What are entry criteria in testing? Entry criteria in testing are the conditions a test phase or task needs before it can start, e.g. a build that passes its smoke test. They are the starting counterpart of exit criteria, and agile teams often call them the definition of ready. ### Does agile testing follow the STLC? Agile testing follows the activities of the STLC, but in short cycles instead of one long sequence. Each iteration runs its own small cycle, with light documents and more automated checks. The exit criteria are often written into the team's definition of done. ### What is a test completion report? A test completion report, also called a test summary report, is the summary a test lead writes at test closure. It says whether testing met the plan and its exit criteria, and it lists the defects and risks still open. ### Who owns each phase of the STLC? Ownership of each STLC phase usually follows two roles. A test lead in the test management role owns planning and closure. Testers, often QA engineers, own the other four phases, and one person can hold both roles. --- Source: [What is the STLC? | Software testing life cycle | SpecStory](https://specstory.com/learning/testing/software-testing-life-cycle)