Las pruebas continuas son el proceso de incorporar comentarios automatizados en diferentes etapas del ciclo de vida del desarrollo de software (SDLC, siglas en inglés de software development life cycle) para dar soporte a una mejor velocidad y eficiencia al gestionar las implementaciones.

Las pruebas continuas son un factor crítico detrás de la eficacia de los procesos de integración continua/entrega continua (CI/CD, siglas en inglés de continuous integration/continuous delivery) y desempeña un papel crucial en la aceleración de los cronogramas de SDLC, ya que mejora la calidad del código, evita costosos cuellos de botella y acelera los procesos de DevOps.

Uno de los principios fundamentales para el desarrollo de un enfoque práctico de DevOps es cerrar la brecha entre la entrega rápida de software y las experiencias de usuario confiables. Sin embargo, la forma convencional de obtener comentarios manualmente en cada fase de desarrollo del software (es decir, diseño del proyecto, programación, pruebas, despliegue y mantenimiento) ha derivado en un uso insuficiente e ineficaz de los recursos organizativos y, en última instancia, en ciclos de integración más largos y retrasos en las actualizaciones del producto.

Las pruebas continuas abordan estas ineficiencias, ya que ayudan a los equipos de DevOps con "shift left", pues se les brindan comentarios valiosos al principio del SDLC mientras automatizan los procesos de prueba manuales y minimizan los errores humanos.

Las pruebas continuas funcionan mediante herramientas automatizadas para cargar scripts de control de calidad predefinidos en todas las etapas de producción. Estos scripts automatizados eliminan la necesidad de intervención humana regular mediante la ejecución de pruebas de control de calidad, y validan secuencialmente la eficiencia del código fuente, al tiempo que garantizan que se proporcione inmediatamente cualquier comentario relevante a los equipos apropiados.

Si las pruebas automatizadas fallan, se notifica a los equipos de desarrollo en esa etapa de desarrollo individual para que puedan realizar los ajustes necesarios en su código fuente "antes" de que afecten a otros equipos en diferentes etapas del SDLC. Si las pruebas automatizadas pasan la inspección, los proyectos avanzan 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 video, Eric Minick profundiza en el tema:

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

Mejor eficiencia y despliegues 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 SDLC. Con la integración de ciclos de comentarios continuos en módulos de prueba de usuarios y unidades, los desarrolladores pueden recibir los insights útiles que necesitan para mejorar la compatibilidad y el rendimiento de su código antes de su despliegue. Esta eficacia resuelve las desconexiones entre varios miembros del equipo de DevOps y permite acelerar los plazos de entrega del software.

Detección rápida de errores y corrección de proyectos distribuidos. Las arquitecturas de desarrollo modernas de hoy son multifacéticas y de múltiples capas. Las pruebas continuas ayudan a los equipos de desarrollo a acabar con estas complejidades mediante la incorporación de una solución de pruebas escalable y automatizada, que mejora significativamente los plazos de detección y corrección de errores.

Experiencia de usuario mejorada. Los métodos avanzados de prueba continua pueden simular una variedad de casos de uso únicos y escenarios de solución de problemas, y observar cómo los usuarios responden a ellos. Los insights recopilados de estas simulaciones permiten a los desarrolladores eliminar las ineficiencias en la interfaz de usuario antes y evitar imprevistos después de que se haya desplegado el producto físico.

Reducción de costos debido a la interrupción comercial relacionada con el desarrollo. Especialmente en grandes sistemas interconectados, un error en un solo módulo de una aplicación puede tener efectos dominó que pueden causar tiempos de inactividad imprevistos, lo cual afecta negativamente la productividad y el resultado final.

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

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

