This is the view of the SDLC from the perspective of QA
Posted by Pablo Gómez
I have been looking forward to write an article about the software development life cycle, better known as SDLC, its acronym in English. Much has been said and you can be found on the internet, by Chat GPT, Copilots and other resources, generally all of them dealing with the “classic” version. But I wanted to write a more personal one, offering my own vision of SDLC from a QA point of view and reflecting in some way the scenarios that I have encountered in different projects.
The classic version
By its very definition, the SDLC is:
A process used by development teams to design and build software. This process has to take into account the iron triangle: the need to balance scope, time and available budget.
I would add a fourth vertex at this point, which would be quality, complicating the picture a little more.
The life cycle can be divided into seven well-differentiated phases:
Planning and identification of customer or end user requirements.
Analysis of requirements in detail in order to translate them into the design
Architecture and interface design.
Software testing.
Deployment in production.
Maintenance, monitoring, improvements, etc.
I will not go into the details of each phase, they are practically self-explanatory.
Depending on the maturity of our product, each phase will have a different weight within the SDLC. If it is still very embryonic and we are in a proof-of-concept phase, the design of the database architecture and interfaces will be much more relevant than if it has already been on the market for years and we are implementing small improvements.
And finally, the SDLC can be carried out by following different models: the classic waterfall in which one phase is not passed without having finished the other, an iterative model (with optional Agile philosophy), a spiral model that is a mixture of both...
SDLC y QA
Given the classic approach to the development cycle, let's close our eyes, do a brief imagination exercise and for a few minutes imagine that we have the role of QA in a development team. What might a quality team member have in mind when we talk to them about the software development cycle? Well, it's impossible to know because we have all different experiences, but I would bet that it might look quite similar to the following graphic:
This drawing is a diagram that I prepared for a project some time ago and although it is slightly modified for the occasion, it will serve well as a didactic support.
The objective is to visualize what type of manual and mainly automatic tests will potentially be carried out at each stage of the SDLC. It is very practical to visualize the phases as the physical places where the code is located at each moment because that is directly related to the maturity state of the development and the software testing types it will need. It is very similar to making a cooking recipe, where you have to plan what you are going to eat, prepare the ingredients, cook them, check at every moment that everything is ready and finally, plate and get to production! ?
Following a timeline, our code could go through the following “places”, the little blue squares:
1. Requirements definition
In this phase, the functionalities to be developed are defined, adding them to a backlog. QA must make sure that:
Acceptance criteria are defined for each functionality, they are clear and understandable.
Acceptance tests are defined for each defined criteria. There should be at least one test for each acceptance criteria.
2. Local development
This is the moment when the developer takes a ticket from the backlog and starts working on it with the objective of meeting the acceptance criteria. In this phase the developer must write the unit tests and execute the static code analysis. A linter with unified rules for the entire team would be highly recommended at this point.
3. Repository
Once the development of the functionality is finished, it must undergo a code review by at least one other teammate. This review is tremendously important because it is a great learning tool: the reviewer learns different ways to approach a challenge and the reviewee will have interesting notes on how to do things better. Another option to consider is pair programming.
All of this is already carried out by the CI/CD (Continuous Integration, Continuous Deployment - Delivery) server, which will orchestrate the rest of our code jumps on its busy path to Production. These jumps are generally be triggered manually.
4. Development and integration environments.
In this case, the project had two environments prior to pre-production, called DEV (Development) and INT (Integration). The code of each project individually went to the DEV environment and the code of those projects that, after having passed through DEV, were the lucky ones to become part of the next release train, went to the INT environment.
In our example, for QA the DEV environment is the place to carry out:
Testing of new functionalities, validating acceptance criteria.
Automatic regression testing to ensure that nothing that worked before has stopped working.
Performance and security tests. The sooner we run them, the sooner we will have feedback on their status (Shift left).
And in the INT integration environment the code went through:
Quick and more superficial Sanity test of the new functionalities.
Automatic regression testing to ensure that nothing that worked before has stopped working with the new code. This test takes on special relevance in this environment because integrations often break unexpected things.
5. Preproduction environment (aka PRE)
We arrive at our beloved and often reviled pre-production environment, which should be an almost exact replica (to scale) of our production machine but which many times, due to technical and/or economic limitations, is no more than just another iron in the CPD. Fortunately, with Cloud services this aspect has improved a lot lately. In this place, prelude to the omnipotent productive environment, we could execute:
A sanity test of the new functionalities and the UAT testing with the Product team.
Automatic E2E tests again
The security and performance tests, already in a place much more similar to where it will suffer the large load requests and the attacks of the “bad guys”.
6. Production environment (aka PROD)
It is an interesting debate to decide whether to carry out development tests of a release once it is in production. Where there is usually consensus is in carrying out an automatic smoke test on a subset of them to quickly see if something is not right. Apart from the tests themselves, there are deployment methodologies that help us take this step with greater security and lower risk. In production we can:
Employ deployment methodologies such as blue/green, Canary deployment, and development methodologies as feature toggle, that minimize the risk of having a serious problem in production for many minutes, facilitating a quick rollback.
Carry out both a manual sanity test and automatic smoke test, selecting tests that do not significantly alter the production database.
Monitoring of productive machines and the state of the application (APM, Application Performance Monitoring) during the deployment process and once all the code is deployed and running.
Final SDLC perspective
The phases defined above are an example based on a real SDLC case and you can probably see similarities with the process that takes place in almost any development cycle. In our case this diagram helped us tremendously to give visibility to the QA work, to keep in mind what kind of tests were done in each environment and to adjust and define them better. And for those uninitiated in the SDLC, it is a simple way to represent this particular software lifecycle.
If you don't have something similar in your company, I invite you to get started!