What is Software Testing Life Cycle (STLC)

Definition of the STLC and its role in the Software Development Life Cycle (SDLC)

What is STLC (Software Testing Life Cycle)

The Software Testing Life Cycle (STLC) is a sequence of specific actions performed during the testing process to ensure that the software quality objectives are met. The STLC includes both verification and validation. Contrary to popular belief, software testing is not just a separate activity. It consists of a series of methodological activities to help certify your software product.

The STLC is a high-quality strategy directly associated with and part of the Software Development Life Cycle (SDLC), which in turn is a framework with 6 core principles:

1. Requirements analysis;
2. Planning;
3. Engineering and design;
4. Software development;
5. Testing;
6. Deployment.

In simple terms, the SDLC is a cycle where actions at each stage are reflected in subsequent stages. 

The STLC also has its stages and most closely intersects with the SDLC at the fifth stage, which I’d describe below.

What to use the STLC for

Since we can explain STLC as a set of testing measures, we can assume that it includes various stages, such as planning, control, implementation, standardization, and so on. All this leads us to the fact that the STLC is needed not only to test the developed product but also for the following:

• Removing its shortcomings during the earliest and most profitable stage of development;
• Increasing the quality and transparency of the development process;
• Maximizing control over the quality of the product being developed at all stages of the SDLC;
• Figuring out how using the testing life cycle in Agile, Scrum, SAFe, etc. influences their application;
• Delivering a quality product not only to the Client but also to the Users.

The role of the STLC in the SDLC

As mentioned earlier, the Software Testing Life Cycle and the Software Development Life Cycle are closely related to each other, but they simultaneously pursue different tasks of the same goal, namely:

• collecting the requirements in the desired form and developing the declared functionality (as for the SDLC);
• analyzing requirements, assisting the client and the development team, and confirming the quality of the implemented functionality (as for the STLC).

The overall goal is client satisfaction and achieving the highest possible score at the Verification and Validation stages.

The role of the STLC in the SDLC can be represented with a double line graph:

Where the SDLC and the STLC lines move in parallel for most of the project but begin to converge rapidly during the software development phase with deep synchronization during the SDLC Test phase. This graph is relevant to many different types of projects, not just large or independent ones, and will remain the same for the implementation of a task within a project and reverse for a project with a huge number of iterations (but in this case, the lines will diverge and converge more often).

Entry and Exit Criteria in STLC

The testing cycle is divided into different stages, and each has its own set of entry and exit criteria. The criteria are related to some activities and deliverables.

Entry Criteria

A collection of conditions or goals that must be met to create an appropriate and favourable testing environment are known as entry criteria. Entry criteria, which are finalised and chosen after a comprehensive analysis of the software and business requirements, guarantee the accuracy of the testing process, and ignoring them can lower the process’s quality.

Exit Criteria

The exit criteria describe all of the requirements that must be met before testing in a particular phase can be completed. All deliverables should be finished in order to satisfy the exit criteria. There should be no flaws, mistakes, or bugs, and all high intensity and high priority mistakes have been corrected.

What are the STLС phases

The STLC has several interconnected phases and is generally very similar to the SDLC system. These phases are sequential and are called:

1. Requirement Analysis;
2. Test Planning;
3. Test Case Development;
4. Test Environment Setup;
5. Test Execution;
6. Test Cycle Closure.

Let’s take a closer look at each of them.

Requirement Analysis

Requirements analysis is one of the most important phases because this is when you can fix project flaws almost completely free of charge. The requirements analysis phase also identifies the potential need for automated testing and allows making economic calculations of labor costs based on the project estimation. This is also when the Entry Criteria and the Exit Criteria are discussed and documented.

Entry and Exit Criteria in software testing are necessary for all levels of the STLC. Entry Criteria define the prerequisites that must be met before you start the testing, while Exit Criteria define the prerequisites for concluding it. Ideally, you don’t proceed to the next testing stage until every Exit Criterion for the previous one is met.

