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 retroalimentación de los desarrolladores mediante la introducción de pruebas activadas por el entorno de desarrollo, así como pruebas más tradicionales activadas por desarrolladores y evaluadores. [3]
En el caso de las pruebas continuas, el alcance de las pruebas se extiende desde la validación de requisitos de abajo hacia arriba o historias de usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [4]
En la década de 2010, el software se ha convertido en un diferenciador comercial clave. [5] Como resultado, las organizaciones ahora esperan que los equipos de desarrollo de software entreguen más software y más 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 generalmente descubren que su proceso de prueba les impide lograr los beneficios esperados de su iniciativa de aceleración del SDLC. [9] Las pruebas y el proceso de calidad general siguen siendo problemáticos por varias razones clave. [10]
Las organizaciones adoptan las pruebas continuas porque reconocen que estos problemas les impiden entregar software de calidad a la velocidad deseada. Reconocen la creciente importancia del software, así como el creciente costo de las fallas del software, y ya no están dispuestas a hacer concesiones entre tiempo, alcance y calidad. [2] [17] [18]
El objetivo de las pruebas continuas es proporcionar una retroalimentación rápida y continua sobre el nivel de riesgo comercial en la última versión o candidato a lanzamiento. [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 la aplicación quedan expuestos poco después de su introducción. [6] Los equipos de desarrollo pueden entonces evitar que esos problemas progresen a la siguiente etapa del ciclo de vida del desarrollo de software (SDLC). Esto reduce el tiempo y el esfuerzo que se deben dedicar a encontrar y corregir defectos. Como resultado, es posible aumentar la velocidad y la frecuencia con la que se entrega software de calidad (software que cumple con las expectativas de un nivel aceptable de riesgo), 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 del negocio, la ejecución de las pruebas produce una lista priorizada de tareas procesables (en lugar de una cantidad potencialmente abrumadora de hallazgos que requieren una revisión manual). Esto ayuda a los equipos a concentrar sus esfuerzos en las tareas de calidad que tendrán el mayor impacto, en función de los objetivos y las prioridades de su organización. [2]
Además, cuando los equipos ejecutan continuamente un amplio conjunto de pruebas continuas a lo largo del ciclo de vida del desarrollo de software, acumulan métricas sobre la calidad del proceso, así como sobre el estado del software. Las métricas resultantes se pueden utilizar para reexaminar y optimizar el proceso en sí, incluida la eficacia de esas pruebas. Esta información se puede utilizar para establecer un ciclo de retroalimentación que ayude a los equipos a mejorar el proceso de forma incremental. [4] [10] La medición frecuente, los ciclos de retroalimentación estrictos y la mejora continua son principios clave de DevOps . [21]
Las pruebas continuas incluyen la validación de los requisitos funcionales y 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 los requisitos no funcionales ( pruebas no funcionales : para determinar si la aplicación cumple con las expectativas en cuanto a 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) más temprana posible de los riesgos que son más críticos para la empresa u organización que está lanzando el software. [6]
Los equipos a menudo descubren que, para garantizar que el conjunto de pruebas pueda ejecutarse de manera continua y evaluar eficazmente 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 para el sistema bajo prueba, y 2) las pruebas de GUI requieren una considerable reelaboración para mantener el ritmo de los cambios frecuentes típicos de los procesos de lanzamiento acelerado; 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 diariamente. [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]
Lo ideal es que todas las pruebas se ejecuten en todos los entornos de prueba que no sean 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 dependencias que su organización puede controlar y crear imágenes), virtualización de servicios (para dependencias que están fuera de su alcance de control o que no son adecuadas para crear imágenes) y administración de datos de prueba. [1] [4] [10] [25]
Dado que las aplicaciones modernas están altamente distribuidas, las suites de pruebas que las ejecutan generalmente requieren acceso a dependencias que no están disponibles para realizar pruebas (por ejemplo, servicios de terceros, mainframes que están disponibles para realizar 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 extremo a extremo requieran acceso a dependencias que aún están evolucionando o que aún no se han implementado. Este problema se puede abordar mediante el uso de 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 consistentes en las distintas ejecuciones de pruebas. [1] [7] [10]
Una de las razones por las que los equipos evitan las pruebas continuas es que su infraestructura no es lo suficientemente escalable como para ejecutar continuamente el conjunto de pruebas. Este problema se puede solucionar centrando 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]
El objetivo de las pruebas continuas es aplicar una "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 la integración continua, 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 a lanzamiento y ejecutar regularmente estas pruebas en el contexto de entornos de prueba estables, similares a los de producción. Algunas diferencias entre las pruebas automatizadas y las continuas:
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 y b) cambió o rompió involuntariamente la funcionalidad existente. Estas pruebas, que fueron un componente clave de la Programación Extrema , implican 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 indica que la implementación es exitosa. [13] [28]
Las empresas de investigación Forrester Research y Gartner hicieron de las pruebas continuas una consideración primordial en sus evaluaciones anuales de 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 implicó consultas con clientes de Gartner, encuestas a usuarios de herramientas, respuestas de proveedores a preguntas de Gartner y demostraciones de productos de proveedores. Gartner requirió herramientas que admitieran pruebas de aplicaciones de escritorio nativas de Windows y soporte para pruebas de Android o iOS, así como también soporte para 3 de los siguientes: aplicaciones web responsivas, aplicaciones móviles, aplicaciones de paquetes, API/servicios web. Los resultados de la investigación del Cuadrante Mágico de 2019 son: [29]
En 2020, Forrester Research evaluó 15 herramientas que cumplían con sus criterios para herramientas de automatización funcional de pruebas de nivel empresarial. [30] Forrester determinó 26 criterios en función de investigaciones anteriores, necesidades de los usuarios y entrevistas con expertos, luego evaluó los productos en función de 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 exigió que las herramientas tuvieran capacidades de prueba multiplataforma, móvil, de interfaz de usuario y de API. Los resultados de la ola de Forrester de 2020 son: [30]