Pruebas de software automatizadas

¿Por qué es importante la automatización de las pruebas para la entrega continua?

La entrega continua (CD) consiste en publicar versiones de código nuevas lo más rápido posible para los clientes. Las pruebas automatizadas resultan fundamentales para alcanzar ese objetivo. No hay forma de automatizar dicha publicación si hay un paso manual que requiere mucho tiempo en el proceso de publicación.

La CD forma parte de un proceso de implementación mayor. Es sucesora de la integración continua (CI) y depende de ella. La CI es totalmente responsable de ejecutar pruebas automatizadas ante cualquier cambio de código nuevo y de verificar que dichos cambios no afectan a la integridad de las funciones establecidas ni introducen errores nuevos. La CD se activa una vez que el paso de integración continua supera el plan de pruebas automatizado.

Esta relación entre las pruebas automatizadas, la CI y la CD aporta numerosas ventajas a los equipos de software que trabajan a gran velocidad. Las pruebas automatizadas garantizan la calidad en todas las fases del desarrollo, ya que aseguran que las confirmaciones nuevas no introducen ningún error, por lo que el software sigue estando listo para implementarse en todo momento.

1. Pruebas de extremo a extremo

Podría decirse que las pruebas más útiles que se pueden implementar son las pruebas de extremo a extremo (E2E, por sus siglas en inglés). Las pruebas E2E simulan una experiencia a nivel de usuario en toda la pila de un producto de software. Por lo general, los planes de pruebas E2E abarcan historias a nivel de usuario como: “el usuario puede iniciar sesión”, “el usuario puede hacer un depósito” o “el usuario puede cambiar la configuración del correo electrónico”. Implementar estas pruebas resulta muy útil, ya que ofrecen la garantía de que los usuarios reales están teniendo una experiencia sin errores, incluso cuando se envían confirmaciones nuevas.

Las herramientas de pruebas E2E capturan y reproducen las acciones del usuario, por lo que los planes de pruebas E2E se convierten en registros de los flujos clave de la experiencia de este. Si un producto de software carece de cualquier tipo de cobertura de pruebas automatizadas, conseguirá la máxima calidad implementando pruebas E2E de los flujos de negocio más críticos. Las pruebas E2E pueden salir caras al principio para capturar y registrar la secuencia del flujo del usuario. Si el producto de software no está realizando rápidas publicaciones diarias, puede salir más económico disponer de un equipo humano que ejecute de forma manual los planes de pruebas E2E.

2. Pruebas unitarias

Como su nombre indica, las pruebas unitarias abarcan unidades individuales de código. La mejor forma de medir las unidades de código es en las definiciones de las funciones. Una prueba unitaria abarcará una función individual. Las pruebas unitarias afirmarán que la entrada esperada a una función coincide con la salida esperada. El código que tiene cálculos confidenciales (como puede ser el de las finanzas, la sanidad o el sector aeroespacial) se cubre mejor con pruebas unitarias. Dichas pruebas son económicas y rápidas de implementar; además, proporcionan un alto retorno de la inversión.

3. Pruebas de integración

A menudo, una unidad de código realizará una llamada externa a un servicio de terceros, pero el código base principal que se está probando no tendrá acceso al código de este. Las pruebas de integración se encargan de burlarse de estas dependencias de terceros y de asegurar que el código que interactúa con ellas se comporta según lo previsto.

Las pruebas de integración son similares a las pruebas unitarias en la forma en que se escriben y en sus herramientas. Las pruebas de integración pueden ser una alternativa económica a las pruebas E2E; sin embargo, el retorno de la inversión es discutible cuando la combinación de pruebas unitarias y E2E ya está en marcha.

4. Pruebas de rendimiento

Cuando se utiliza en el contexto del desarrollo de software, el “rendimiento” se usa para describir la velocidad y la capacidad de respuesta de un proyecto de software. Algunos ejemplos de métricas de rendimiento son: “tiempo de carga de la página”, “tiempo de la primera visualización” o “tiempo de respuesta de los resultados de la búsqueda”. Las pruebas de rendimiento crean mediciones y afirmaciones para estos casos de ejemplo. Las pruebas de rendimiento automatizadas ejecutarán casos de prueba en estas métricas y, a continuación, alertarán al equipo sobre cualquier regresión o pérdida de velocidad.

