STLC (Software Testing Life Cycle) – Overview & Phases

The software testing life cycle (STLC) is a set of standards and best practices for testing software applications. It guides software testers through the testing process and promotes a consistent and comprehensive method for quality assurance practices.

This systematic approach to testing ensures quality standards are met by giving testing teams a framework for planning and executing tests. It typically consists of six phases. However, some teams choose to combine steps, split them, or even add or remove some phases depending on their needs.

Why the software testing life cycle is important

Similar to the Software Development Life Cycle, the software testing life cycle exists to help teams do their best work in an organized and consistent manner. It supports getting everyone on the same page and gives guidelines for progressing the work. Here are some of the ways the STLC helps teams:

• Teams have a better structure for aligning with the testing goals, scope, and project deliverables.
• Having a framework helps managers plan timelines and budgets for testing projects.
• Organized processes ensure the overall quality of the product.
• This systematic approach helps speed the testing process by enabling teams to identify and resolve bugs faster.

Who uses the software testing life cycle?

Typically, the testing team uses the software testing life cycle. However, depending on team structure, others connected with the product will use it too, such as engineers, testers, and product or project managers. For agile teams using the STLC, their testing might involve a wide range of folks, from developers to technical support. Sometimes, development and ops teams find it advantageous to use when when setting up testing environments or reviewing defect reports.

STLC vs SDLC

Both cycles relate to the software development process, but their goals differ. Whereas the SDLC begins with gathering and creating requirements, the STLC starts by analyzing those requirements and then planning and executing tests to ensure the software functions in ways that meet those requirements.

The software testing life cycle can be performed as part of the software development life cycle or undertaken in parallel. The SDLC is an all-encompassing end-to-end process for building the software, which includes design, development, testing, and more. However, the STLC solely focuses on testing. So while testing is a phase within the SDLC, the STLC examines what is required to complete the testing phases.

Entry and exit criteria

There are entry and exit criteria for every phase of the STLC. The entry criteria are specific conditions, documents, or artifacts required before beginning a phase. In contrast, exit criteria are the conditions that must be met before a tester can proceed to the next phase of the software testing life cycle.

The STLC phases

The software testing life cycle follows six phases:

1. Requirement analysis
2. Test planning
3. Test design
4. Environment setup
5. Test execution
6. Test cycle closure (reporting)

1. Requirement analysis

Development projects typically start with a set of software requirements that specify what the business expects from the software application. During this software testing life cycle phase, the business requirements are analyzed to determine which requirements are testable. The testing team then assesses the testable requirements and works cross-functionally to determine how to test each one. Reviewing occurs during brainstorming sessions, team meetings, and asynchronous communication through team collaboration tools.

Having verified the requirements documents in this phase, the testing team can prepare test artifacts such as the test strategy and plan.

Entry criteria: Requirements, acceptance criteria, and product architecture have been documented.

Exit criteria: Requirements have been verified, and the test lead thoroughly understands which requirements are testable and which are not.

Learn more about requirement analysis in STLC.

2. Test planning

This second phase of the software testing life cycle is considered the most important because it determines what happens in the remaining stages. Test planning takes learnings from the previous phase to create and document the test strategy.

A testing team member creates the test strategy and test plan documents during the planning phase. Other team members can also contribute during this phase, but a senior team member usually owns it. The test plan is a comprehensive document that specifies who is involved, how testing will be done, the scope of work, timelines, and much more.

Entry criteria: Requirements analysis is complete.

Exit criteria: The test plan is completed and includes cost and time estimates.

3. Test design

After the test plan, it’s time to create the test cases. Also known as the test case development phase, the test design phase is when the testing team writes manual test cases and creates automated test scripts.

Test team members can review their peers’ test cases and get approval for their own. This phase includes the necessary work for storing the test cases in a repository such as a test case management tool.

Once the test cases are written, a team lead can review and approve them. Making each test case identifiable and repeatable is essential because tests may need to be re-run as new functionality is introduced over time.

Entry criteria: The test plan has been approved.

Exit criteria: Test cases and test scripts have been written, and test data is created and available for emulating a realistic scenario for each test case.

4. Environment setup

