The Software Testing Life Cycle (STLC): Phases, Entry and Exit Criteria
Six phases that take testing from a requirement to a signed-off release, with a clear start and finish line for each one.
For QA engineers learning how a testing effort is structured, and leads defining a repeatable process for their team.
What the STLC Gives a Team
The Software Testing Life Cycle is the sequence of phases a testing effort moves through, from reading the requirements to signing off the release. Each phase has a goal, a set of activities, and a deliverable that feeds the next one.
Its real value is in the criteria between phases. Entry criteria say what must be true before a phase starts; exit criteria say what must be true before it ends. Together they give everyone the same answer to "are we ready?" and "are we done?".
The Six Phases
Requirement analysis
Understand what has to be tested and confirm every requirement is testable. Typical activities: Review user stories and acceptance criteria, ask clarifying questions, identify the test types each feature needs.
Test planning
Decide scope, approach, people, schedule, and the entry and exit criteria for every later phase. Typical activities: Define what is in and out of scope, estimate effort, assign owners, set a target date.
Test case design
Turn each requirement into reviewed test cases with clear steps and expected results. Typical activities: Apply design techniques, write or generate cases, prepare test data, review cases with a second person.
Environment setup
Have a build, an environment, and test data that match what the plan says will be tested. Typical activities: Deploy the build, create test accounts and data, confirm access, run a quick smoke check.
Test execution
Run the cases, record results, and log defects with enough detail to fix them. Typical activities: Execute and mark each case, log and track defects, re-test fixes, re-run failures.
Test closure
Summarise what was tested, what was found, and whether the release meets its exit criteria. Typical activities: Write the summary report, record lessons learned, get sign-off, archive results.
Test case design covers the techniques for choosing cases, explained in depth in Test Case Design Techniques. Requirement analysis depends on testable criteria; see the Acceptance Criteria guide.
Entry and Exit Criteria for Every Phase
Use this table as a starting checklist and tune each line to your project. The exit criteria of one phase usually become the entry criteria of the next, which keeps the hand-offs clean.
| Phase | Entry criteria | Exit criteria | Deliverable |
|---|---|---|---|
| Requirement analysis | Requirements or user stories are available | Acceptance criteria are testable and open questions are answered | Agreed, testable requirements |
| Test planning | Requirements are agreed | Plan is reviewed and approved | Test plan |
| Test case design | Plan and scope are approved | Every requirement has reviewed, approved cases | Approved test cases and test data |
| Environment setup | A deployable build exists | Smoke check passes on the target environment | Ready environment, accounts, data |
| Test execution | Approved cases and a ready environment | All cases executed, no open critical defects, agreed pass rate met | Results and defect log |
| Test closure | Execution exit criteria are met | Stakeholders sign off | Test summary report |
Writing good entry criteria
Writing good exit criteria
How the Phases Map to Evaficy Smart Test
Each phase has a home in the platform, with statuses that show where the work stands:
| Phase | Where it happens | Statuses |
|---|---|---|
| Requirement analysis | Requirement custom field on a scenario | Stored with the scenario and restored when it is reopened |
| Test planning | Test Plans (Enterprise): a named set of scenarios with a target date | Draft, Active, Completed |
| Test case design | Scenarios, AI generation, and the validation workflow (Advanced and Enterprise) | Draft, Pending, Approved, Rejected |
| Environment setup | Create Test Run dialog: Environment, Browser, Operating System, Build Version, Start and End Date | Recorded on every run |
| Test execution | Test runs, per-case results, defects, and Re-run Failed | Run: Draft, In progress, Completed, Aborted. Case: Passed, Failed, Blocked, Skipped |
| Test closure | Execution report with PDF export; Test Plan marked Completed | Report per run |
- Test planning: a Test Plan groups the scenarios for a release. Its coverage counts the share of those scenarios with at least one completed test run.
- Test case design: in the validation workflow, a project's Owner, Product Owner, or Tech Lead approves or rejects each case before it is used in a run.
- Environment setup: the run records the environment, browser, operating system, and build version, so results always point to what was actually tested.
- Test execution: Re-run Failed creates a new run named "Re-run: <original name>" containing only the cases that failed, ready for re-testing after a fix.
For the details of each step, see Test Plan Management, The Expert Validation Workflow, and the Test Run Execution guide.
The STLC Inside a Sprint
In agile teams the six phases still happen, on a smaller scale and many times over. Each story moves through its own short cycle within the sprint:
Refinement
Requirement analysis and planning happen while the story is refined: criteria are made testable and the test types are chosen.
During development
Test cases are designed and reviewed while the feature is being built, so they are approved when the build lands.
Ready for QA
Environment setup and execution follow as soon as the build is deployed; failures are logged and re-run after the fix.
Sprint review
Closure is the story's exit criteria in the Definition of Done, plus a release-level summary when the increment ships.
For sprint-level testing tactics, see Agile QA Strategy.
Closing the Cycle Well
A closure report people actually read
Finish with two or three lessons learned, such as a requirement that needed clarifying late or an environment that delayed execution. Those notes improve the entry criteria of the next cycle.
Common Questions
What is the difference between the STLC and the SDLC?
The SDLC covers the whole life of the software: planning, design, development, testing, deployment, and maintenance. The STLC zooms into the testing part and breaks it into its own phases.
Can phases overlap?
Yes, and in agile teams they usually do. Test case design often runs alongside development, and execution of one feature runs while another is still being designed. The entry and exit criteria keep each piece of work clear even when phases overlap.
Who decides the exit criteria?
The QA team proposes them during test planning, and the Product Owner or release owner agrees them. Agreeing them up front makes the final sign-off a quick check.
What happens when exit criteria are not met by the deadline?
The team makes an explicit decision: extend testing, or release with known risks that are written down and accepted by the release owner. Either way, the decision and its reasons go into the closure report.
Key Takeaways
- The STLC has six phases: requirement analysis, test planning, test case design, environment setup, test execution, and test closure.
- Entry criteria define when a phase can start; exit criteria define when it is done.
- Make every criterion checkable, and agree execution exit criteria such as pass rate during planning.
- In agile teams the phases repeat per story inside each sprint.
- Test plans, validation, test runs, and execution reports give each phase a status you can see.
- A closure report leads with the release decision, then the numbers, then lessons for the next cycle.
Run your next testing cycle end to end
Create your free account to design scenarios, run them against a named environment and build, and export the results.
Create your free account