As testers, we tend to follow various strategies and approaches to aim for optimum quality. But one process that is really interesting is the software testing life cycle (STLC). It is a process where the tester’s end goal is to efficiently meet the software quality standards. The steps within the STLC are six systematic approaches: requirement analysis, test planning, test case development, environment setup, test execution and test cycle closure. You may already be using a majority of these steps within your team! The STLC allows us as testers to shift left in the development lifecycle as it allows one to discover requirements, test ideas and formulate test scenarios.

In this blog, I will take you from the very basics of the STLC and its benefits, discuss its various phases, and walk you through the differences between STLC and SDLC. Let’s deep dive into it then! 💪

Benefits of Software Testing Life Cycle (STLC)

Some of the STLC benefits include the following:

• Increased consistency and effectiveness as project requirements are analysed.
• Clear and defines goals for the product under test, which helps track the project process much easier.
• The confidence in each feature being passed testing, before additional features are added.
• Tests to be designed in a meaningful manner.
• Specifications are much clearer which in turn helps the entire team too.
• It’s a systematic approach that allows uncovering bugs/defects in the product much faster.

Phases of Software Testing Life Cycle (STLC)

Phase 1: Requirement Analysis

In the first phase, the STLC team understands the feature requirements, mainly what is there to be a tester? If necessary, the testing teams can also consult at this point with stakeholders to gain more clarity on the requirements. The requirements can be functional/non-functional and the decision to automate testing is also evaluated at this point.

• Entry Criteria: client requirements, acceptance criteria, and intended product architecture to be documented.
• Exit Criteria: aim for a requirement traceability matrix (RTM) and decision of automation.

Phase 2: Test Planning

This phase includes a test strategy being implemented and defined in the testing plan. Also, the effort and cost of the testing team are estimated at this stage. This stage will only commence once the requirement gathering is completed.

• Entry Criteria: report the test strategy being used.
• Exit Criteria: have an approval on the test plan ( risks and costs).

Phase 3: Test Case Development

During this phase, test cases are created. Each case defines test inputs (e.g. data), procedures, execution conditions, and anticipated results. Test cases should be transparent, efficient, and adaptable. Once all test cases are created, test coverage should be 100%. Any necessary automation scripts are also created during this phase.

• Entry Criteria: approval of timelines to execute the test plan.
• Exit Criteria: approval of test cases and automation scripts if being used.

Phase 4: Test Environment Setup

In the fourth phase, a QA/Testing environment is configured and deployed to allow testers to test the feature. Once the environments are successfully deployed, smoke testing can be performed to ensure the environment is working with the intended functionality and would also provide confidence in testing the new feature.

• Entry Criteria: have a system design and project architecture defined.
• Exit Criteria: have a working QA/Testing environment set up to run test cases.

Phase 5: Test Execution

In the fifth stage, the test execution gets started as the environment is successfully set up. The test cases generated at phase three are put into action here. Your expected results can be used to compare the actual results. The actual results could also be used as a baseline. You can also report back all your interesting findings such as bugs reports to the development teams.

• Entry Criteria: have all the previous steps completed especially the exit criteria.
• Exit Criteria: test execution and results to be documented to report them back.

Phase 6: Test Cycle Closure

In the last stage of the STLC, a test result report is generated. The report should contain the entire process of testing the new requirement such as the analysis between the expected outcome and the actual outcome, whether the objectives were met or not, the time taken to test the feature, costs, test coverage and the most important thing of all — whether you found any defects and details about it.

• Entry Criteria: test results and logging from all previous phases.
• Exit Criteria: delivered planned deliverables and approved test closure test summary report.

STLC vs. SDLC: How Do They Differ?

Although the STLC and SDLC (Software Development Life Cycle) might seem related, they are different in their own nature. They both have different aims and guidelines. Something quite interesting is that STLC phases can be performed in the phases of SDLC. SDLC is related to software development and STLC is related to software testing. STLC is a segment/subset/part of SDLC. The activities in both lifecycles are executed one after the other.

Another difference I can point out between both approaches is that with SDLC the primary goal is to collect the client requirements and create the features accordingly. However, STLC’s goals are to generate tests that adapt to the requirements and verify that the features meet the requirements.

The goal of SDLC is to complete a successful software development with good quality software, whereas STLC aims to complete successful software testing activities and making the software defect free. Both STLC and SDLC phases have entry and exit criteria to be fulfilled before entering or leaving a phase as mentioned above.

In both of these approaches, you need your stakeholders such as DevOps, testing team, Product owners, Business analysts and developers. Full cooperation from the team means you can verify the requirements are defined accurately, tests are relevant, and the results are accurate too!

When to Stop Testing?

This is a very interesting question, it’s a question that gets asked around a lot too. Testing should be stopped when it meets the exit criteria put in the test plan. Test managers/lead, clients and respective stakeholders will consider all the above and similar other factors to decide when to stop.

The Importance of Reporting

When you complete a release, you have release notes generated, in the same way when you complete STLC phases you generate a test report. This report will highlight the testing outcomes, evaluations and be used as a document to aid confidence in whether to release the application or not. It is important not to generate this report and feel like the “job is done”, but it is also vital that you learn from this and see how the test strategies used this time could be implemented/improved in the future. Use it like a lesson learned. At the end of the day we are aiming for a good quality product, therefore aim for removing bottlenecks and continue with the best practices for next time.

TL;DR

Whether your team is going for a SDLC approach or STLC approach, you should understand how testing and quality fits into the phases. You may feel more comfortable with one approach or another, but the aim at the end of the day for both approaches is to deliver a good quality product with appropriate testing coverage and confidence. I myself have used a bit of both approaches in the past, however it would be quite interesting to follow STLC rigorously and understand if one can unveil some different bugs/findings.

It is not a good idea or efficient to identify errors in the last stage of SDLC and there are other actions to focus on. Spending too much time testing bug fixes also leads to obstruction of efficiency and does not add much value.

The use of efficient time and resources is something that eases the testing process, therefore following the STLC process, you will notice speedy bug fixes as well as product quality enhancements. Which in turn leaves you with a happy customers, positive company reputation and increased ROI 🚀