The software testing life cycle (STLC) is the process a team follows to plan testing, design tests, prepare the environment, execute checks, manage defects, and evaluate the results. Its purpose is to give stakeholders evidence about product quality and release risk. It cannot prove that software has no defects.
STLC is part of the broader software development life cycle (SDLC) . Testing can begin while requirements are still being discussed and continue through development and after release. The six phases below are a useful framework, but teams may overlap, repeat, or rename them.
The six phases of STLC at a glance
|
Phase |
Main question |
Typical work |
Output |
|---|---|---|---|
|
1. Requirement analysis |
What should be tested? |
Review requirements, risks, and acceptance criteria |
Testable requirements and initial coverage map |
|
2. Test planning |
How will we test it? |
Set scope, priorities, people, schedule, and exit criteria |
Test plan or sprint test approach |
|
3. Test case design |
Which checks will show whether it works? |
Design scenarios, cases, and data |
Reviewed tests and requirement traceability |
|
4. Test environment setup |
Where and with what data will tests run? |
Configure systems, access, devices, and data |
Ready environment and smoke-check result |
|
5. Test execution |
What happened when we tested? |
Run tests, report defects, retest fixes, assess risk |
Results, defect records, and coverage status |
|
6. Test closure |
What have we learned, and what remains? |
Summarize results and unresolved risks |
Test summary and reusable test assets |
Quick example: For a checkout change, a tester checks whether the requirements specify supported payment methods and failure messages, plans coverage for the highest-risk purchases, designs successful and declined-payment scenarios, prepares a payment sandbox, executes the tests, then reports results and remaining risks. The team may revisit test design as soon as a new edge case appears.
What are entry and exit criteria in STLC?
Entry criteria are the conditions needed to start an activity effectively. Exit criteria are the conditions used to decide whether it is complete enough to move forward. They should be agreed in planning and adjusted when requirements or risks change.
For example, test execution might require an available build, working credentials, a stable environment, and approved test data. Its exit criteria might include execution of all release-critical tests, review of unresolved high-severity defects, and a documented decision about residual risk. A failed exit criterion does not automatically prohibit release; it means the release owner needs an explicit, informed decision.
1. Requirement analysis
The QA team reads user stories, specifications, designs, and acceptance criteria to identify what can be verified. Testers ask about vague behavior, missing error states, access rules, and non-functional needs such as performance and accessibility. They collaborate with product owners, developers, and other stakeholders while changes are still inexpensive to discuss.
For the checkout example, “the payment should work” is insufficient. A testable requirement says which methods are supported, what happens after a decline, and whether a failed attempt creates an order. A requirement traceability matrix or a lightweight story-to-test mapping can make gaps visible.
Typical output: clarified acceptance criteria, a list of risks and questions, and a first mapping of requirements to tests.
Move on when: the team can describe expected behavior well enough to plan meaningful tests; open questions are tracked.
2. Test planning
A test plan defines scope, priorities, responsibilities, environments, test levels, timing, and how results will be reported. It also says what will not be covered in this cycle and why. A small Agile team may keep this in a sprint ticket; a regulated or complex release may need a formal document.
Choose checks based on risk. A payment authorization path may justify API, integration, and end-to-end tests, while a minor copy change may need a focused review. Developers commonly own unit tests; integration and system testing can be shared according to the team's setup. For a deeper look at the options, see types of software testing and what software testing involves .
Typical output: a test plan or sprint-level approach, resource estimates, priorities, and entry and exit criteria.
Move on when: stakeholders understand what evidence the team intends to collect and the principal gaps in coverage.
3. Test case design
Turn requirements and risks into test scenarios with inputs, expected results, and enough context to reproduce a failure. Include normal paths, boundaries, invalid inputs, permissions, and relevant integrations. Prepare data without copying sensitive production information into an unsafe test environment.
For checkout, one case could be: Given a valid cart and an approved sandbox card, when the customer confirms payment, then exactly one order is created and a confirmation is shown. Another should cover a decline, retry, or interrupted request. Link each case to its requirement where traceability matters, and review cases for gaps and duplication. Complete coverage of every possible input is generally impractical; prioritize important risks rather than promising “100% coverage.”
Typical output: scenarios, test cases or automated checks, data needs, and an updated coverage map.
Move on when: the important behaviors have clear expected outcomes and reviewers have addressed major gaps.
4. Test environment setup
Prepare the application build, devices or browsers, connected services, permissions, configuration, and test data. The environment should represent the production behavior relevant to the test, though it need not duplicate every production detail. For payment testing, use an approved sandbox and controlled data.
Run a brief smoke check before full execution: can testers sign in, create a cart, reach checkout, and observe results? Record environment versions so failures can be reproduced. Review software testing tools and QA tools when selecting tools for test management, automation, or defect tracking.
Typical output: a configured environment, available data and accounts, and a smoke-check result.
Move on when: critical dependencies work and testers can reliably run their checks.
5. Test execution and defect management
Run the planned manual and automated checks, compare actual behavior with expected behavior, and record results. A useful defect report identifies the build and environment, steps to reproduce, expected and actual results, and supporting evidence. The team triages impact and urgency, then retests fixes and runs relevant regression checks.
If a checkout request times out and creates two orders, the team should record the defect, investigate whether retry behavior is involved, and test the fix alongside nearby order flows. A failed test may also signal a data or environment issue; investigate before labeling every failure an application defect.
Typical output: pass/fail and blocked results, defect records, retest status, and a view of remaining risk.
Move on when: the agreed exit criteria have been evaluated and outstanding issues are visible to decision-makers.
6. Test closure
Summarize what was tested, what passed, what remains untested, and which defects are open. Keep the evidence and test assets useful for the next cycle. A retrospective can identify flaky checks, slow environment setup, or requirements that repeatedly caused confusion.
A concise checkout test summary could say that all critical purchase paths passed on the release candidate, one low-impact display issue remains, and a particular payment provider's outage behavior was not tested. The product or release owner can then make a decision with those limitations in view. Closure marks the end of a testing cycle; it does not mean the product will never be tested again.
Typical output: a test summary, documented open risks, archived results, and follow-up actions.
STLC vs. SDLC: What is the difference?
|
Aspect |
STLC |
SDLC |
|---|---|---|
|
Scope |
Testing activities and evidence about quality |
The broader process of planning, building, delivering, and maintaining software |
|
Main work |
Analyze, plan, design, set up, execute, and assess tests |
Define requirements, design, implement, test, deploy, and maintain |
|
People involved |
Testers, developers, product owners, and other reviewers |
The full product and engineering team |
|
Outputs |
Test cases, results, defect records, and quality or risk summaries |
Working software and supporting product artifacts |
|
Relationship |
Operates within and alongside development work |
Includes testing as one of its ongoing concerns |
STLC is not something that must wait until coding finishes. Testers can review requirements and design tests while developers implement a feature. Read more about software engineering and what software developers do for the wider context.
How STLC works in Agile and DevOps teams
In a sequential project, the phases may look like distinct handoffs. In Agile work, the same activities usually recur for each story or sprint. A team can analyze a story on Monday, design tests while it is coded, run automated checks on every change, and close the story only after discussing the results. Continuous integration helps surface failures quickly; human review still matters for unclear requirements, usability, and risk decisions.
Automation belongs where repeatability and feedback justify its maintenance cost. Unit and API checks often provide fast feedback; a smaller set of end-to-end checks covers key user journeys. Tools such as Selenium IDE may help with particular browser testing tasks, but the choice of tool follows the test objective. For an interview-oriented recap, see software testing interview questions and answers and Selenium interview questions .
Common STLC mistakes and how to avoid them
|
Mistake |
Better approach |
|---|---|
|
Waiting for a finished build before discussing testing |
Review requirements and risks as soon as a change is proposed |
|
Treating the six phases as rigid gates |
Repeat phases when code, requirements, or evidence changes |
|
Counting test cases as a substitute for coverage |
Map important risks and requirements to checks |
|
Copying production data into a test system without safeguards |
Use synthetic or appropriately protected data |
|
Closing testing because every scripted test ran |
Report blocked checks, open defects, and untested risks |
Conclusion
The six STLC phases help a team turn requirements into useful evidence: what was checked, what failed, what remains uncertain, and what to improve next time. Use the phases as a repeatable guide, adapt their formality to the project, and make release risks visible.
People are also reading:
![What is Waterfall Model? [Phases, Pros, & Cons]](https://storage.googleapis.com/techgeekbuzz/media/new_post_images/Waterfall_Model.webp)
