Las pruebas continuas son el proceso de incorporar comentarios automatizados en las distintas fases del ciclo de vida de desarrollo de software (SDLC) en aras de una mayor rapidez y eficacia a la hora de gestionar las implementaciones.

Las pruebas continuas son un factor fundamental de la efectividad de los procesos de CI/CD (integración continua/entrega continua) y desempeñan un papel crucial a la hora de acelerar los plazos del SDLC al mejorar la calidad del código, evitar costosos cuellos de botella y acelerar los procesos de DevOps.

Uno de los principios fundamentales para desarrollar un método de DevOps práctico es cerrar la brecha entre la entrega rápida de software y las experiencias de usuario fiables. Sin embargo, la forma convencional de obtener comentarios manualmente en cada etapa de desarrollo de software (es decir, diseño de proyectos, codificación, pruebas, implementación y mantenimiento) ha provocado un uso insuficiente e ineficaz de los recursos organizativos y, en última instancia, ciclos de integración más largos y retrasos en las actualizaciones de productos.

Las pruebas continuas abordan estas ineficiencias al ayudar a los equipos de DevOps a "girar a la izquierda", proporcionándoles valiosos comentarios al principio del SDLC, a la vez que automatizan los procesos de pruebas manuales y minimizan los errores humanos.

Las pruebas continuas funcionan utilizando herramientas automatizadas para cargar scripts de control de calidad predefinidos en todas las etapas de producción. Estos scripts automatizados eliminan la necesidad de una intervención humana regular al ejecutar pruebas de control de calidad y validan secuencialmente la eficiencia del código fuente a la vez que garantizan que los equipos correspondientes proporcionen inmediatamente sus comentarios.

Si las pruebas automatizadas fallan, se notifica a los equipos de desarrollo en esa etapa individual de desarrollo para que puedan realizar los ajustes necesarios en su código fuente "antes" de que afecte a otros equipos en diferentes etapas del SDLC. Si las pruebas automatizadas pasan la inspección, los proyectos pasan automáticamente a la siguiente etapa del SDLC, lo que brinda a las organizaciones la capacidad de crear un modelo de entrega sostenible que maximice la productividad y mejore la coordinación entre departamentos.

En el siguiente vídeo, Eric Minick profundiza en el tema:

La incorporación de pruebas continuas en los procesos de DevOps proporciona varios beneficios a las empresas en crecimiento.

Mejor eficiencia e implementaciones de mayor calidad. Las pruebas continuas proporcionan un método automatizado para gestionar la garantía de calidad y la interoperación de calidad entre flujos de trabajo en cada etapa del ciclo de vida de desarrollo de software (SDLC). Al integrar bucles de comentarios continuos en los módulos de prueba de usuarios y unidades, los desarrolladores pueden recibir la información procesable que necesitan para mejorar la compatibilidad y el rendimiento de su código antes de implementarlo. Esta eficiencia resuelve las desconexiones entre varios miembros del equipo de DevOps y permite acelerar los programas de entrega de software.

Detección y corrección rápidas de errores para proyectos distribuidos. Las arquitecturas de desarrollo modernas de hoy en día son multifacéticas y multicapa. Las pruebas continuas ayudan a los equipos de desarrollo a resolver estas complejidades al incorporar una solución de pruebas escalable y automatizada que mejora significativamente los plazos de detección y corrección de errores.

Experiencia del usuario mejorada. Los métodos avanzados de pruebas continuas pueden simular una variedad de casos prácticos únicos y escenarios de solución de problemas y observar cómo los usuarios responden a ellos. La información obtenida de estas simulaciones permite a los desarrolladores eliminar las ineficiencias en la interfaz de usuario antes y evitar sorpresas no deseadas después de que se haya implementado el producto físico.

Reducción de costes debido a la interrupción del negocio relacionada con el desarrollo. Especialmente en los grandes sistemas interconectados, un error en un solo módulo de una aplicación puede tener efectos dominó que pueden causar tiempos de inactividad no deseados, lo que repercute negativamente en la productividad y los resultados finales.

Los proveedores de nube, por ejemplo, habitualmente informan de averías en un extremo que paralizan toda una región y provocan cortes que duran varias horas. Esto puede ser particularmente devastador para las organizaciones que dependen de una alta disponibilidad del servicio. Las pruebas continuas a nivel granular identifican errores que de otro modo serían invisibles en grandes sistemas de software y ayudan a evitar los costes de la interrupción del negocio.

Las pruebas continuas implican un espectro de pruebas que garantizan la fiabilidad, la seguridad, el rendimiento de las operaciones y la usabilidad del sistema. Las pruebas en el espectro incluyen lo siguiente:

