What is the STLC?
What is the STLC?
In the contemporary small-to-medium-sized business world, embracing innovation as a means of differentiating your business from competitors can be the key to sustainable success.
A key area for innovation is software development. Whether looking to streamline the efficiency of your team or improve customer satisfaction, properly identifying and implementing software-based solutions in your IT infrastructure will pay dividends for your company.
The financial gains you can net through understanding tech are well-documented. In fact, a recent study by Deloitte found that small businesses considered “digitally-advanced” earned twice as much revenue per employee, saw four times as much revenue growth from the prior year, and were nearly three times as likely to create jobs as compared to their less tech-forward counterparts.
While you may not have a formal tech background, taking the time to understand the terms and processes that are relevant to any software engagement you embark on will make your presence in meetings more valuable and help you secure the most ideal end product possible.
One process that you can focus on to improve the quality of your contributions to software development projects is the software testing lifecycle (STLC). By understanding this process, you can help any development team you work with to properly ensure that the software product they deliver meets all necessary end-user criteria.
Find a software development company on The Manifest. Use client rating, notable projects, and minimum project size to find the perfect partner for your business.
What is the STLC?
To understand the STLC, you’ll also need to understand software testing. This term refers to the process a development team undertakes to verify that their software deliverable performs as intended.
Several different types of software testing are outlined below:
- Acceptance Testing: Testing to validate that an entire system works properly
- Functional Testing: Using hypothetical scenarios to verify functionality
- Integration Testing: Testing to validate that the software components of a system work properly together
- Performance Testing: Gauging a given system’s functionality under different levels of strain
- Regression Testing: Checking if new features of a system hamper or break its overall functionality
- Unit Testing: Testing to validate that an individual software component works properly
- Usability Testing: Performing activities that an end-user would to ensure the system isn’t overly cumbersome
Even when looking at software testing from this high level, you can see that it is a discipline with many facets that can be applied differently to different software development engagements as needed to produce the ideal software product.
STLC Defined
The term STLC refers to the sequence in which these testing activities come together. Regardless of the actual tests performed, each activity can be grouped into software testing lifecycle phases that in turn make up the overall STLC for a project.
It is important that you understand the STLC as a methodology, as software testing is not a solitary activity. Rather, each component of the STLC must be performed in the proper sequence and with the proper level of dedication so that any bugs with your end product are identified prior to implementation within your IT network.
How is the Software Testing Lifecycle Different From the Software Development Lifecycle?
Before we dive further into the STLC, we must first discuss the difference between this process and the software development lifecycle, or SDLC. While there’s only a one letter difference between the two acronyms, the one letter makes a big difference.
Read on for a definition of each:
- SDLC: The sequential grouping of software development activities to best deliver a software product
- STLC: The sequential grouping of software test activities to best deliver a bug-free software product
Although each life cycle is made up of software activities, the STLC is limited to test activities while the SDLC encompasses the entirety of the software development process. In fact, the activities included in the STLC will also make up the testing portion of your engagement’s SDLC.
Now that you understand the basics of the STLC as well as its place within the SDLC, we can dive deeper into the different phases and requirements of the STLC so you can better understand how the methodology fits into your software projects.
What Do Testing Teams Need to Get Started on STLC Phases?
Before your software test team is ready to embark on the activities enumerated in your STLC, they’ll need information from you and your team to help them define their testing parameters.
By providing accurate, in-depth information to the team, you can enable them to perform the best test management possible throughout the STLC.
Here’s an overview of information your testing team might ask for:
- Entry Criteria: Components of the software solution that must be met before software testing can begin
- Exit Criteria: Testing requirements that must be met before software testing can conclude
- Development Team: Your testing team should be provided with a list of points of contact among the software developers so that any bugs can be fixed promptly if they are unearthed
- Project Managers: Your testing team should also be provided with project manager contact information should they need assistance working with the development team
- Testers: You’ll need to inform the team of what tests will be necessary so they can allocate the proper testing resources to your project
- Metrics: The thresholds that the software must meet to have passed the tests
- List of Deliverables: Any documentation or reports that must be provided as related to the tests performed
- Understanding of Stakeholders: You’ll want to let the team know what parties external to the engagement expect from the final software product so they can perform any tests relevant to these expectations
- Development Methodology: The set of principles guiding the overall development effort
- Agile: A flexible development methodology in which software is developed and released incrementally so that all parties can assess project success over time
- Waterfall: A traditional development methodology in which software is developed and released after all stages of development are complete
- Hybrid: A methodology that borrows concepts from agile and waterfall
Once you provide your software test team with this information, they’ll be ready to start on the first phase of the STLC.
6 Stages of the STLC
As we discussed earlier, the STLC encompasses the entirety of the software testing process, not just the testing itself.
While different software projects will require different tests to be performed, the six phases of the STLC that can be applied to any project are as follow:
- Requirements Analysis
- Test Planning
- Test Case Development and Design
- Test Environment Setup
- Test Execution
- Test Cycle Closure
Understanding each of these six phases and how to apply them within the software testing process of any development projects with which you and your team are involved is crucial to ensuring that any deliverables work properly prior to implementation.
1. Requirements Analysis
Performing a requirements analysis is the first of the phases of STLC. This analysis involves decomposing the end-user needs of a given software into actionable testing requirements.
Based on your requirements analysis, your software test team will build a list of criteria by which they can judge if their deliverable passes or fails the tests they choose to perform. They can also decide which tests are most relevant to project goals.
What Do You Need For a Requirements Analysis?
This step of the process will involve three deliverables:
- Requirements document
- Requirement traceability matrix
- Automation feasibility report
Here’s how you’ll use them to kick off the STLC.
Ideally, others on your software development team will have put together a requirements document that defines the overall goals the software was designed to meet earlier in the software development process.
Another previously-existing document that may be of use to your testing team is the requirement traceability matrix (RTM). The RTM is defined as a document that traces the development path of each of the requirements of a project from kickoff to final implementation.
While this document may not discuss the content of each requirement at as in-depth of a level as the requirements document, it can still provide new context to your software test team. It will include background information such as the requester of each requirement and the business need each requirement is designed to meet.
Both documents can serve as a good basis for your testing team to perform their own requirements analysis. Based on the requirements document, the RTM, and the team’s separate understanding of stakeholder desires, they can set forth acceptance criteria for their testing efforts. This term is synonymous with the aforementioned term exit criteria, referring to the criteria that must be met before testing can conclude.
As the scope of the potential tests to be performed is narrowed down, your testing team may also prepare an automation feasibility report. As its name would lead you to believe, this report will analyze the exit criteria and testing activities to determine if there’s a place for automation within the testing efforts.
Tip: Consider Functionality
In the requirements analysis phase of the STLC, it’s important that your software test team takes functionality into account when setting their exit criteria.
Regardless of its scope, any development project will have software requirements that can be characterized as either functional or non-functional. Functional requirements specify what software should do, whereas non-functional requirements specify how software should perform a certain function.
For instance, imagine that you’ve contracted a development team to integrate chat functionality into your website. A functional requirement for this project may be “users should be able to share images via the chat function.” On the other hand, a non-functional requirement for this project may be “the chat function must fit into the existing UX of our website.”
Your team should be able to pull functional and non-functional requirements for your project from the software requirement specification (SRS), a type of requirements document which includes functional and nonfunctional requirement grouping.
2. Test Planning
Once your software test team has a clear understanding of what will be asked of them from a requirements standpoint and has developed comprehensive acceptance criteria, the planning phase of the STLC can begin.
Based on the exit criteria your testing team has set forth, they will work with your quality assurance team to build a test plan document. This document lays out which requirements will be tested, how they will be tested, and how the test activities will fit into the overall development process.
The presence of the QA team in the test plan document drafting process is crucial to the viability of the document. Outside of the context of the STLC, there are two types of software tests that will be performed as your team develops software: verification and validation.
Validation testing is the dynamic, code-based testing handled by your testing team that, so far, we’ve discussed exclusively in this article. Verification testing, though, is qualitative review of the product prior to the start of the testing process designed to catch potential bugs early on.
Because your QA team will handle verification testing, their experience up to this point can increase the effectiveness and fine-tune the focus of the test plan your software test team develops.
As a part of the test plan document, your test team should also put together a test strategy document. This document expands on the testing requirements outlined in the test plan document to describe the thought process behind each testing methodology.
Outside of the test strategy, other areas that should be specifically covered in a test plan document include in-scope activities, out of scope activities, assumptions, schedules, roles and responsibilities, deliverables, testing environments, testing tools, defect management plans, risks, risk management plans, and exit criteria.
Test planning is a comprehensive process and covers all future facets of the STLC. As such, the test plan document is a dynamic document. As they explore the next several phases of the STLC, your testing team may decide to revise their approach. At these junctures, it would be appropriate to revisit and revise the test plan document.
3. Test Case Development and Design
After your team has a working test plan in place, they will move on to the test case development phase of the STLC.
In this phase, your software test team will build the software test cases that will guide how the end product is tested. Test cases specify the procedure for checking a given condition of the software.
Ideally, they should detail the test scenario, prerequisites for performing the test, the priority with which the test should be handled, the test data that should be input when performing the test, any parameters that should be set prior to running the test, any pertinent contextual information about the test environment, and the expected result of the test.
Once the test has been run, the test case should be updated to include the status of the test (pass, fail, etc.), the actual results of the test, and any other important comments.
Automation vs Manual Testing
The term test case is often used interchangeably with the term test script.
However, some test professionals will choose to use test scripts to specifically reference automation scripts written to test software automatically.
Automation scripts are often the focus of your software test team’s efforts, whereas manual testing will be performed by your QA team.
Both types of testing have their merits. Test automation allows for tests to be run more quickly and provides a great level of visibility into which areas of your code are being tested. Conversely, if you’ve developed a test case that is strikingly complex, your team is more likely to execute it properly via manual testing.
To comprehensively test your software, both automated and manual testing should be performed. With the host of functional and non-functional requirements your team is testing, working both types of tests into the test cases you employ will ensure every aspect of your software is subject to the proper level of scrutiny prior to release.
4. Test Environment Setup
With your test plan fleshed out into specific test cases, your test team will move on to setting up the test environment.
The test environment is the programming environment in which your testing team will perform the tests outlined in your test cases. This environment should be set up to be as similar to the production environment as possible.
You’ll also want the test environment your team uses to be set up to handle any of the types of testing that have been identified as pertinent in your test cases.
Particular consideration should be given as to whether the tests should fall under the umbrella of one of the following:
- Acceptance testing: evaluates an entire system
- Integration testing: evaluates several components of the system
- Unit testing: examines a single part of the system
As discussed earlier, each of these types of testing examine your system at a different level.
Because any software being tested won’t be performing in a vacuum upon release, all three of these types of testing are important to perform as a part of the STLC. As such, your test environment should include the existing components of your system to allow for acceptance and integration testing.
While your QA team won’t be performing tests in the test environment, any outside verification testing they’re performing may influence the scope of the testing process. As such, updates made to the test plan document because of concurrent QA testing should be flowed through to your test cases and the parameters of the test environment.
As you set up your test environment, you’ll also want to ensure any testing tools your team plans to employ will be compatible with it.
Popular services such as web development testing tool Selenium are designed to be as universal as possible, but cybersecurity and other concerns may limit these tools’ usefulness in your test environment.
Source: Medium
In addition to Selenium, popular testing tools include Watir, TestComplete, Katalon Studio, and Cucumber.
What is Smoke Testing?
Prior to full test implementation, your team may opt to perform smoke testing. This type of testing is high-level and ensures that the software build is stable prior to further test activities.
Because smoke testing can quickly identify if your code will execute at all, it should be a prerequisite to all automated testing. Additionally, running this type of test prior to the test execution phase can uncover pain points in your code that can be worked into your test plan document and test cases.
5. Test Execution
Now that your software test team has properly prepared for the full scope of testing necessary, they can begin the execution phase of the STLC.
This stage in the testing process calls upon your testing team to perform all the tests outlined in the test plan document according to the parameters outlined in the test cases. These tests will be of several different types designed to ensure your software meets all necessary requirements.
One type of testing that will be particularly important in the execution phase is regression testing. As mentioned earlier, this type of testing checks if new features of a system hamper or break its overall functionality.
Regression testing is important to conduct throughout the test execution stage, as any changes made based on the results of your other tests could cause problems down the line.
See below for a tutorial on regression testing:
As your team runs the tests, testers should detail any less-than-stellar results in a defect report. This report should detail where in the code a bug occurs, what sort of error the bug causes, and the status of the bug.
Based on the defect reports, appropriate retesting should occur to ensure that all bugs are fixed prior to release. Additionally, any tests whose prerequisites are affected by bug fixes should undergo retesting as well to eliminate the possibility of downstream effects of these fixes.
6. Test Cycle Closure
As your team satisfies all test exit criteria, they will move to the final stage of the STLC, test cycle closure. In this stage, the software testing team will circulate reports on any relevant test results to all interested stakeholders as a final check that the software is ready for release.
The main report put together by your test team will be the test closure report, which gives a summary of all tests performed during the STLC, the bugs these tests unearthed, and the actions taken to fix these issues.
In reviewing this report, your knowledge of the STLC should be helpful. Not only will you be able to understand how the results speak to the software quality and functionality, but you can also examine the test coverage to ensure that the test activities properly encapsulate the scope of the test plan document.
Understanding the STLC is Key to Evaluating Software Testing Success
The STLC is a comprehensive, detailed process that ensures a successful software testing process. However, your understanding of the lifecycle’s phases will help ensure that your test team is effectively testing your software product.
With your understanding of the six phases of the STLC, you can provide relevant feedback that will better the testing process overall.
Whether your team is in the requirements analysis phase, test planning phase, test case development phase, test environment setup phase, test execution phase, or test cycle closure phase, your STLC knowledge will help you and your team properly work out bugs before implementing and releasing any new software.
Looking for some extra support with a software project? Connect with a software development company on The Manifest.
Additional Reading:
