SDLC vs STLC: What's the Difference?
Although similarly named, the Software Development Life Cycle (SDLC) and Software Testing Life Cycle (STLC) are two separate and distinct processes for ensuring success within software delivery projects. Let’s take a look at how you can get the best out of both of these for your software delivery project:
What is the Software Development Life Cycle (SDLC)?
The Software Development Life Cycle (SDLC) is a linear set of steps for delivering software, based on a research paper by Dr Winston Royce originally published in 1970. The steps are as follows:
Once a gap or opportunity in the organisation’s application landscape has been identified, there is a need to understand and document exactly what that business requirement is in order to select the correct solution. It is important to resist the urge of jumping directly to a solution in this phase and stakeholders may need coaching and support to take an open mind about any solution preferences they may already have.
It is important at this stage to ensure that the requirements are not met, or could be closely met, by existing applications. Solution architects, business analysts or those with similar skill sets can help in this phase by gathering requirements and examining the existing application portfolio.
It is often wise at this stage to speak more widely across the organisation to determine if the identified or similar requirements exist as a need in other areas, to prevent duplicate systems being built or procured and allow reuse of the system.
The key output of this phase will be a business requirements document (BRD) which should contain a list of all required functionality, possibly prioritised using a technique such as MoSCoW (Must have/Should have/Could have/Won’t have now) with appropriate traceability by business area.
Once the requirements for the new software have been sufficiently documented and signed off, the design work can begin. At this point, organisations should decide if their effort is best spent on building a new bespoke system or purchasing something off the shelf. This may require a tender process such as a request for proposals (RFP) or a request for information (RFI).
Generally speaking, where capabilities are being met that are highly standardised (for example; payroll, appointment booking, electronic point of sale) it is often better to purchase an off the shelf system for these so-called “systems of record” or “systems of differentiation”. Where requirements exist that are unique to the industry or organisation or provide capabilities that are of competitive advantage the systems are known as “systems of innovation” and are more likely to be suited to a bespoke build.
At the design stage, business analysts and UX designers may work together to create wireframes or mock-ups of what the system would look like. Technical architects and solution designers may begin to design the architecture of the system and make selections around tech stack, hosting and programming languages, keeping in mind the organisation’s current skillset and vendors.
The key output of the design phase will vary by system but are likely to include a set of wireframes, a systems architecture diagram, a decision on tech stack and an indication of resourcing capabilities required.
In the build phase, the output of the “requirements” and “design” phases are transformed into working software by software developers. This could consist of various things such as building front ends, back ends, databases, microservices or many other components.
The software will be built in such a way that it provides the functionality specified in the requirements document and the best projects will ensure continuing engagement with end-users throughout this phase to ensure that the things being built are closely aligned with the originally stated requirements, as sometimes what is built can deviate from this.
In the testing phase, test analysts will conduct a number of validation checks on the software such as performance testing, load testing and exploratory manual testing. The main objective is to ensure that the quality of the work implemented in the build phase is sufficiently robust to meet the demands that will be placed on the system during normal operating conditions and determine what happens when those conditions are exceeded.
User acceptance testing may now begin to confirm that the way in which the system operates matches the stated expectations in the requirements gathering phase although close alignment between users and the build team during the build phase can help to minimise the rework which might be required and ensure there are no surprises.
During the deployment phase, the software is loaded into the relevant production environments & platforms from which it will be run. These environments may be physical servers located in the businesses data centre, or more increasingly, a cloud-hosted platform.
Training of end-users is likely to begin in this phase, in order to ensure that people are familiar with how to use the new system and if any data migration is required from the previous legacy system this will be completed to prevent the need for “double keying”.
Discussions should already have begun with the teams who will be supporting and sustaining the system in its “business as usual” state and these teams should also be considered during the training phase to allow them to be able to support the system once the project team is disbanded.
During the maintenance phase, the system is handed over to the team who will be supporting it for the remainder of its life at the organisation. Correct documentation and helpfiles will need to be prepared for service desk operatives so that they know how to direct user support requests to the correct team.
Enhancements and changes may be made to the system over its lifetime, for instance, if new requirements are discovered or if external factors such as regulatory changes occur and the approach for this will need to be considered, i.e. whether internal resource will be retained to make such changes, or will the changes be farmed out to an external provider on an ad-hoc basis.
For more details on the software development lifecycle and how to build on this in order to ensure security is built-in throughout, check out our article: Secure Software Development Lifecycle [Practical Guide]
What is the Software Testing Life Cycle (STLC)?
The Software Testing Life Cycle (STLC) is a process for ensuring that sufficiently detailed, robust tests are implemented throughout the inception of a system and beyond. It consists of 5 key phases as listed below:
During the requirements analysis phase, the business requirements document (BRD) created in the SDLC requirements phase is analysed by the testing team so that they understand the key outcomes and functionality that are required from the new system.
The testing team will discuss the BRD with key stakeholders and business analysts so that they have a good grasp of what is being built and how it should function. They should also consider the business criticality of the system, along with relevant regulatory requirements to ensure that any compliance aspects are adhered to.
Once the functionality and outcomes are understood, the testing team will be able to start planning how they are going to implement their tests. They will write a test strategy document for the initiative, detailing how they will make use of the various technologies at their disposal such as manual, automated, integration and unit tests. They may start to list out the specific test cases or scripts that will need to be created to ensure a robust and complete test of the system.
Once the specific test cases and approaches have been identified at a high level, the work can then begin on fleshing the test scripts out with more details such as the specific user journeys that will need to be tested, both from a happy path and an edge case perspective.
Test Environment Setup
Once a usable version of the system has been built, the test team can begin to build a suitable test environment, separate from the production and development environments. In this test environment, they will ensure they have appropriate user personas set up with the correct user login accounts and sufficient test data in order to execute their scripts.
Test Execution and Closure
Finally, once a stable environment exists, the test team takes the time to execute the scripts they designed and then feeds back to the project team and stakeholders with their findings. This step and others may need to be repeated many times as the findings are dealt with by the project team and then require retesting.
To recap, the SDLC and STLC are two separate but complementary processes, both of which need to be considered when any new system is built.
- The SDLC is concerned with building new systems, whereas the STLC is concerned only with testing them.
- The SDLC provides a linear process to ensure that you design and accurately build the correct system, whereas the STLC provides an approach to allow you to robustly test what has been built.
- Although the STLC exists as a standalone approach to testing, this does not mean that quality assurance should be left out of the SDLC. Quality should be built into software, rather than “tested out of it” and the STLC is not a substitute for good design, nor a fix for poor development.
- The SDLC and STLC will likely form part of any successful new software systems build.
When to use the SDLC?
- When you are building a new software system from scratch rather than modifying an off the shelf system.
- When you value stage gated formal (waterfall) processes over less formal (agile) incremental development.
- When you have a good idea of what your requirements are from the beginning, rather than solving a complex problem with an unknown solution.
- When your organisation values detailed documentation as part of hand-offs between teams.
When to use the STLC?
- To give a high level of structure, planning and rigour to your testing approach.
- To ensure that each part of the system is tested independently in turn before moving to the next.
- To validate that the stated business requirements have been met.
- When a high level of quality and robustness is required in the solution you are building and deploying with defects would be unacceptable.
Difference between SDLC and STLC
|Title||Software Delivery Lifecycle||Software Testing Lifecycly|
|Summary||Concerned with building software||Concerned with testing software|
|Objective||Ensure that software systems are built well||Ensure that software systems are tested sufficiently|
|Phases||Requirements Design Build Test Deploy Maintenance||Requirements analysis Planning Test development Environment setup Execution and closure|
|Involved people||Entire project team||Testers / QA engineers|
|Output||Usable software system||Tested software system|
The SDLC and STLC are just two tools that should be kept in any organisations toolkit, along with many others, to consider the use of when delivering any new software initiative. The SDLC allows well-defined software projects to be delivered in a phased and structured way. The STLC allows such projects to be robustly tested in order to ensure they are performant, reliable and functional.