Esta es la visión del SDLC desde el punto de vista de QA
Artículo de Pablo Gómez
Llevaba tiempo detrás de realizar un artículo sobre el ciclo de vida de desarrollo de software, más conocido por SDLC, sus siglas en inglés. Mucho se ha hablado y podréis encontrar por internet, por Chat GPT, Copilots y demás recursos, generalmente todos ellos tratando la versión “clásica”. Pero yo quería escribir uno más personal, que ofreciera mi propia visión del SDLC desde el punto de vista de QA testing y que reflejara en cierta manera los escenarios que me he ido encontrando en diferentes proyectos..
La versión clásica del SDLC
De libro, la definición de SDLC es:
Un proceso que emplean los equipos de desarrollo para diseñar y crear software.
Ese proceso ha de tener en cuenta el triángulo de hierro: la necesidad de equilibrar el alcance, el tiempo y el presupuesto disponible.
Añadiría en este punto un cuarto vértice que sería la calidad, complicando un poco más la foto.
El SDLC, o ciclo de vida del software, podemos dividirlo en siete fases bien diferenciadas:
Planificación e identificación de requisitos del cliente o usuario final.
Análisis de requisitos en detalle de cara a traducirlos al diseño
Diseño de la arquitectura e interfaces.
Pruebas del software.
Implementación con su despliegue en producción.
Mantenimiento, monitorización, mejoras, etc.
No voy a entrar en el detalle de cada fase, son prácticamente autoexplicativas.
En función de la madurez de nuestro producto, cada fase tendrá un peso diferente dentro del SDLC. Si todavía es muy embrionario y nos encontramos en una fase de prueba de concepto, el diseño de la arquitectura de la bbdd y las interfaces será mucho más relevante que si ya lleva años en el mercado y estamos implementando pequeñas mejoras.
Y finalmente, el SDLC se puede llevar a cabo siguiendo diferentes modelos: el clásico waterfall en el que no se pasa de una fase sin haber terminado la otra, un modelo iterativo (con filosofía Agile optativa), un modelo en espiral que es una mezcla de ambos…
SDLC y QA
Visto el acercamiento clásico al SDLC, cerremos los ojos, hagamos una breve ejercicio de imaginación y durante unos minutos suplantemos el rol de QA en un equipo de desarrollo. ¿Qué puede tener en la cabeza un miembro de equipo de calidad cuando le hablamos de ciclo de vida del software? Pues es imposible saberlo porque cada uno hemos tenido diferentes experiencias, pero apostaría a que se podría parecer bastante al siguiente gráfico:
Este dibujo se trata de un esquema que preparé para un proyecto hace algún tiempo y aunque está un poco modificado para la ocasión, servirá bien como apoyo didáctico.
El objetivo es visualizar qué tipo de pruebas manuales y principalmente automáticas se van a llevar potencialmente a cabo en cada momento del SDLC. Es muy práctico visualizar las fases como los sitios físicos donde se encuentra el código en cada momento porque eso se relaciona directamente con el estado de madurez de ese desarrollo y el tipo de pruebas que va a necesitar. Es muy similar a hacer una receta de cocina, donde debes planificar qué vas a comer, preparar los ingredientes, cocinarlos, verificar en cada momento que todo está en su punto y finalmente, emplatar y ¡a producción!
Siguiendo una línea temporal, nuestro código podría pasar por los siguientes “lugares”, los cuadraditos azules:
1. Definición de los requisitos
En esta fase se definen las funcionalidades a desarrollar, añadiéndolas a un backlog. Desde QA debemos asegurarnos de que:
Se definen los criterios de aceptación para cada funcionalidad, son claros y entendibles.
Se definen las pruebas de aceptación para cada criterio definido. Al menos debería haber una prueba por cada criterio de aceptación.
2. Desarrollo local
Es el momento en el que el desarrollador toma un ticket del backlog y comienza a trabajar en él con el objetivo de que cumpla con los criterios de aceptación. En esta fase el desarrollador debe programar los test unitarios y ejecutar el análisis estático de código. Un linter con reglas unificadas para todo el equipo sería muy recomendable en este punto.
3. Repositorio
Una vez el desarrollo de la funcionalidad está terminado, debe pasar una revisión de código por, al menos, otro compañero del equipo. Esta revisión es tremendamente importante porque es una magnífica herramienta didáctica: el revisor aprende diferentes maneras de afrontar un reto y el revisado tendrá notas interesantes sobre cómo hacer las cosas mejor. Otra opción a valorar es el pair programing.
Todo esto ya se lleva a cabo dentro del servidor CI/CD (Continuous Integration, Continuous Deployment - Delivery), que será quien orqueste el resto de saltos de nuestro código en su ajetreado camino hacia Producción. Estos saltos generalmente serán disparados de manera manual.
4. Entornos de desarrollo e integración
En este caso el proyecto disponía de dos entornos previos a preproducción, llamados DEV (Desarrollo) e INT (Integración). Al primero iba a parar el código de cada proyecto de manera individual y en el de INT se juntaba el código de aquellos proyectos que, tras haber pasado por DEV, eran los afortunados de pasar a formar del siguiente tren de release que les lleve a Producción.
En nuestro ejemplo, para QA el entorno DEV es el lugar donde llevar a cabo:
Testing de las nuevas funcionalidades, validando los criterios de aceptación.
Test de regresión automático para asegurar que nada de lo que antes funcionaba ha dejado de funcionar
Pruebas de rendimiento y de seguridad. Cuando antes las ejecutemos, antes tendremos feedback de su estado (Shift left).
Y en el entorno de integración INT el código pasaba por:
Sanity test rápido y más superficial de las nuevas funcionalidades.
Test de regresión automático para asegurar que nada de lo que antes funcionaba ha dejado de funcionar con el nuevo código. Esta prueba toma especial relevancia en este entorno porque las integraciones suelen romper cosas inesperadas.
5. Entorno de preproducción (aka PRE)
Llegamos a nuestro querido y muchas veces denostado entorno de preproducción, que debería ser una réplica casi exacta (a escala) de nuestra máquina productiva pero que muchas veces por limitaciones técnicas y/o económicas no pasa de ser un hierro más del CPD. Afortunadamente con los servicios Cloud este aspecto ha mejorado bastante últimamente. En este lugar, antesala del omnipotente entorno productivo, podríamos ejecutar:
Un sanity test de las nuevas funcionalidades y la UAT con el equipo de Producto.
Los test E2E automáticos de nuevo.
Las pruebas de seguridad y rendimiento, ya en un lugar mucho más parecido a donde sufrirá las grandes solicitaciones de carga y los ataques de los “malos”.
6. Entorno de producción (aka PROD)
Es un interesante debate el decidir si se llevan a cabo pruebas por parte de desarrollo de una release una vez está en producción. Donde sí suele haber consenso es en llevar a cabo un smoke test automático de un subset de las mismas para ver rápidamente si algo no va bien. Aparte de las pruebas como tal, hay metodologías de despliegue que nos ayudan a dar este paso con mayor seguridad y menor riesgo. En producción podemos:
Emplear metodologías de despliegue como blue/green o canary, y de desarrollo como feature toggle, que minimizan el riesgo de tener un problema grave en producción durante muchos minutos, facilitando un rápido rollback.
Llevar a cabo a la vez un sanity test manual y un smoke test automático seleccionando pruebas que no alteren significativamente la base de datos productiva.
Monitorización de las máquinas productivas y del estado de la aplicación (APM, Application Performance Monitoring) durante el proceso de despliegue y una vez la totalidad del código está desplegado y en ejecución.
Perspectiva final del SDLC
Las fases definidas arriba son un ejemplo que parten de un caso real de SDLC y probablemente se puedan apreciar similitudes con el proceso que se lleva a cabo en prácticamente cualquier ciclo de desarrollo. En nuestro caso este diagrama nos ayudó tremendamente a dar visibilidad a la labor de QA, a tener presente qué tipo de pruebas se hacían en cada entorno y a ajustarlas y definirlas mejor. Y para aquellos no iniciados en el SDLC es una manera sencilla de representar este particular ciclo de vida del software.
Si en vuestra empresa no tenéis algo similar, ¡os invito a poneros manos a la obra!