Now imagine that an edtech startup company is developing an online learning platform for K-12 students to be launched in six months. The platform will include various types of educational content, such as videos, quizzes, and interactive exercises, and will be accessible on desktop and mobile devices.

The edtech startup conducts market research and user surveys to identify the target audience and their preferences and needs. They discover that the majority of K-12 students prefer interactive and gamified content, and that teachers prefer content that aligns with their curriculum standards and provides analytics and progress tracking features.

Based on these findings, the company defines the requirements for the platform, including content types, curriculum standards, and the user interface and experience. For example, they decide to include animated videos, quiz games, and virtual labs, and to align them with the common core standards in science and math. They also design the user interface to be intuitive and engaging, with colorful graphics and sound effects, and to include features for tracking progress, communicating with teachers, and accessing learning resources.

Test Planning

At this phase, a test plan is formed. This is the concretization of all phases of the testing itself, timing, participants, and responsibilities. As a result of this, we receive data on:

• the participants and their roles in testing;
• the necessary testing tools;
• the necessary test environment.

Back to our example, this is when the testing team reviews the requirements and defines the testing objectives, strategies, and criteria. They decide to focus on functional, usability, and performance testing, and to use both manual and automated testing approaches.

They identify the testing types, such as functional, usability, performance, security, and accessibility testing, and plan the testing schedule, resources, and tools. For example, they decide to use JIRA for test case management, Selenium for automation testing, and LoadRunner for performance testing. They also allocate specific testing tasks to individual team members and set up regular testing meetings and checkpoints.

They also set the quality goals and metrics to track and measure the testing progress and results. For example, they set a goal of achieving a 95% pass rate for functional testing, a 80% satisfaction rate for usability testing, and a 3-second load time for each page.

Test Case Development

Test development implies using manual and automated testing to achieve full coverage of the software’s functionality and features, with the process being based on the requirements set up beforehand. More often than not, the test cases carried out using testing automation are written separately, since the cases for manual testing are described in the form of cheat sheets. Each has its own Test Case Life Cycle, which encompasses its creation, verification, and rework.

The testing team from our example creates test cases for each testing type, based on the requirements and the testing objectives. For example, they create test cases for each type of interactive content, such as videos, quizzes, and labs, and test them for functionality, usability, and performance.

They design the test scenarios, inputs, expected outputs, and the test environment and data needed for each test case. For example, they create different scenarios for a quiz game, such as single-player mode, multiplayer mode, and time-limited mode, and test them with different input parameters and expected outcomes. They also create a test environment that simulates different user devices and networks, such as desktop, mobile, and 3G, and test the platform under various conditions.

They also develop the test scripts and automate the testing process wherever possible to increase efficiency and reduce manual effort. For example, they use Selenium to create automated scripts for regression testing, and to test the functionality and compatibility of the platform with different web browsers and operating systems.

Test Environment Setup

The test plan makes it clear which test environment should be used. At this STLC phase, operating systems and virtual machines are configured, testing tools like Selenium, Katalon Studio, and the project’s test environment and databases are deployed. We also make requests to DevOps and Admins if support is needed.

In our example, the testing team sets up the test environment, which includes the hardware, software, network, and data needed for testing. For instance, they set up a testing server that replicates the production environment, and install the necessary software and drivers for the testing tools and frameworks used.

They also configure the testing tools and integrate them with the development environment to enable continuous testing and feedback. For example, they use JIRA to track defects and issues, and to link them to specific test cases and requirements. They also use Jenkins to automate the testing process and to trigger alerts and notifications for failed tests.

Test Execution

Tests are performed based on ready-made test documentation and a correctly configured test environment. All test results are recorded in the Test Management System. Negatively passed tests, where the actual result differs from the one expected, are recorded as errors and transferred to the development team for script revision with subsequent rechecking after correction.

