Modela el futuro de la entrega de software y haz oír tu voz mediante la encuesta sobre el estado de DevOps de 2021.

Tecnología de DevOps: Pruebas continuas

La clave para mejorar la calidad del software es recibir con rapidez comentarios sobre el impacto de los cambios durante el ciclo de vida de la entrega de software. Tradicionalmente, los equipos recurrían a inspecciones de código y pruebas manuales para verificar la precisión de los sistemas. Estas inspecciones y pruebas se realizaban en una fase separada después de “finalizar el desarrollo”. Este enfoque tiene las siguientes desventajas:

  • Las pruebas manuales de regresión son lentas y costosas, lo que las convierte en un cuello de botella del proceso. El software no se puede actualizar con frecuencia, y los desarrolladores no reciben los comentarios con rapidez.
  • Las inspecciones y pruebas manuales no son confiables porque las personas no realizan de forma eficiente las tareas repetitivas como las pruebas de regresión manuales, y es difícil predecir el impacto de los cambios en un sistema de software complejo mediante la inspección.
  • Una vez que se “completa el desarrollo” del software, los desarrolladores deben esperar mucho tiempo para recibir comentarios sobre los cambios. Por lo general, esto hace que clasificar los defectos y solucionarlos sea muy laborioso. Los problemas de rendimiento, seguridad y confiabilidad a menudo requieren cambios de diseño que son aún más costosos de solucionar cuando se descubren en esta etapa.
  • Los ciclos de comentarios extensos también hacen que sea más difícil para los desarrolladores aprender a compilar código de calidad y, a veces, presionados por los tiempos, los equipos de desarrollo tratan a la calidad como “el problema de otra persona”.
  • Cuando los desarrolladores no se encargan de probar su propio código, es difícil que aprendan a escribir código que puede probarse.
  • En los sistemas que evolucionan con el tiempo, mantener actualizada la documentación de prueba requiere un esfuerzo considerable.

En su lugar, los equipos deben hacer lo siguiente:

  • Realizar todos los tipos de pruebas de forma continua durante todo el ciclo de vida de la entrega de software
  • Crear y seleccionar paquetes rápidos y confiables de pruebas automatizadas que se ejecuten como parte de las canalizaciones de entrega continua.

La investigación de DORA ayuda a los equipos a compilar (y aprender a compilar) software de alta calidad más rápido y, además, mejora la estabilidad del software, reduce el agotamiento del equipo y disminuye los problemas de implementación.

Cómo implementar pruebas continuas

Para mejorar la calidad del software, debes ejecutar de manera continua pruebas automatizadas y manuales durante todo el proceso de entrega para validar la funcionalidad y la arquitectura del sistema en desarrollo. Esta disciplina tiene un componente organizacional y uno técnico. En cuanto a lo organizacional, según la investigación de DORA, los equipos funcionan mejor cuando sucede lo siguiente:

  • Se permite que los verificadores trabajen junto con los desarrolladores a lo largo del proceso de desarrollo y entrega de software. (Ten en cuenta que “verificador” es una función, no necesariamente un trabajo de tiempo completo, aunque es un patrón común que se analiza más adelante).
  • Se realizan actividades de prueba manuales, como pruebas de exploración, pruebas de usabilidad y pruebas de aceptación a lo largo del proceso de entrega.

Una actividad técnica clave consiste en compilar y mantener un conjunto de paquetes de pruebas automatizadas, incluidas las siguientes:

  • Pruebas de unidades. Por lo general, se prueba un método, una clase o una función de forma aislada, de modo que los desarrolladores tienen la certeza de que el código funciona según lo previsto. Para asegurarte de que el código se pueda probar y las pruebas se puedan mantener, escribe tus pruebas de unidades antes de escribir el código, una técnica conocida como desarrollo basado en pruebas (TDD).
  • Pruebas de aceptación. Por lo general, se prueba una app o un servicio en ejecución (que suelen tener dependencias reemplazadas por dobles de prueba) para garantizar que el nivel más alto de funcionalidad opere según lo previsto y que no haya errores de regresión. Las pruebas de aceptación de ejemplo pueden verificar los criterios de aceptación empresariales de una historia de usuario o la precisión de una API. Escribe estas pruebas como parte del proceso de desarrollo. Nadie debería poder declarar que “el desarrollo se completó” en su trabajo, a menos que las pruebas de aceptación automatizadas estén aprobadas.

En el siguiente diagrama, que creó Brian Marick y que más adelante se menciona en el libro Agile Testing: A Practical Guide for Testers and Agile Teams (Pruebas ágiles: una guía práctica para los verificadores y equipos ágiles), se muestran los tipos de pruebas automatizadas y manuales que se deben ejecutar.

image