¿Qué tipos de pruebas de software se deben hacer de forma manual?

Se puede decir que se debería automatizar cualquier prueba que presente la oportunidad de hacerlo. Supone una gran ganancia en productividad y coste de tiempo en lo que respecta al personal. Dicho esto, hay veces en que el ROI de desarrollar una serie de pruebas automatizadas no vale la pena en comparación con la ejecución de una prueba manual.

1. Pruebas exploratorias

Las pruebas automatizadas tienen un script y siguen una secuencia de pasos para validar el comportamiento. Las pruebas exploratorias son más aleatorias y prueban secuencias sin script para encontrar errores o comportamientos inesperados. Aunque existen herramientas de software para establecer una serie de pruebas exploratorias de software, aún no están totalmente desarrolladas ni se han adoptado de forma generalizada. Puede ser mucho más eficiente asignar un tester manual de control de calidad y utilizar la creatividad humana para descubrir cómo encontrar puntos débiles en un producto de software.

2. Pruebas de regresión visual

Una regresión visual ocurre cuando se introduce un defecto de diseño visual en la interfaz de usuario del software. Puede tratarse de elementos de la interfaz de usuario mal colocados, una fuente incorrecta, colores erróneos, etc. Al igual que con las pruebas exploratorias, existen herramientas para escribir pruebas automatizadas con el fin de detectar estas regresiones. Dichas herramientas realizan capturas de pantalla de varios estados de un producto de software y, a continuación, utilizan OCR para compararlas con los resultados esperados. El desarrollo de estas pruebas es caro y las herramientas no están muy extendidas. Puede ser mucho más eficaz que una persona observe algo y vea si hay alguna incidencia visual.

3. Desarrollo de un marco de automatización de pruebas para tu equipo de DevOps

No existe una solución integral para las pruebas automatizadas. A la hora de planificar una solución de pruebas automatizadas para tu equipo, hay que tener en cuenta algunas consideraciones clave.

4. Frecuencia de publicación

En el caso de los productos de software que se publican en intervalos fijos, como mensual o semanalmente, las pruebas manuales son más adecuadas. Los productos de software que se publican con más rapidez se beneficiarán en gran medida de las pruebas automatizadas, ya que la CI y la CD dependen de ellas.

5. Herramientas y ecosistema disponibles

Cada lenguaje de programación tiene su propio ecosistema de herramientas y utilidades complementarias. Cada tipo de patrón de prueba automatizada tiene su propia serie de herramientas que pueden o no estar disponibles en un ecosistema de lenguajes de programación en particular. La implementación correcta de un patrón de pruebas automatizadas requerirá una intersección entre el lenguaje y el soporte de herramientas.

6. Adecuación del producto al mercado y desarrollo de la base de código

Si tu equipo está trabajando en el desarrollo de un producto nuevo que aún no ha probado un público objetivo o un modelo empresarial, puede que no tenga sentido invertir en pruebas automatizadas. Dichas pruebas actúan como un mecanismo de seguro para restringir las regresiones de código inesperadas. Si tu equipo se mueve a gran velocidad, puede salir bastante caro tener que actualizar y mantener las pruebas automatizadas cuando el código cambia de manera drástica y rápida.

Pruebas automatizadas como parte de la canalización de CD

Las pruebas automatizadas son una práctica estándar del desarrollo de software moderno. Los mejores equipos y empresas utilizan dichas pruebas. La CI y la CD dependen de las pruebas automatizadas; son fundamentales para ayudar a los mejores equipos a lanzar software fiable y coherente para los clientes.

Open DevOps de Atlassian es una plataforma de cadena de herramientas abierta con la que podrás compilar una canalización de desarrollo basada en CD con tus herramientas favoritas. Descubre cómo Atlassian y las herramientas de terceros pueden integrar pruebas en tu flujo de trabajo con nuestros tutoriales sobre pruebas de DevOps.