Por qué DevOps necesita pruebas continuas
por Parasoft
14 de octubre de 2015
4 min leer
Las pruebas continuas no se tratan solo de automatización. Cierto pruebas continuas para DevOps alinea las actividades de prueba con el valor comercial. El objetivo de las pruebas continuas en apoyo de DevOps es eliminar las pruebas sin sentido y producir tareas de valor agregado que realmente impulsen a la organización de desarrollo hacia un lanzamiento exitoso.
En respuesta a la demanda actual de “Todo continuo”, la cinta transportadora de entrega de software se mueve cada vez más rápido. Pero teniendo en cuenta que las pruebas han sido la principal limitación del proceso de entrega de software, no es razonable esperar que la simple aceleración de un proceso problemático produzca mejores resultados.
Una gran analogía para I Love Lucy fans es la infame escena de Lucy y Ethel en la fábrica de dulces, luchando por mantener el ritmo mientras la cinta transportadora comienza a sacar chocolates cada vez más rápido.
Ahora que la entrega rápida de software diferenciable se ha convertido en un imperativo empresarial, los equipos de desarrollo de software se esfuerzan por mantenerse al día. En respuesta al aumento de la demanda, están buscando nuevas formas de acelerar sus ciclos de lanzamiento, impulsando la adopción de prácticas de desarrollo ágiles o lean como DevOps.
Pero según la cantidad de fallas de software que ahora aparecen en los titulares a diario, es evidente que acelerar el SDLC abre la puerta a graves repercusiones.
Las organizaciones son negligentes al asumir que las prácticas de ayer pueden satisfacer las demandas de los procesos de hoy. Es necesario que haya un cambio cultural de probar una aplicación a comprender los riesgos asociados con una versión candidata. Tal cambio requiere ir más allá del enfoque tradicional de "abajo hacia arriba" para las pruebas, que se enfoca en agregar pruebas incrementales para nuevas funcionalidades. Si bien esto siempre será necesario, es igualmente importante adoptar un enfoque de arriba hacia abajo para mitigar los riesgos comerciales. Esto significa que las organizaciones deben defender la experiencia del usuario con los casos de uso más probables en el contexto de requisitos no funcionales, de forma continua.
Para que se produzca una automatización más avanzada, debemos ir más allá del porcentaje de aprobación / falla de la prueba hacia una comprensión mucho más granular del impacto de la falla: un matiz que se pierde en el conjunto de pruebas de regresión tradicional.
La prueba continua, que implica la ejecución automática de un conjunto de pruebas diseñadas para verificar si se satisfacen las expectativas comerciales de funcionalidad, seguridad, confiabilidad y rendimiento, es clave para cerrar esta brecha. Cambia el paradigma de un enfoque ascendente puro a un modelo híbrido en el que se aprovechan las pruebas descendentes para proteger la experiencia del usuario esperada de los cambios introducidos a medida que evoluciona la aplicación. En última instancia, la prueba continua restablece la pregunta de "¿ha terminado la prueba?" a "¿se entiende y acepta el nivel de riesgo?"
Prueba: El elefante en la habitación
A medida que las organizaciones comiencen a acelerar el SDLC, los cuellos de botella del proceso se harán evidentes. Uno de los cuellos de botella que sigue afectando la aceleración de SDLC son las pruebas. En el mejor de los casos, las pruebas se han considerado como gastos generales inevitables: un evento "encuadrado en el tiempo" que ocurre en algún momento entre la finalización del código y la fecha de lanzamiento prevista. En el peor de los casos, las organizaciones han llevado los procesos de calidad a la publicación, lo que ha obligado a una "prueba de aceptación del cliente en tiempo real".
La prueba siempre ha sido el elefante en la habitación. Psicológicamente, la naturaleza maleable del software ha dado a las organizaciones una excusa para aplazar la inversión en pruebas. Sin embargo, este aplazamiento genera una deuda técnica. Con el tiempo, la deuda técnica se agrava, aumentando el riesgo y la complejidad asociados con cada versión.
Otro obstáculo para la aceleración de SDLC es la falta de un proceso de calidad coordinado de principio a fin. Si se recopilaran datos de calidad holísticos y confiables en todo el SDLC, los puntos de decisión más automatizados podrían optimizar los procesos posteriores.
Prueba continua: cómo ayuda
Continuous Testing proporciona una evaluación objetiva en tiempo real de los riesgos comerciales asociados con una aplicación en desarrollo. Aplicado de manera uniforme, permite a los gerentes comerciales y técnicos tomar mejores decisiones de compensación entre el alcance, el tiempo y la calidad de la versión.
Las pruebas continuas no son solo más automatización, es una reevaluación más amplia de las prácticas de calidad del software, impulsadas por el costo de la calidad de una organización, equilibrado por la velocidad y la agilidad. En última instancia, las pruebas continuas pueden proporcionar una evaluación cuantitativa del riesgo y producir tareas procesables que ayudarán a mitigar estos riesgos antes de pasar a la siguiente etapa del SDLC.
Figura 1: Mitigue los riesgos antes de que pasen a la siguiente etapa del SDLC
Por ejemplo, suponga que un minorista sabe que factores muy específicos de la experiencia del usuario relacionados con la aplicación hacen que sea más probable que el consumidor agregue artículos a su carrito de compras de comercio electrónico. Estas métricas, que se definen en el lenguaje empresarial y se miden automáticamente, son exactamente los mismos puntos de referencia que se utilizan para aceptar un candidato a lanzamiento de software. La pregunta que debe responder el conjunto de pruebas es cómo afectan las modificaciones de la aplicación a este conjunto de métricas comerciales. El objetivo es llevar las expectativas comerciales y el lenguaje comercial a la vanguardia del proceso de validación y, en última instancia, proteger al usuario y la marca.
Cuando se trata de la calidad del software, nos enfrentamos a la necesidad de una verdadera reingeniería de procesos. La prueba continua no es una solución "plug and play". Como ocurre con todas las iniciativas impulsadas por procesos, requiere la evolución de las personas, los procesos y la tecnología. Debemos acomodar la naturaleza creativa del desarrollo de software como disciplina, pero debemos enfrentar el hecho abrumador de que el software impregna todos los aspectos del negocio, y la falla del software presenta el mayor riesgo para la organización.
Resumen
Dadas las expectativas comerciales en cada etapa del SDLC, Continuous Testing ofrece una evaluación cuantitativa del riesgo, así como tareas procesables que ayudan a mitigar estos riesgos antes de que pasen a la siguiente etapa del SDLC. El objetivo de las pruebas continuas en apoyo de DevOps es eliminar las pruebas sin sentido y producir tareas de valor agregado que realmente impulsen a la organización de desarrollo hacia un lanzamiento exitoso.