The testing team from the example executes the test cases according to the testing plan and the testing schedule. Let’s say they conduct functional testing first, then usability testing, and finally performance testing. They analyze the test results, identify defects and issues, and report them to the development team for resolution. In the end, they find that some quiz questions are not displayed properly.

Test Cycle Closure

The last phase of the STLC is the final generation of testing reports for the client. These should include the time spent, the percentage of defects found to positive test results, the total number of errors found and fixed. As far as the testing department is concerned, this is the moment for analyzing its work, summing up the results, analyzing its productivity, and the opportunity to make suggestions for improving the quality of testing.

And the final part of our example. The development team fixes the defects and issues reported by the testing team, and re-runs the relevant test cases to verify the fixes. They modify the quiz code to correctly display the questions, and re-test it with the same test cases as before.

The testing team then conducts a final regression testing to ensure that the fixes have not introduced any new defects, and that the platform meets the quality goals and metrics set earlier. They run all the test cases again, including the ones that were previously failed or blocked, and check if they all pass this time.

Once that is done, the testing team generates a test summary report, which includes all the testing activities, their results, and recommendations, and presents it to the management and stakeholders. The report can summarize the test execution and results for each testing type, and provide suggestions for further improvements and enhancements.

Finally, the edtech startup company launches the platform to the market and monitors its performance and feedback from users and teachers. They also plan for the next testing cycle, which includes new features and updates based on the user feedback and market trends. For example, they may want to add a new feature for personalized learning paths, and plan for a new testing cycle with the new functionality in mind.

STLC Phases and Their Entry and Exit Criteria

STLS Phase	Entry Criteria	Exit Criteria	Deliverables
Requirement Analysis	Functional and non functional requirements documentation Defined acceptance criteria Application architecture documentation	Signed off requirement traceability matrix Test automation feasibility report signed off by the client	Requirement traceability matrix Automation feasibility report
Test Planning	Requirements documentation Requirement traceability matrix Test automation feasibility documentation	Approved test plan and strategy document Signed off effort estimation documentation	Test plan and strategy documentation Effort estimation documentation
Test Case Development	Requirements documentation Requirement traceability matrix and test plan Automation analysis report	Reviewed and signed test cases and scripts Reviewed and signed test data	Test cases and scripts Test data
Test Environment Setup	System design and architecture documentation Environment setup plan	Working environment setup is following the plan and checklist Completed test data setupSuccessful smoke test	Test data set and ready environment Smoke test results
Test Execution	Baselined requirement traceability matrix Test plan Test case and scripts Test environment Completed test data setup Unit and Integration test reports	Completed planned tests Logged and tracked defects to closure	Completed requirement traceability matrix and execution status Updated test cases and their results Defect reports
Test Cycle Closure	Completed testing Test results Available defect logs	Test closure report signed off by client	Test closure report Test metrics

Changes In Standard STLC Cycle

The example above is a sort of perfect scenario for the software testing lifecycle. But sometimes there are situations when variations in  STLC are unavoidable. Let’s look at some possible cases where these variations can take place.

Agile Development

In an Agile environment, the testing process may not follow the standard STLC sequence, which is designed for Waterfall development. Agile development emphasizes flexibility, iteration, and quick feedback, so testing is often done in parallel with development rather than in sequential stages. Test planning, case development, and execution may all happen simultaneously with development sprints, and the cycle may be more fluid and iterative.

Emergency Patches 

In some cases, a software application may require an emergency patch or hotfix to fix a critical issue. In such cases, the standard STLC sequence may need to be compressed or bypassed to quickly deliver the fix. For example, the test planning and case development phases may be skipped, and the testing team may need to focus solely on executing pre-existing test cases to confirm that the patch has resolved the issue.

Legacy Systems

In an organization with legacy systems, the STLC sequence may not be followed strictly due to the technical constraints of the older systems. The environment setup phase, in particular, may be difficult or impossible to complete, as the legacy systems may not be compatible with modern testing tools and techniques. In such cases, the testing team may need to rely on manual testing or older testing tools, which may require a different approach to the testing process as a whole.