• Pruebas de desplazamiento a la izquierda: este método prioriza las pruebas de software y de sistema al principio del ciclo de vida de desarrollo de software (SDLC) para ayudar a reducir o prevenir problemas de depuración significativos en el futuro.
  
  
• Pruebas de desplazamiento a la derecha: este método prioriza las pruebas cerca del final del SDLC, centrándose en mejorar la experiencia del usuario, el rendimiento general, la tolerancia a fallos y la funcionalidad.
  
  
• Pruebas aleatorias: estas pruebas, que pueden ser manuales o automatizadas, proporcionan una detección superficial inicial para detectar defectos visibles en el software. Si bien las pruebas aleatorias no son complicadas en su diseño, ofrecen una solución rápida y económica para eliminar errores graves en el software.
  
  
• Pruebas de unidad: son ideales para comprobaciones de estrés a pequeña escala, carga, volumen o fuga de memoria en todas las compilaciones para identificar degradaciones en las primeras etapas del desarrollo.
  
  
• Pruebas de integración y mensajería: comprueban si hay errores cuando los módulos de software funcionan en conjunto. Las pruebas continuas virtualizan las dependencias que faltan para que los equipos puedan probar lo bien que funcionan de manera colectiva los procesos y escenarios integrales. A continuación, el código compuesto se compila y ejecuta en tiempo de ejecución para comprobar si funcionan según lo esperado.
  
  
• Pruebas de rendimiento: probar el rendimiento del software de la aplicación por sí mismo puede no tener en cuenta el hardware y middleware en el entorno de producción final. Se requiere una prueba integrada del sistema para evaluar eficazmente el rendimiento general de la solución.
  
  
• Pruebas funcionales: esta forma de pruebas comprueba si la experiencia del usuario cumple con las expectativas y si los flujos de trabajo funcionales se ejecutan según sea necesario en un sistema de software. Por ejemplo, el software de la cadena de suministro debe ser capaz de alertar a los camiones para que lleguen a las fábricas cuando el inventario esté disponible para su envío. (Por el contrario, las pruebas no funcionales se centran en el rendimiento, la usabilidad, la fiabilidad, el tiempo de respuesta, el tiempo de carga, la escalabilidad, etc., e indican la preparación del software para ofrecer la experiencia del cliente deseada).
  
  
• Pruebas de regresión: este tipo de prueba verifica si hay cambios en el rendimiento, la funcionalidad o las dependencias después de corregir los errores en cualquier software dependiente y que el sistema funciona como antes.
  
  
• Pruebas de aceptación de usuarios: también llamadas pruebas de aplicaciones o de usuario final, es cuando la aplicación se prueba en una situación real por parte de algún subconjunto de usuarios previstos. Las pruebas beta son un ejemplo de pruebas de aceptación de usuarios.

Los sistemas y aplicaciones de TI corren un mayor riesgo de errores debido a las siguientes características:

• Están cada vez más integrados con una serie de tecnologías emergentes, por ejemplo, cloud computing, Internet de las cosas (IoT), redes definidas por software, realidad aumentada (RA)
  
  
• Están cada vez más distribuidos en varias regiones, con un núcleo y un límite perfectamente interconectados. Las aplicaciones para ciudades inteligentes, automóviles autónomos y servicios públicos inteligentes son beneficiarios de dicha arquitectura

En estos casos, las pruebas continuas son más exigentes porque el desarrollo no ocurre en una sola ubicación o compañía. Terceros, incluidos equipos remotos, pueden suministrar algunos elementos del sistema. El sistema puede integrarse con interfaces de programación de aplicaciones (API). Cada equipo de desarrollo opera en diferentes entornos de TI, incluido el software heredado. El entorno físico de cada uno de los equipos es imposible de reproducir para pruebas continuas.

Afortunadamente, las pruebas continuas se pueden virtualizar para crear un entorno de prueba en el que todo el sistema pueda reproducirse virtualmente en una única interfaz. Un entorno virtualizado se puede reconfigurar con facilidad para probar un sistema de TI diferente o para uno que se haya cambiado para corregir errores

En un entorno DevOps, las pruebas continuas se realizan automáticamente a lo largo del ciclo de vida del desarrollo de software (SDLC) y trabajan mano a mano con la integración continua para validar automáticamente cualquier nuevo código integrado en la aplicación.

Las herramientas de prueba están precargadas con scripts de prueba que se ejecutan automáticamente cada vez que se integra código nuevo en la aplicación. Normalmente, las pruebas comienzan con pruebas de integración y pasan automáticamente a pruebas del sistema, pruebas de regresión y pruebas de aceptación de usuarios.

Las pruebas generan fuentes de datos desde cada módulo de aplicación, y las fuentes se analizan para garantizar que todos los módulos afectados por el nuevo código funcionen como se espera. Si falla una prueba, el código vuelve al equipo de desarrollo para su corrección; luego se vuelve a integrar y el ciclo de prueba comienza de nuevo.

Una vez que se pasan todas las pruebas, la aplicación o el proyecto pasa a la siguiente etapa del SDLC (normalmente entrega continua).

Consulte la explicación de Andrea Crawford sobre DevOps para obtener algunos antecedentes sobre el tema:

Se necesita un marco de pruebas continuas para conjuntos de pruebas para garantizar su coherencia en todos los módulos de una aplicación, sus conectores (o API y contenedores), las plataformas, su infraestructura y los escenarios que definen sus requisitos.

Los conjuntos de pruebas pueden ser secuenciales (p. ej.,, las pruebas de regresión siguen a las pruebas de unidad) o pueden ser simultáneos (p. ej., una nueva iteración de un módulo va acompañada de una prueba con las pruebas correspondientes para sus dependencias).

Un marco de pruebas continuas proporciona un envoltorio alrededor del conjunto de pruebas para que se apliquen de manera consistente y preparen el camino para la automatización. Los desarrolladores quieren asegurarse de que el método que adoptan para un módulo no sea diferente de los aplicados a los módulos relacionados. Cuando los módulos evolucionan, también lo hacen una gama de pruebas para software interrelacionado.

Los marcos proporcionan una forma estándar de modificar cómodamente los scripts y las funciones para las pruebas. La automatización obtendrá beneficios cuando se eliminen las incoherencias en las pruebas; de lo contrario, generará una serie de resultados engañosos.