• Pruebas shift left: este enfoque da prioridad a las pruebas de software y sistemas en una fase temprana del SDLC para ayudar a reducir o prevenir problemas significativos de depuración más adelante.
  
  
• Pruebas shift right: este enfoque prioriza las pruebas cerca del final del SDLC, ya que se centran en mejorar la experiencia del usuario, el rendimiento general, la tolerancia a fallas y la funcionalidad.
  
  
• Pruebas de humo: estas pruebas, que pueden ser manuales o automatizadas, proporcionan una detección superficial inicial de fallas conspicuas en el software. Si bien las pruebas de humo no son elaboradas en su construcción, siguen proporcionando una solución rápida y económica para la eliminación de errores graves en el software.
  
  
• Pruebas unitarias: son ideales para comprobaciones de estrés, carga, volumen o pérdida de memoria a pequeña escala en compilaciones para identificar degradaciones en etapas tempranas de desarrollo.
  
  
• Pruebas de integración y mensajes: estas verifican errores cuando los módulos de software funcionan conjuntamente entre sí. Las pruebas continuas virtualizan las dependencias faltantes para que los equipos puedan probar qué tan bien funcionan colectivamente los procesos y escenarios end to end. Luego, el código compuesto se compila y se coloca en tiempo de ejecución para probar si funcionan como se esperaba.
  
  
• Pruebas de rendimiento: probar el rendimiento del software de aplicación por sí mismo puede no tener en cuenta el hardware y el middleware en el entorno de producción final. Se requieren pruebas integradas del sistema para evaluar eficazmente el rendimiento general de la solución.
  
  
• Pruebas funcionales: esta forma de prueba verifica 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 facilidad de uso, la confiabilidad, el tiempo de respuesta, el tiempo de carga, la escalabilidad, etc. y miden la preparación del software para ofrecer la experiencia deseada al cliente).
  
  
• Prueba de regresión: esta 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.
  
  
• Prueba de aceptación del usuario: también denominada prueba de aplicación o prueba de usuario final, es cuando un subconjunto de usuarios previstos prueba la aplicación en una situación del mundo real. Las pruebas beta son un ejemplo de pruebas de aceptación del usuario.

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

• Se integran cada vez más con una serie de tecnologías emergentes, como computación en la nube, internet de las cosas (IoT, siglas en inglés de Internet of Things), redes definidas por software y realidad aumentada (RA).
  
  
• Se distribuyen cada vez más en múltiples regiones, con un núcleo y borde perfectamente interconectados. Las aplicaciones para ciudades inteligentes, vehículos autónomos y servicios públicos inteligentes son beneficiarias de dicha arquitectura

En estos casos, las pruebas continuas son más exigentes porque el desarrollo no ocurre en una sola ubicación o empresa. Terceros, incluidos equipos remotos, pueden suministrar algunos elementos del sistema. El sistema puede integrarse con interfaces de programación de aplicaciones (API, siglas en inglés de application programming interfaces). 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 de DevOps, las pruebas continuas se realizan automáticamente a lo largo del SDLC y trabajan mano a mano con la integración continua para validar automáticamente cualquier código nuevo 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 un nuevo código en la aplicación. Normalmente, las pruebas comienzan con evaluaciones de integración y pasan automáticamente a pruebas del sistema, pruebas de regresión y pruebas de aceptación del usuario.

Las pruebas generan fuentes de datos de 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 una prueba falla, el código vuelve al equipo de desarrollo para su corrección; luego se reintegra y el ciclo de pruebas comienza de nuevo.

Una vez superadas todas las pruebas, la aplicación o el proyecto pasa a la siguiente fase del SDLC, normalmente, la 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 a fin de garantizar su congruencia 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 (por ejemplo, las pruebas de regresión siguen a las pruebas unitarias) o concurrentes (por ejemplo, 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 wrapper alrededor del conjunto de pruebas para que se apliquen de manera congruente y se preparen para la automatización. Los desarrolladores quieren asegurarse de que el enfoque 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 ofrecen una forma estándar de modificar convenientemente los scripts y las funciones para las pruebas. La automatización obtendrá beneficios cuando se eliminen las incongruencias en las pruebas; de lo contrario, generará una serie de resultados de pruebas engañosos.