Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte del proceso de entrega de software para obtener retroalimentación inmediata sobre los riesgos comerciales asociados con un candidato a lanzamiento de software. [1] [2] Las pruebas continuas se propusieron originalmente como una forma de reducir el tiempo de espera para recibir comentarios de los desarrolladores mediante la introducción de pruebas activadas por el entorno de desarrollo, así como pruebas más tradicionales activadas por desarrolladores / probadores. [3]
Para las pruebas continuas, el alcance de las pruebas se extiende desde la validación de los requisitos ascendentes o las historias de usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [4]
Impulsores de adopción
En la década de 2010, el software se ha convertido en un diferenciador empresarial clave. [5] Como resultado, las organizaciones ahora esperan que los equipos de desarrollo de software entreguen más y más software innovador en ciclos de entrega más cortos. [6] [7] Para satisfacer estas demandas, los equipos han recurrido a enfoques lean , como Agile , DevOps y Continuous Delivery , para intentar acelerar el ciclo de vida del desarrollo de sistemas (SDLC). [8] Después de acelerar otros aspectos del proceso de entrega, los equipos normalmente encuentran que su proceso de prueba les impide lograr los beneficios esperados de su iniciativa de aceleración SDLC. [9] Las pruebas y el proceso de calidad general siguen siendo problemáticos por varias razones clave. [10]
- Los procesos de prueba tradicionales son demasiado lentos. La duración de la iteración ha cambiado de meses a semanas o días con la creciente popularidad de Agile, DevOps y Continuous Delivery. Los métodos tradicionales de prueba, que dependen en gran medida de las pruebas manuales y las pruebas de GUI automatizadas que requieren actualizaciones frecuentes, no pueden seguir el ritmo. [9] [11] En este punto, las organizaciones tienden a reconocer la necesidad de ampliar sus esfuerzos de automatización de pruebas. [1] [12]
- Incluso después de agregar más automatización al proceso de prueba existente, los gerentes aún carecen de información adecuada sobre el nivel de riesgo asociado con una aplicación en un momento dado. [2] Comprender estos riesgos es fundamental para tomar decisiones rápidas de ir / no ir involucradas en los procesos de Entrega Continua. [13] Si las pruebas se desarrollan sin comprender lo que la empresa considera un nivel de riesgo aceptable, es posible tener un candidato de lanzamiento que pase todas las pruebas disponibles, pero que los líderes empresariales no considerarían listo para lanzamiento. [14] Para que los resultados de las pruebas indiquen con precisión si cada versión candidata cumple con las expectativas comerciales, el enfoque para diseñar las pruebas debe basarse en la tolerancia de la empresa a los riesgos relacionados con la seguridad, el rendimiento, la confiabilidad y el cumplimiento. [5] Además de tener pruebas unitarias que verifican el código en un nivel ascendente muy granular, existe la necesidad de un conjunto más amplio de pruebas para proporcionar una evaluación descendente del riesgo comercial del candidato a la versión. [4]
- Incluso si las pruebas están automatizadas y las pruebas miden de manera efectiva el nivel de riesgo comercial, los equipos sin un proceso de calidad coordinado de extremo a extremo tienden a tener problemas para satisfacer las expectativas comerciales dentro de los ciclos de entrega comprimidos actuales. [4] Se ha demostrado que intentar eliminar los riesgos al final de cada iteración es significativamente más lento y requiere más recursos que incorporar calidad en el producto a través de estrategias de prevención de defectos como las pruebas de desarrollo . [15] [16]
Las organizaciones adoptan las pruebas continuas porque reconocen que estos problemas les impiden entregar software de calidad a la velocidad deseada. Reconocen la importancia creciente del software, así como el costo creciente de las fallas del software, y ya no están dispuestos a hacer concesiones entre tiempo, alcance y calidad. [2] [17] [18]
Metas y beneficios
El objetivo de las pruebas continuas es proporcionar retroalimentación rápida y continua con respecto al nivel de riesgo comercial en la última versión o versión candidata. [2] Esta información se puede utilizar para determinar si el software está listo para avanzar a través del proceso de entrega en un momento dado. [1] [5] [13] [19]
Dado que las pruebas comienzan temprano y se ejecutan de forma continua, los riesgos de las aplicaciones se exponen poco después de su introducción. [6] Los equipos de desarrollo pueden evitar que esos problemas progresen a la siguiente etapa del SDLC. Esto reduce el tiempo y el esfuerzo necesarios para encontrar y corregir defectos. Como resultado, es posible aumentar la velocidad y frecuencia con la que se entrega el software de calidad (software que cumple con las expectativas de un nivel de riesgo aceptable), así como disminuir la deuda técnica . [4] [10] [20]
Además, cuando los esfuerzos y las pruebas de calidad del software están alineados con las expectativas comerciales, la ejecución de la prueba produce una lista priorizada de tareas procesables (en lugar de una cantidad potencialmente abrumadora de hallazgos que requieren revisión manual). Esto ayuda a los equipos a centrar sus esfuerzos en las tareas de calidad que tendrán el mayor impacto, según los objetivos y prioridades de su organización. [2]
Además, cuando los equipos están ejecutando continuamente un amplio conjunto de pruebas continuas en todo el SDLC, acumulan métricas con respecto a la calidad del proceso, así como el estado del software. Las métricas resultantes se pueden utilizar para volver a examinar y optimizar el proceso en sí, incluida la eficacia de esas pruebas. Esta información se puede utilizar para establecer un circuito de retroalimentación que ayude a los equipos a mejorar gradualmente el proceso. [4] [10] La medición frecuente, los ciclos de retroalimentación ajustados y la mejora continua son principios clave de DevOps . [21]
Alcance de la prueba
Las pruebas continuas incluyen la validación tanto de los requisitos funcionales como de los no funcionales .
Para probar los requisitos funcionales ( pruebas funcionales ), las pruebas continuas a menudo implican pruebas unitarias , pruebas de API , pruebas de integración y pruebas del sistema . Para probar requisitos no funcionales (pruebas no funcionales : para determinar si la aplicación cumple con las expectativas de rendimiento, seguridad, cumplimiento, etc.), implica prácticas como análisis de código estático , pruebas de seguridad , pruebas de rendimiento , etc. [9] [20] Las pruebas deben diseñarse para proporcionar la detección (o prevención) lo antes posible de los riesgos que son más críticos para la empresa u organización que lanza el software. [6]
Los equipos a menudo descubren que para garantizar que el conjunto de pruebas pueda ejecutarse de manera continua y eficaz evalúe el nivel de riesgo, es necesario cambiar el enfoque de las pruebas de GUI a las pruebas de API porque 1) las API (la "capa de transacción") se consideran la interfaz más estable al sistema que se está probando, y 2) las pruebas de la GUI requieren una reelaboración considerable para mantener el ritmo de los frecuentes cambios típicos de los procesos de liberación acelerada; Las pruebas en la capa API son menos frágiles y más fáciles de mantener. [11] [22] [23]
Las pruebas se ejecutan durante o junto con la integración continua , al menos a diario. [24] Para los equipos que practican la entrega continua , las pruebas se ejecutan comúnmente muchas veces al día, cada vez que la aplicación se actualiza en el sistema de control de versiones. [9]
Idealmente, todas las pruebas se ejecutan en todos los entornos de prueba que no son de producción . Para garantizar la precisión y la coherencia, las pruebas deben realizarse en el entorno de producción más completo posible. Las estrategias para aumentar la estabilidad del entorno de prueba incluyen software de virtualización (para las dependencias que su organización puede controlar y crear imágenes), virtualización de servicios (para dependencias más allá de su alcance de control o inadecuadas para la creación de imágenes) y la gestión de datos de prueba. [1] [4] [10] [25]
Prácticas comunes
- Las pruebas deben ser una colaboración de desarrollo, control de calidad y operaciones, alineadas con las prioridades de la línea de negocio, dentro de un proceso de calidad coordinado de principio a fin. [1] [4] [10] [17] [26]
- Las pruebas deben tener componentes lógicos, ser incrementales y repetibles; los resultados deben ser deterministas y significativos. [1] [4]
- Todas las pruebas deben ejecutarse en algún punto de la canalización de compilación, pero no todas las pruebas deben ejecutarse todo el tiempo, ya que algunas pruebas son más costosas en recursos ( pruebas de integración ) que otras (pruebas unitarias). [1] [9]
- Elimine los datos de prueba y las limitaciones del entorno para que las pruebas se puedan ejecutar de forma constante y coherente en entornos similares a los de producción. [1] [4] [9]
- Para minimizar los falsos positivos, minimizar el mantenimiento de las pruebas y validar de manera más efectiva los casos de uso en los sistemas modernos con arquitecturas de varios niveles, los equipos deben enfatizar las pruebas de API sobre las pruebas de GUI . [4] [11] [12]
Desafíos / obstáculos
Dado que las aplicaciones modernas están altamente distribuidas, los conjuntos de pruebas que las ejercen generalmente requieren acceso a dependencias que no están disponibles para las pruebas (por ejemplo, servicios de terceros, mainframes que están disponibles para pruebas solo en capacidad limitada o en momentos inconvenientes, etc.) Además, con la creciente adopción de procesos de desarrollo ágiles y paralelos, es común que las pruebas funcionales de un extremo a otro requieran acceso a dependencias que aún están en evolución o que aún no se han implementado. Este problema se puede abordar utilizando la virtualización de servicios para simular las interacciones de la aplicación bajo prueba (AUT) con las dependencias faltantes o no disponibles. También se puede utilizar para garantizar que los datos, el rendimiento y el comportamiento sean coherentes en las distintas ejecuciones de prueba. [1] [7] [10]
Una razón por la que los equipos evitan las pruebas continuas es que su infraestructura no es lo suficientemente escalable para ejecutar continuamente el conjunto de pruebas. Este problema se puede abordar enfocando las pruebas en las prioridades de la empresa, dividiendo la base de pruebas y paralelizando las pruebas con herramientas de automatización de lanzamiento de aplicaciones . [24]
Pruebas continuas frente a pruebas automatizadas
El objetivo de las pruebas continuas es aplicar "automatización extrema" a entornos de prueba estables, similares a los de producción. La automatización es esencial para las pruebas continuas. [27] Pero las pruebas automatizadas no son lo mismo que las pruebas continuas. [4]
Las pruebas automatizadas implican la ejecución automatizada impulsada por CI de cualquier conjunto de pruebas que el equipo haya acumulado. [ aclaración necesaria ] Pasar de las pruebas automatizadas a las pruebas continuas implica ejecutar un conjunto de pruebas que está diseñado específicamente para evaluar los riesgos comerciales asociados con un candidato de lanzamiento y ejecutar estas pruebas periódicamente en el contexto de entornos de prueba estables, similares a la producción. Algunas diferencias entre las pruebas automatizadas y continuas:
- Con las pruebas automatizadas, una prueba fallida puede indicar cualquier cosa, desde un problema crítico hasta una violación de un estándar de nomenclatura trivial. Con las pruebas continuas, una prueba fallida siempre indica un riesgo empresarial crítico.
- Con las pruebas continuas, una falla de prueba se aborda a través de un flujo de trabajo claro para priorizar los defectos frente a los riesgos comerciales y abordar primero los más críticos.
- Con las pruebas continuas, cada vez que se identifica un riesgo, existe un proceso para exponer todos los defectos similares que ya se hayan introducido, así como para evitar que este mismo problema vuelva a ocurrir en el futuro. [2] [5]
Antecesores
Desde la década de 1990, el desarrollo continuo basado en pruebas se ha utilizado para proporcionar a los programadores una retroalimentación rápida sobre si el código que agregaron a) funcionó correctamente yb) cambió o rompió involuntariamente la funcionalidad existente. Esta prueba, que fue un componente clave de Extreme Programming , implica la ejecución automática de pruebas unitarias (y, a veces, pruebas de aceptación o pruebas de humo) como parte de la compilación automatizada, a menudo muchas veces al día. Estas pruebas se escriben antes de la implementación; pasar las pruebas indican que la implementación es exitosa. [13] [28]
Herramientas de prueba continua
Las firmas de investigación Forrester Research y Gartner hicieron de las pruebas continuas una consideración primordial en sus evaluaciones anuales de las herramientas de automatización de pruebas. Gartner publicó una versión actualizada de la investigación en 2019.
Gartner evaluó 10 herramientas que cumplían con sus criterios para herramientas de automatización de pruebas de nivel empresarial. La evaluación incluyó consultas con clientes de Gartner, encuestas a usuarios de herramientas, respuestas de proveedores a preguntas de Gartner, demostraciones de productos de proveedores. Gartner necesitaba herramientas para admitir las pruebas de aplicaciones de escritorio nativas de Windows y la compatibilidad con las pruebas de Android o iOS, así como para admitir 3 de los siguientes: aplicaciones web receptivas, aplicaciones móviles, aplicaciones de paquetes, API / servicios web. Los resultados de la investigación del Cuadrante Mágico de 2019 son: [29]
- Líderes: Berenjena , SmartBear Software , Tricentis
- Retadores: IBM , Micro Focus
- Visionarios: Broadcom , Parasoft
- Jugadores de nicho: froglogic , Ranorex , Worksoft
En 2020, Forrester Research evaluó 15 herramientas que cumplían con sus criterios para herramientas de automatización funcional de prueba de nivel empresarial. [30] Forrester determinó 26 criterios basados en investigaciones anteriores, necesidades de usuarios y entrevistas con expertos, luego evaluó los productos frente a esos criterios en función de las respuestas de los proveedores a las preguntas de Forrester, demostraciones de productos de los proveedores y entrevistas con los clientes. Forrester necesitaba herramientas para tener capacidades de prueba entre navegadores, dispositivos móviles, UI y API. Los resultados de la ola de Forrester de 2020 son: [30]
- Líderes: ACCELQ, Berenjena, Parasoft, Tricentis
- Rendimientos sólidos: Broadcom, IBM, Mabl, Micro Focus, Perforce , Sauce Labs , SmartBear Software
- Competidores: Cyara, Expiretest, Worksoft
- Challengers: Ranorex
Ver también
- Entrega continua
- Integración continua
- DevOps
- Gestión de la liberación
- Virtualización de servicios
- Pruebas de software
- Automatización de pruebas
Otras lecturas
- Ariola, Wayne; Dunlop, Cynthia (2014). Prueba continua . CreateSpace. ISBN 978-1494859756.
- Gruver, Gary; Mouser, Tommy (2015). Liderar la transformación: aplicar principios ágiles y DevOps a escala . IT Revolution Press. ISBN 978-1942788010.
- Whittaker, James; Arbon, Jason; Carollo, Jeff (2012). Cómo prueba Google el software . Addison-Wesley Professional. ISBN 978-0321803023.
- Humilde, Jez; Farley, David (2010). Entrega continua: Versiones de software confiables a través de la automatización de la construcción, prueba e implementación . Addison-Wesley Professional. ISBN 978-0-321-60191-9.
Referencias
- ^ a b c d e f g h i Parte del proceso: por qué las pruebas continuas son esenciales , por Adam Auerbach, TechWell Insights agosto de 2015
- ^ a b c d e f La relación entre el riesgo y las pruebas continuas: una entrevista con Wayne Ariola , por Cameron Philipp-Edmonds, Stickyminds, diciembre de 2015
- ^ Saff, D .; Ernst, MD (20 de noviembre de 2003). Reducir el tiempo de desarrollo desperdiciado mediante pruebas continuas . 14º Simposio Internacional sobre Ingeniería de Fiabilidad de Software, 2003. Denver, CO, EE.UU .: IEEE. págs. 281-292. ISBN 0-7695-2007-3. ISSRE 2003. Archivado desde el original el 1 de agosto de 2016. doi : 10.1109 / ISSRE.2003.1251050
- ^ a b c d e f g h i j k DevOps: ¿Está enviando errores a los clientes más rápido ?, por Wayne Ariola y Cynthia Dunlop, PNSQC, octubre de 2015
- ^ a b c d DevOps y QA: ¿Cuál es el costo real de la calidad? , por Ericka Chickowski, DevOps.com, junio de 2015
- ^ a b c La importancia de cambiar a la derecha en DevOps , por Bob Aiello, CM Crossroads, diciembre de 2014
- ^ a b Los problemas persisten en los flujos de trabajo continuos , por Lisa Morgan, SD Times, septiembre de 2014
- ^ Prueba continua: Piense diferente , por Ian Davis, Revista Visual Studio, septiembre de 2011
- ^ a b c d e f Pruebas en un mundo de entrega continua , por Rob Marvin, SD Times junio de 2014
- ^ a b c d e f Desplazar a la izquierda y priorizar la calidad , por Adam Auerbach, TechWell Insights octubre de 2014
- ^ a b c La evaluación de Forrester Wave ™ de la automatización de pruebas funcionales (FTA) está disponible y se trata de ir más allá de las pruebas de GUI , por Diego Lo Giudice, Forrester Research 23 de abril de 2015
- ^ a b El desarrollo continuo trae cambios para los probadores de software , por Amy Reichert, SearchSoftwareQuality septiembre de 2014
- ^ a b c Toma de Zeichick: Olvídese de la 'integración continua': la palabra de moda ahora es 'Prueba continua' , por Alan Zeichick, SD Times, febrero de 2014
- ^ ¿ Comprar el software incorrecto? Una solución puede costar $ 700,000 Una conversación con Theresa Lanowitz de Voke , por Dom Nicastro, CMS Wire Octubre de 2014
- ^ Jones, alcaparras; Bonsignour, Olivier (2011). La economía de la calidad del software . Addison-Wesley Professional. ISBN 978-0132582209.
- ^ Kolawa, Adam; Huizinga, Dorota (2007). Prevención automatizada de defectos: mejores prácticas en la gestión de software . Prensa de la Sociedad de Computación Wiley-IEEE. pag. 73. ISBN 978-0-470-04212-0.
- ^ a b Theresa Lanowitz habla sobre automatización de pruebas extremas en STAREAST 2014 , por Beth Romanik, TechWell Insights, mayo de 2014
- ^ Vista de invitado: ¿Qué le impide continuar? , por Noel Wurst, SD Times, noviembre de 2015
- ^ Administre los riesgos comerciales del desarrollo de aplicaciones con pruebas continuas , por Wayne Ariola, CM Crossroads, septiembre de 2014
- ^ a b El poder de las pruebas de rendimiento continuo , por Don Prather, Stickyminds agosto de 2015
- ^ Prácticas para DevOps y entrega continua , por Ben Linders, InfoQ julio de 2015
- ^ Produzca un mejor software mediante el uso de una estrategia de pruebas en capas , por Sean Kenefick, Gartner 7 de enero de 2014
- ^ Cohn, Mike (2009). Tener éxito con Agile: Desarrollo de software con Scrum . Addison-Wesley Professional. pag. 312 . ISBN 978-0321579362.
- ^ a b Experiencias de pruebas continuas en Siemens Healthcare , por Ben Linders, InfoQ febrero de 2015
- ^ DevOps: no es un mercado, sino una filosofía centrada en herramientas que respalda una cadena de valor de entrega continua , por Laurie F.Wurster, Ronni J. Colville, Jim Duggan, Gartner , febrero de 2015
- ^ Mantenga su software saludable durante el desarrollo ágil , por Adrian Bridgwater, ComputerWeekly noviembre de 2013
- ^ Automatización extrema, cumple con el ciclo de vida de la preproducción , por Alexandra Weber Morales, SD Times, enero de 2014
- ^ Integración continua (versión original) , por Martin Fowler, DevOps.com, septiembre de 2000
- ^ Cuadrante mágico para la automatización de pruebas de software , Gartner, 25 de noviembre de 2019
- ^ a b "The Forrester Wave: Suites de automatización de pruebas funcionales continuas, segundo trimestre de 2020" . Forrester . 2020-06-18 . Consultado el 16 de octubre de 2020 .