Dalia Trujillo
Líder en calidad y desarrollo de software. Hacemos que las empresas aumenten dramáticamente su calidad y velocidad de desarrollo, a través de Enjisst (Plataforma) y PAREX (Metodo de agilidad pragmática)
10 de abril de 2023
Introducción:
Las pruebas de software han evolucionado desde el modelo cascada al iterativo, del iterativo al ágil y de la ágil a DevOps. Cada uno más avanzado y exigente que el anterior.
Las metodologías iterativas nos concientizan de la necesidad de probar “por partes” dado que el proyecto que se realizan en “mini-cascadas”. Estas “mini-cascadas” ayudan a que las validaciones no queden al final dando la posibilidad de detectar errores de forma más pronta. También nos enseña que es necesario que los tiempos de ejecutar las pruebas de regresión sean menores, y por eso impulsan la automatización cuando el software que ya está desarrollado “y estable”.
Retos de la Agilidad:
Agilidad nos trae unos retos diferentes en pruebas, más allá de ejecutar varias veces las pruebas. Lo voy a resumir en dos retos principales:
El primer reto es la cross-funcionalidad que significa la colaboración entre los diferentes roles para poder ejecutar las pruebas no solamente al final de la iteración sino en medio de la iteración, incluso en los primeros días de la iteración. Ese es el reto que se tiene en pruebas, cuando estamos hablando de agilidad: Las iteraciones que dejan las pruebas al final no son agiles; las pruebas que se dejan para después de la iteración, mucho menos.
Las pruebas continuas a lo largo del sprint es un gran diferencial que hay entre la agilidad y el manejo iterativo.
Y el segundo reto que trae la agilidad es que se prevengan los errores por medio del TDD (desarrollo dirigido por pruebas). TDD nos invita a que al momento de definir el requerimiento se identifiquen los escenarios de prueba que deben ser cubiertos por el desarrollo que vamos a hacer, así se pueden prevenir los errores que se generan cuando un desarrollador no tiene claridad de todos los “caminos de uso” que debe cubrir su código. Y el reto más interesante es que nos invita a automatizar los escenarios de prueba antes de codificar.
¿Porque es útil este enfoque?
1. Para que haya disponibilidad para el desarrollador un conjunto suficientemente completo de pruebas, que se pueden ejecutar de forma rápida hasta que se valide que todo su desarrollo es correcto.
2. Queda de una vez listo para que se incluya en las pruebas de regresión, que ya sabemos que son fundamentales para demostrar que el software no se ha dañado a lo largo del desarrollo de nuevas funcionalidades.
3. El tercero, consecuencia del anterior y muy necesario cuando hablamos de agilidad, es que nos permite el refactoring. Se llama el refactoring el volver a desarrollar lo que ya estaba desarrollado cambiando su diseño para mejorarlo, o para ampliarlo. El refactoring es una consecuencia propia de la agilidad porque la agilidad está hecha para el cambio continuo del software, incluyendo el cambio de la conceptualización del software y diseño. Por ese motivo debemos prepararnos para el refactoring como algo propio de las metodologías ágiles: el TDD nos prepara para el refactoring.
El TDD nace desde el concepto de la automatización de las pruebas de componentes. Pero Dan North posteriormente cae en cuenta que, aunque este concepto es poderoso, es muy limitado dado que pierde la visión sistémica necesaria del desarrollo de software, y por eso crea el llamado BDD, en donde se pretende que tenga el mismo concepto de desarrollo dirigido por pruebas, pero ya no desde el punto de vista de componente, sino desde el punto de vista de pruebas de sistema, teniendo en cuenta el sistema completo.
¿Y DevOps?
DevOps efectúa la salida a producción continua y la colaboración requerida entre desarrolladores y operadores. La salida a producción continua nos quita el concepto que antes existía que era la fase de estabilización, debido al despliegue continuo.
¿Qué implicaciones tiene en término de pruebas?
Por un lado, la automatización de la validación del software pasa a otro nivel, dado que el objetivo ya no es solo disminuir los tiempos de ejecución, sino que se realice de forma autónoma sin intervención humana, como parte del pipeline del despliegue y con el poder de devolver automáticamente la puesta a producción si existe algún error en el software, todo sin asistencia.
Además, deben existir mecanismos orientados al seguimiento de la calidad en producción operación, para validar de forma automática que el comportamiento es el esperado después del despliegue y a lo largo de su uso, generar las alarmas si esto no llega a pasar, y mecanismos de seguimiento al error que permitan hacer verificación y posterior planeación de la solución de un error cuando se está en producción de forma continua, y corrección de datos si es necesario.
En conclusión, ya no hay fase de prueba, ni mini-fase de prueba, ni micro-fase de prueba. Agilidad y DevOps requieren de continua interacción del equipo alrededor de la calidad y las diferentes actividades de pruebas se realizan todo el tiempo para servicio de todo el equipo y por supuesto, del cliente final.
Bibliografía
- Berg, Craig. DevOps for Beginners. A complete guide to DevOps Best Practices, Including How You Can Create World-Class Agility, Reliability, And Security In Technology Organizations With DevOps, Edición de Kindle.
- Bergstr, Stefan. Adopting the Rational Unified Process: Success with the RUP. Addison Wesley. 2004
- Crispin, Lisa. Agile Testing (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2009. Edición de Kindle.
- Crispin, Lisa. Gregory, Janet. More Agile Testing, Learning Journeys for The Whole Team (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2015. Edición de Kindle.
- J. Humble, C. Read and D. North, “The deployment production line,” AGILE 2006 (AGILE’06), Minneapolis, MN, 2006, pp. 6 pp.-118, doi: 10.1109/AGILE.2006.53.
- Krutchen, Phillippe. The Rational Unified Process: An introduction. Addison Wesley. 2004.
- Smith, Larry. “Shift-Left Testing”, Dr Dobbs, 2001