Las pruebas automatizadas destacadas en el diagrama anterior se ajustan a una canalización de implementación de entrega continua. En esas canalizaciones, cada cambio ejecuta una compilación que crea paquetes de software, ejecuta pruebas de unidades y, quizá, realiza otras verificaciones, como el análisis estático. Una vez que estos paquetes pasan la primera etapa, se ejecutan pruebas de aceptación automatizadas más completas y, quizá, algunas pruebas no funcionales, como pruebas de rendimiento y análisis de vulnerabilidades, en el software en ejecución implementado de forma automática. Por lo general, las compilaciones que pasan la etapa de aceptación luego están disponibles para la exploración manual y las pruebas de usabilidad. Por último, si no se encuentran errores en estos pasos manuales, se considera que la app se puede lanzar.

La ejecución de pruebas de forma continua como parte de una canalización contribuye a que se proporcionen comentarios para los desarrolladores con rapidez, un tiempo de entrega corto desde el registro hasta el lanzamiento y una tasa de error baja en los entornos de producción. La mayor parte del trabajo de los desarrolladores se valida en cuestión de minutos, en lugar de días o semanas, para que puedan corregir errores lo antes posible.

En el siguiente diagrama, se muestra un ejemplo de una canalización de implementación lineal simple. En este ejemplo, el verde significa que no se encontró ningún problema y el rojo significa que se encontraron uno o más problemas.

imagen

En el patrón de canalización de implementación, cada cambio crea un candidato de lanzamiento, y el ciclo de comentarios rápidos ayuda a detectar problemas lo antes posible. Cuando un paquete llega al final de la canalización y el equipo aún no está convencido de realizar el lanzamiento, o si se descubren defectos en la producción, es posible que se deba mejorar la canalización, tal vez mediante el agregado o la actualización de pruebas.

Errores comunes

  • Que los desarrolladores no participen en las pruebas. Según la investigación de DORA, cuando los desarrolladores son los principales responsables de crear y mantener conjuntos de pruebas automatizadas, y cuando resulta sencillo para los desarrolladores corregir las fallas de las pruebas de aceptación, el rendimiento mejora. Cuando otros grupos son propietarios de la automatización de pruebas, suelen surgir dos problemas:

    • Los paquetes de pruebas suelen estar en mal estado. Es posible que los cambios de código requieran que se actualicen las pruebas. Si los desarrolladores no se encargan de la automatización de las pruebas, la canalización de compilación permanece interrumpida hasta que el equipo responsable corrige las pruebas.
    • Los desarrolladores escriben código que resulta difícil de probar. Los desarrolladores tienden a resolver el problema que se les presenta sin pensar en cómo se probará. Esto puede ocasionar un código mal diseñado y conjuntos de pruebas costosos y difíciles de mantener.

    Los verificadores y equipos de control de calidad aún tienen una función importante en este modo de trabajo. Los verificadores tienen una perspectiva única del sistema porque comprenden cómo los usuarios interactúan con él. Se recomienda que los verificadores y los desarrolladores trabajen juntos a fin de crear y desarrollar los paquetes de pruebas automatizadas mediante herramientas para compartir pantallas, si los equipos no se encuentran en la misma ubicación física. De esta manera, pueden aprender unos de otros y solucionar problemas en tiempo real. Los verificadores también desempeñan una función esencial: realizan pruebas de exploración y usabilidad, y ayudan a seleccionar paquetes de pruebas.

  • No se pueden seleccionar los paquetes de pruebas. Asegúrate de revisar y mejorar de forma continua tus paquetes de pruebas para encontrar mejor los defectos y mantener la complejidad y el costo bajo control. Por ejemplo:

    • Por lo general, los paquetes de pruebas de aceptación deben representar recorridos del usuario reales de extremo a extremo a través del sistema, en lugar de solo colecciones de criterios de aceptación automatizados. A medida que tu producto evolucione, también cambiarán estas situaciones, y los conjuntos de pruebas que las validan. Para obtener más información sobre este proceso, mira el video Setting a Foundation For Successful Test Automation (Establece una base para la automatización exitosa de pruebas) de Angie Jones.
    • Si cada vez que cambias el código debes cambiar varias pruebas de unidades, es probable que dependas demasiado de la simulación o no puedas reducir el paquete de pruebas de unidades.
    • Mantén los paquetes de pruebas bien definidos. Si cada cambio en la IU hace que varias pruebas de aceptación fallen, usa el patrón de objeto de página para separar las pruebas del sistema a prueba.
    • Si las pruebas son costosas, esto puede causar problemas con la arquitectura del software. Asegúrate de seguir invirtiendo para que tu software sea fácil de probar; incorpora la refactorización en el trabajo diario de tu equipo.
  • Tener una proporción incorrecta de pruebas de aceptación y de unidades. Un objetivo de diseño específico de un paquete de pruebas automatizadas consiste en encontrar los errores lo antes posible. Esta es la razón por la que las pruebas de unidades de ejecución más rápida se ejecutan antes que las pruebas de aceptación de ejecución más lenta, y ambas se ejecutan antes que cualquier prueba manual.

    Deberías encontrar errores con la categoría de prueba más rápida. Cuando encuentres un error en una prueba de aceptación o de exploración, agrega una prueba de unidades para asegurarte de que la próxima vez este error se detecte más rápido, más temprano y a un costo menor. Mike Cohn describió la pirámide de automatización de pruebas ideal, en la que la mayoría de los errores se detectan mediante la prueba de unidades. Esta pirámide se muestra en el siguiente diagrama:

    image

  • Tolerancia de pruebas poco confiables. Las pruebas deben ser confiables: cuando se aprueban, debemos poder confiar en que el software está listo para lanzarse; y las fallas deben indicar un defecto real. En particular, no debes tolerar pruebas poco confiables. Obtén información sobre la estrategia de mitigación de Google para las pruebas poco confiables.

