Tengo solo dos minutos
Muchos equipos y empresas esperan obtener grandes beneficios de las prácticas y herramientas DevOps, pero en el proceso olvidan una de las que brindan mayor ROI: la Automatización de Pruebas.
DevOps sin Automatización de Pruebas es una forma eficiente y efectiva de poner basura en producción.
OK puedo seguir leyendo
El siguiente diagrama nos ayuda a visualizar la problemática y mi sugerencia de manera sucinta:
DevOps nos ayuda a eficientizar procesos mediante la automatización y la estandarización apoyándose en la codificación de conocimiento (programación). El problema de automatizar todos los procesos necesarios del ALM (Application Lifecycle Management), y dejar fuera la automatización agresiva de pruebas es que no es factible verificar y validar un aplicativo de forma manual y conseguir niveles altos de calidad y eficiencia en la detección temprana de errores.
Automatización agresiva de pruebas
Esto significa llegar lo más cercano a un 100% de automatización de pruebas dados los recursos (software, hardware, dinero) y el talento (personas) disponibles. Por lo general, las pruebas de bajo nivel (unitarias e integración) son relativamente baratas de crear y mantener en el tiempo. Las pruebas de alto nivel (de aceptación o comportamiento) tienden a requerir herramientas y capacitaciones más especializadas para el personal.
Resumen del problema
- El día uno, probar un aplicativo de manera manual es sumamente rápido, son pocas funcionalidades.
- Con el pasar del tiempo y el crecimiento natural del aplicativo las pruebas requieren más tiempo y más personas.
- Eventualmente, llegara un punto de quiebre donde la cantidad de casos de prueba a ejecutar con cada entregable es inmanejable por el equipo de QA y simplemente ya no se puede alargar el ciclo de pruebas o agregar personas. En ese momento llega la decisión salomónica: ¿Cuales casos de prueba debemos dejar de ejecutar para salir a tiempo? tomamos la espada y partimos el listado en un punto arbitrario, pero en cualquier punto que lo partamos la calidad sufrirá.
Calidad
En este contexto estoy definiendo la calidad como el grado de conformidad con las necesidades de los clientes y usuarios. Note que no use la palabra requerimientos, pues no siempre los requerimientos formales satisfacen las necesidades originales del cliente. Es vital validar que el software puede satisfacer las necesidades originales, luego de ser construido, y no solo la versión escrita que comúnmente llamamos requerimientos o requisitos.
Los errores y omisiones son inherentes a la condición humana, al hacer pruebas manuales tenemos una formula de “interés compuesto” de errores:
- El cliente / usuario tiene una necesidad y hace un intento por comunicarla utilizando diversos medios: conversación, documentos, soportes audiovisuales, etc.
- Algún analista (PO, Ingeniero de Requisitos, etc.) intenta documentar estas necesidades como requisitos: Casos de Uso, Historias de Usuario, Documento de Requerimientos, etc.
- Los desarrolladores tratan de entender dichos requisitos y cumplirlos mediante la creación de un modelo formal y ejecutable: uno o más componentes de software expuestos como una aplicación al cliente o usuario.
- Los mismos desarrolladores o un personal de SQA intentan comprobar que el resultado final cumple tanto con los requisitos como con las necesidades. Estos realizan pruebas manuales, artesanales o guiadas por algún script (documento de casos de pruebas).
Cada paso de este proceso tiene una brecha importante de comunicación:
- Lo que el usuario o cliente piensa no es exactamente lo que comunica.
- Lo que el usuario o cliente comunica no es exactamente lo que logra documentar el analista de requisitos.
- Los desarrolladores no siempre comprenden los requisitos o logran crear una solución apropiada.
- El personal de control y aseguramiento de calidad no siempre logra crear casos de prueba que cubran todos los escenarios críticos y en ocasiones detectan falsos negativos al interpretar un comportamiento del software como erróneo cuando no lo es.
Al final quedamos con una aplicación potencialmente muy alejada de la necesidad del cliente o usuario. Esto es una realidad la cual podemos mejorar mas no eliminar. Existen distintas técnicas de comunicación, retroalimentación y detección temprana de inconsistencias y errores, pero ese no es el tema de hoy. El punto es que si tuviésemos las pruebas automatizadas, aunque estén probando una idea ligeramente distinta de la original, podemos salir a producción mucho más rápido sabiendo que por lo menos el código cumple con lo capturado en los requisitos. En segundo lugar, cuando el código deba ser cambiando las pruebas automáticas pueden detectar en segundos, bueno minutos para ser conservadores, la introducción de un error. Finalmente, las pruebas automáticas agregan objetividad y determinismo algo en lo que los humanos no somos muy buenos o nos requiere mucho esfuerzo y tiempo.
Eficiencia en la detección temprana de errores
Ya vimos que los errores pueden ocurrir y seguirán ocurriendo en el proceso de construcción de cualquier software. Las estrategias de mitigación de esta realidad (riesgo inherente al proceso) son muchas, me enfocare en la detección temprana de errores. Recordando nuestro proceso, bastante corto y simplificado, de cuatro pasos ahora agregue un quinto para llevar el aplicativo a manos del usuario final (“pasar a producción”). En cada una de las, ahora cinco, etapas o pasos es posible detectar errores e inconsistencias: entre las necesidades del usuario y lo que verbaliza, entre estas y lo que escribe el analista como requisito, entre lo que se escribió como requisito y otras partes del sistema, etc. Así podemos seguir hasta detectar un error en la aplicación luego de haberla entregado a los usuario finales, cuando esta “viva” o “en producción”. Mientras más avanzada la etapa más tarde estamos detectando los errores, más nos cuesta su reparación y nos impactan negativamente. Por tanto, lo ideal seria detectar los errores lo más temprano posible, idealmente no dejar que pasen de la etapa de construcción o codificación.
Las pruebas automáticas nos ayudan bastante en este sentido. Los equipos que las adoptan de manera seria y comprometida terminan creando las pruebas automáticas junto con el nuevo código producido desde el primer momento. Como toda nueva característica entregada viene con su batería de pruebas, la cantidad de defectos que escapan al desarrollador y luego al poco QA manual realizado (pruebas exploratorias, de penetración, etc.), es mínima.
Aclaraciones
- DevOps en si no es el problema, el concepto y los beneficios de esta practica son reales. El tema esta en la mentalidad de muchas lideres y desarrolladores que entienden que con automatizar el build y el deployment, lograr hacer CI+CD, ya tienen la batalla ganada.
- La automatización de pruebas realizada después que se entregan las características no funciona, los beneficios descritos en este articulo, y muchos otros no mencionados, no se consiguen cuando primero se crea el código y luego las pruebas. Peor aun algunos equipos utilizan la practica de una carrera entre un equipo de “desarrollo” y otro de “test automation” o robotización: el primero crea software y lo libera sin pruebas automáticas y el otro esta constantemente detrás automatizando pruebas para las características liberadas en ciclos anteriores.
- La mayoría de los equipos inician sus proyectos entre los cuadrantes II, III y IV, algunas por desconocimiento, otra por falta de recursos y otras por querer ir rápido al inicio. Cada uno de estos cuadrantes tiene sus atractivos aparentes y una trampa a mediano y largo plazo de las cuales podemos conversar largo y tendido en otro momento. Este articulo trata sobre la trampa del cuadrante IV, donde las empresas y equipos creen que pueden ir rápido pues “hacen DevOps” pero olvidan la automatización de pruebas, volviéndose rápidos en sacar software con problemas muchas veces por mes, semana, día, hora, …
Takeaways
- DevOps por si solo no resuelve nada, podemos caer en la clásica trampa de automatizar un proceso con problemas de fondo.
- Antes de embarcarnos en DevOps debemos diseñar nuestros procesos y luego automatizarlos eligiendo las herramientas que se adapten a nosotros.
- El desarrollo de software moderno no admite que se realicen pruebas completamente manuales, simplemente no es negocio ni para la fabrica, ni para el dueño del producto ni para los clientes.
Si estas haciendo planeas implementar DevOps o ya lo estas haciendo, pero las aplicaciones soportadas no tienen un alto porcentaje de pruebas automatizadas, comenta las razones para esta combinación.
Hasta la próxima …