Outsourced Testing

If an organization outsources its testing to a third-party vendor, the testing process may not follow the standard STLC sequence. The vendor may have its own testing methodologies and tools, which may differ from the organization’s standard approach. The vendor may also need to adapt the testing process to accommodate differences in infrastructure, culture, and communication channels between the vendor and the organization. In such cases, the organization may need to establish clear expectations and guidelines for the testing process to ensure that the vendor’s approach aligns with the organization’s quality standards.

Continuous Testing

In a DevOps environment, testing may be automated and integrated into the development process through continuous testing. Continuous testing involves running automated tests on every code change, commit, or build to detect defects and regressions as early as possible in the development cycle. Continuous testing may blur the lines between the different phases of the STLC and require a different approach to test planning, case development, and execution. In such cases, the testing team may need to focus on creating reusable automated tests and ensuring that the testing process is integrated seamlessly into the development pipeline.

The Role of Automation in STLC

Test automation is the best way to improve the effectiveness, efficiency, and coverage of your software testing. An automated testing tool can run pre-recorded and predefined actions, compare the results to expected behaviour, and report the result of these manual tests to a test engineer. Once automated tests are created, they can be readily repeated and extended to accomplish tasks that manual testing cannot. As a result, automated software testing has emerged as a critical component of successful development projects.

Benefits of automated testing:

• Saves time and money. Once created, automated tests can be run indefinitely at no extra cost and are significantly faster than manual tests. The time it takes to perform repetitive tests can be reduced from days to hours using automated software testing. It’s a time savings method that immediately translates to cost savings;
• Increases test coverage. Automated software testing can help improve software quality by increasing the complexity and scope of tests. Longer tests can even be performed on numerous computers with varying configurations. During each test run, test automation can easily perform thousands of different complex test cases, providing coverage that manual tests cannot provide;
• Improves accuracy. Automated tests execute the same steps exactly every time and never fail to record detailed results. Testers who are no longer subjected to repetitive manual tests have more time to develop new automated software tests and deal with complicated features;
• More possibilities. Automated testing can mimic the interactions of tens, hundreds, or thousands of virtual users via a network, software, or web apps;
• Helps developers and testers. Developers can use shared automated tests to catch problems rapidly before sending them to QA. When source code changes are checked in, tests can run automatically and inform the team or the developer if they fail.

Alternative to a Sequential STLC

Parallel testing is some kind of opposite to sequential testing. Parallel testing is an automated test process that allows developers and testers to run multiple tests against various real device variations and browser configurations at the same time. Parallel testing aims to address time constraints by spreading tests equally throughout the resources available.

For example, if 20 test cases take 100 minutes to complete, 10 parallel operations could run 2 test cases each, reducing total testing time to 10 minutes. If you have enough resources, say 20 real mobile devices and browsers for parallel execution of 20 test cases, you should be able to greatly reduce the runtime to 5 minutes.

Benefits of parallel testing:

• Speed. Parallel testing allows you to divide your time investment by the number of environments;
• Cost-efficiency. Maintenance is no longer a hassle: you simply lease the necessary testing environment, which is always up to date. Moreover, cloud-based testing grids enable you to run tests at high concurrency, lowering the cost per test significantly;
• Better coverage. You can test your application on as many platform-device-browser combinations as possible to ensure that no bugs are left;
• Improved testing practices. You can test more by testing at high speeds. This allows your QA team to improve their testing practices and find bugs faster.

Conclusion

Now that we know what the STLC in software testing is and what it is for, we can say what the graph of interaction between the STLC and the SDLC will look like with full certainty:

The fact that the closest point of convergence happens during the “Test Execution” stage is direct proof of the importance of testing in software development. At the same time, we see that some phases of the STLC and the SDLC are very similar to each other both in name and in meaning, which suggests that the Software Testing Life Cycle and the Software Development Life Cycle are inevitably linked at all stages of software product development.