Formas de mejorar las pruebas continuas

Si tu organización aún no tiene una cultura de pruebas de unidades de desarrolladores, no te preocupes. La prueba de unidades no fue una práctica generalizada en Google en sus primeros años. Un grupo de voluntarios de Google llamado Testing Grouplet impulsó la cultura actual de la realización de pruebas de unidades integrales. Descubre cómo ayudaron a impulsar la adopción de pruebas de unidades mediante la creación de una comunidad de práctica enfocada en propagar el conocimiento sobre las pruebas en Google y convencer a los desarrolladores del valor de las pruebas de unidades.

Si no tienes suficiente automatización de pruebas, comienza con la compilación de una canalización de implementación de esquema básico. Por ejemplo, crea una sola prueba de unidades, una sola prueba de aceptación y una secuencia de comandos de implementación automatizada que haga funcionar un entorno de prueba de exploración, y agrúpalas. Luego, aumenta de forma gradual la cobertura de la prueba y amplía la canalización de implementación a medida que el producto o el servicio evolucionen.

Si ya estás trabajando en un sistema brownfield, sigue las instrucciones de este artículo, pero no te detengas a actualizar un paquete completo de pruebas automatizadas. En su lugar, escribe una cantidad pequeña de pruebas de aceptación para la funcionalidad de valor alto. Luego, asegúrate de pedir a los desarrolladores que escriban pruebas de unidades y aceptación para cualquier funcionalidad nueva o que desees cambiar. Se recomienda que uses el TDD a fin de mejorar la calidad y el mantenimiento del código principal y de prueba. Luego, asegúrate de que, cuando las pruebas de aceptación presenten fallas, escribirás pruebas de unidades para detectar el error más rápido.

Si tienes un paquete de pruebas poco confiable y con mantenimiento costoso, puedes reducirlo sin problemas. Un paquete de diez pruebas rápido y confiable es mucho mejor que uno de cientos de pruebas difícil de mantener y en el que nadie confía.

Formas de medir las pruebas continuas

Puedes medir los resultados de las pruebas continuas en tu entorno de la siguiente manera:

Factor por probar Qué se debe medir Objetivo
Escritores de pruebas de unidades y aceptación. Porcentaje de pruebas que escriben los desarrolladores, los verificadores y cualquier otro grupo de la empresa. Los autores y encargados principales del mantenimiento de las pruebas de aceptación son los desarrolladores.
Cantidad de errores detectados en pruebas de aceptación, de exploración y en producción. Cambio en la proporción de errores con el tiempo. Se detectan más errores en las fases de prueba “más económicas”, los equipos agregan pruebas automatizadas para los errores que se encuentran durante las pruebas de exploración y en producción, y se agregan pruebas de unidades para detectar los errores que se descubren en las pruebas de aceptación.
Tiempo dedicado a solucionar errores de las pruebas de aceptación. Cambio en el tiempo dedicado a corregir errores de pruebas a lo largo del tiempo (debe reducirse). Los desarrolladores pueden corregir con facilidad los errores de las pruebas de aceptación.
Las pruebas automatizadas son significativas. Realiza un seguimiento de la cantidad de errores de pruebas automatizadas que representan un defecto real y de la cantidad de pruebas que estaban mal codificadas. Los errores de pruebas siempre indican un defecto real en el producto.
Las pruebas automatizadas se ejecutan en la canalización de entrega. Verifica (sí/no) si todos los paquetes de pruebas se ejecutan en todos los activadores de canalización. Las pruebas automatizadas se ejecutan como parte de la canalización principal y el flujo de trabajo.

¿Qué sigue?