The test environment is the setting where the testing takes place. This phase often involves input from the development or ops team, as they often build and maintain the various environments. It’s important to have testing environments that match those of your users. For example, if your test group is mainly Android users, you’ll need to be able to test on the Android platform. Similarly, if your users are PC users, make sure you can test on Windows.

After setting up the environment, the development or ops team will need to help the testing team access it through an installation or login process. Depending on your product, you might have several testing environments to set up and grant your team access.

Entry criteria: The system design and product architecture are understood.

Exit criteria: The test environment is ready for use, and an initial smoke test has been run and reported.

5. Test execution

The test execution phase is when testing takes place. It is when testers run test cases, report defects, and update the requirements traceability matrix.

As developers fix reported defects, testers can retest and verify bug fixes. Leveraging both manual and automated tests is essential during this phase to ensure good test coverage. This is sometimes the most chaotic phase of the STLC because the number of tests to run can quickly mount up. Therefore, having the right tools and systems in place to support staying organized, productive, and efficient is critical to this part of the STLC.

Entry criteria: All exit criteria from previous steps.

Exit criteria: The test execution report, defect report, and requirements traceability matrix are available.

6. Test closure

In this final phase of the software development life cycle, the test lead prepares a test closure report showing test coverage and reported defects, which is then shared with the overall product team. The purpose of the test closure report is to summarize the results. A thorough test closure report will include details like the percentage of failed tests, the total number of defects logged, and more.

As a final step of the test closure phase, the testing team should archive test data and other artifacts for future use. From here, the software team plans for how they will release and support the software.

Entry criteria: Test results and all reports and logs are available from previous phases.

Exit criteria: Test lead sends test closure report and test metrics.

Agile software testing life cycle phases

The testing life cycle will look slightly different when following the agile methodology. Agile promotes rapid iterations and flexibility, so with this in mind, many of the robust documents we see in the traditional software testing life cycle are skipped.

Just like traditional testing teams, agile teams leverage a combination of manual testing and automated testing. Agile teams might have dedicated testers working alongside the developers, or the developers might run the tests themselves. It mostly depends on the team size and structure. Other non-technical roles are occasionally brought into exploratory testing to help expand the test coverage.

Let’s look at what a testing life cycle might look like for an agile team.

1. Sprint planning

Sprints help software teams take large complex projects and break them into smaller, more manageable work units. The sprint planning session is a predetermined meeting where product managers, developers, and testers discuss the feasibility and scope of work for the next sprint. This is where the team will get an understanding of what exactly needs to be tested.

2. Test case design

Testers determine how they will test the software in this phase. Options include documenting and writing test cases, conducting exploratory testing, or something more lightweight, like a checklist.

3. Test execution

Testing begins once development has concluded and the code is available for testing in the QA environment. The test execution phase looks different across teams and organizations, however, the ultimate goal of this phase is to run and complete tests and report any defects. 

When dedicated QA team members are involved, they may perform their testing when each story has been completed and deployed to the test environment. Often the developer may do a small handover of each story. This allows testing to take place throughout the sprint which means any issues are picked up sooner.

It’s also common for agile teams to have the engineers write unit tests for the code they’ve written. In addition to or instead of a dedicated tester or testing team, this ensures the code changes are constantly being tested as the code is deployed throughout the sprint.

Agile is flexible and constantly moving, so depending on team structure, the testing phase might involve a range of differently skilled people.

4. Regression and deployment

It’s essential to ensure any new changes haven’t negatively impacted existing functionality. Therefore, regression testing is necessary during this closing phase before final verification and deployment.

What happens if you don’t follow the STLC?

Whatever your team structure, it’s important to establish guidelines around how you plan, design, conduct, and report on software testing. By not using the software testing life cycle, you risk wasting time and money and disappointing customers.

If quality assurance is an afterthought, your software will likely have many defects. Bring quality to the forefront by following a set of software testing life cycle phases that work for your team.

Conclusion

Although the software testing life cycle varies across teams and companies, it exists for good reasons. Teams can plan work accurately and it helps set customer expectations on timelines and budgets. It also delivers structure for building a quality assurance program from the ground up. Product owners, engineers, and designers should be familiar with the STLC to work in harmony with their teams. No matter how your team works, the software testing life cycle will align you with your peers and enable a stronger team with higher performance.