Tecnología de DevOps: Automatización de pruebas

La clave para crear un software de calidad es obtener con rapidez comentarios sobre el efecto de los cambios. Los equipos solían usar inspecciones y pruebas manuales de código para verificar la precisión de los sistemas. Estas inspecciones y pruebas se realizaban una vez que se completaba el desarrollo y presentaban 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.
  • En los sistemas que evolucionan con el tiempo, mantener la documentación de prueba actualizada requiere un esfuerzo considerable.

A principios de la década del 2000, la comunidad de desarrollo ágil propuso un conjunto de técnicas de automatización de pruebas con el fin de acelerar los comentarios. Estas técnicas evolucionaron y ahora se usan en canalizaciones de entrega continua a fin de proporcionar comentarios para los desarrolladores con rapidez, reducir el tiempo de espera para los cambios, reducir la tasa de fallas y mucho más.

Cómo implementar la automatización de pruebas

Para mejorar la calidad del software, debes ejecutar de manera continua pruebas automatizadas y manuales durante todo el proceso de entrega.

Las pruebas automatizadas incluyen lo siguiente:

  • 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 pruebas antes del código, una técnica que también se conoce como desarrollo basado en pruebas (TDD).
  • Pruebas de aceptación: Por lo general, prueban la app como un todo 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, la precisión de una API y la funcionalidad dañada que antes operaba de manera correcta. 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 usó como núcleo del 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.

Imagen

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, 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. Es decir, la empresa puede decidir si desea implementarla o no en producción.

La ejecución de la canalización de implementación continua garantiza 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 apenas se presenten.

En el siguiente diagrama, se muestra un ejemplo de una canalización de implementación lineal simple. En este ejemplo, el rojo representa los comentarios negativos, por pruebas o verificaciones que fallaron. El verde representa los comentarios positivos, lo que significa que se aprobaron todas las verificaciones.

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. Los desarrolladores deben participar en la creación y el mantenimiento de paquetes de pruebas automatizadas. 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 suelen generar 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á. Como resultado, puede haber paquetes de pruebas mal diseñados, o el equipo de automatización de pruebas debe refactorizar mucho código.

    Esto no significa que debas deshacerte de los verificadores o de los equipos de control de calidad. 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 para ayudar a los primeros a crear y desarrollar los paquetes de pruebas automatizadas. De esta manera, los desarrolladores conocen la perspectiva de los verificadores, y estos pueden aprender sobre la automatización. Los verificadores también deben realizar pruebas de exploración como parte de la canalización de implementación.

  • 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 posible. 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:

    Imagen

  • No se pueden seleccionar los paquetes de pruebas. Por ejemplo:

    • 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.
    • Por lo general, los paquetes de pruebas de aceptación deben representar recorridos del usuario completos y reales a través del sistema, en lugar de ser recopilaciones de criterios de aceptación automatizados. Para obtener más información al respecto, mira el video Setting a Foundation For Successful Test Automation (Establece una base para la automatización exitosa de pruebas) de Angie Jones.
    • 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.

Formas de mejorar la automatización de pruebas

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.

Por último, asegúrate de que los verificadores y los desarrolladores trabajen en conjunto como parte del proceso de desarrollo, en lugar de comenzar las pruebas solo después de que “se complete el desarrollo”. Lo ideal sería que los desarrolladores y los verificadores trabajen en el mismo espacio físico para programar la compilación, la clasificación y el mantenimiento de las pruebas de aceptación. Si esto no es posible, usa herramientas para compartir pantallas.

Formas de medir la automatización de pruebas

Puedes medir los resultados de la automatización de pruebas en el 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 exploración y en producción. Cambio en la proporción de errores con el tiempo. Se encuentran más errores en las fases de prueba “más económicas”, y debes agregar pruebas automatizadas para los errores que se produzcan durante las pruebas de exploración y la producció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.

Próximos pasos

  • Para ver vínculos a otros artículos y recursos, consulta la página de DevOps.
  • Aprende a compilar, probar y, también, implementar el sistema de forma continua mediante Cloud Build.
  • Aprende a supervisar el sistema y las pruebas mediante Cloud Monitoring.