¿Qué es la automatización de pruebas? Una Introducción Simple y Clara
Hay dos tipos de pruebas en el mundo del software-manuales y automatizadas. Algunos tipos de pruebas manuales, como las pruebas de descubrimiento y las pruebas de usabilidad, son inestimables. Usted puede hacer otros tipos de pruebas-como las pruebas de regresión y pruebas funcionales-manualmente, pero es una práctica bastante inútil para los seres humanos a seguir haciendo lo mismo una y otra vez. Es este tipo de pruebas repetitivas que se prestan a la automatización de pruebas.
La automatización de pruebas es la práctica de la ejecución de pruebas de forma automática, la gestión de los datos de prueba, y la utilización de los resultados para mejorar la calidad del software. Es principalmente una medida de garantía de calidad, pero sus actividades implican el compromiso de todo el equipo de producción de software. Desde los analistas de negocios hasta los desarrolladores y los ingenieros de DevOps, sacar el máximo provecho de la automatización de pruebas requiere la inclusión de todos.
Este post le dará una comprensión de alto nivel de lo que es la automatización de pruebas. Hay todo tipo de pruebas, pero no todas deben ser automatizadas; por lo tanto, vamos a empezar con los criterios generales para la automatización de pruebas.
Criterios para la automatización
Una prueba necesita cumplir con algunos criterios para ser automatizada- de lo contrario, podría terminar costando más de lo que ahorra. Después de todo, uno de los principales objetivos de la automatización es ahorrar tiempo, esfuerzo y dinero. He aquí algunos criterios generales para la automatización de pruebas. Se trata de puntos de partida. Sus criterios pueden ser diferentes dependiendo de sus circunstancias.
Repetible
La prueba debe ser repetible. No tiene sentido automatizar una prueba que sólo se puede ejecutar una vez. Una prueba repetible tiene los siguientes tres pasos:
- Crear la prueba, incluyendo los datos y el entorno.
- Ejecutar la función y medir el resultado.
- Limpiar los datos y el entorno.
En el primer paso, queremos ser capaces de poner el entorno en un estado consistente. En otras palabras, si tenemos una prueba para intentar añadir un usuario existente, tenemos que asegurarnos de que el usuario existe antes de realizar la prueba. Una vez completada la prueba, el entorno debe volver al estado base.
Determinante
Cuando una función es determinante, significa que el resultado es el mismo cada vez que se ejecuta con la misma entrada. Lo mismo ocurre con las pruebas que se pueden automatizar. Por ejemplo, digamos que queremos probar una función de suma. Sabemos que 1 + 1 = 2 y que 394,19 + 5,81 = 400,00. La suma es una función determinante.
Los programas informáticos, por otra parte, pueden utilizar un número tan elevado de variables de entrada que es difícil obtener el mismo resultado a lo largo del tiempo. Algunas variables pueden incluso ser aleatorias, lo que puede dificultar la determinación del resultado específico. El diseño del software puede compensar esto permitiendo entradas de prueba a través de un arnés de pruebas.
Otras características de una aplicación pueden ser aditivas; por ejemplo, crear un nuevo usuario se sumaría al número de usuarios. Al menos cuando añadimos un usuario sabemos que el número de usuarios sólo debería crecer en uno. Sin embargo, la ejecución de pruebas en paralelo puede provocar resultados inesperados. El aislamiento puede evitar este tipo de falsos positivos.
Sin opinión
No se pueden automatizar las cuestiones de opinión. Aquí es donde realmente brillan las pruebas de usabilidad, las pruebas beta, etc. Las opiniones de los usuarios son importantes, pero no pueden ser automatizadas… ¡lo siento!
Tipos de pruebas automatizadas
Hay tantos tipos de pruebas, muchas de las cuales pueden ser automatizadas, que no podemos incluirlas todas en un solo post. Pero aquí hay suficientes para darle un buen punto de partida.
Análisis de código
En realidad hay muchos tipos diferentes de herramientas de análisis de código, incluyendo el análisis estático y el análisis dinámico. Algunas de estas pruebas buscan fallos de seguridad, otras comprueban el estilo y la forma. Estas pruebas se ejecutan cuando un desarrollador revisa el código. Aparte de configurar las reglas y mantener las herramientas actualizadas, no hay mucho que escribir con estas pruebas automatizadas.
Pruebas unitarias
También puede automatizar un conjunto de pruebas unitarias. Las pruebas unitarias están diseñadas para probar una sola función, o unidad, de operación de forma aislada. Normalmente se ejecutan en un servidor de compilación. Estas pruebas no dependen de bases de datos, APIs externas o almacenamiento de archivos. Tienen que ser rápidas y están diseñadas para probar sólo el código, no las dependencias externas.
Pruebas de integración
Las pruebas de integración son un tipo diferente de animal cuando se trata de la automatización. Dado que una prueba de integración -a veces llamada pruebas de extremo a extremo- necesita interactuar con dependencias externas, son más complicadas de configurar. A menudo, es mejor crear recursos externos falsos, especialmente cuando se trata de recursos fuera de su control.
Si usted, por ejemplo, tiene una aplicación de logística que depende de un servicio web de un proveedor, su prueba puede fallar inesperadamente si el servicio del proveedor está abajo. ¿Significa esto que su aplicación está rota? Puede ser, pero deberías tener suficiente control sobre todo el entorno de pruebas para crear cada escenario de forma explícita. Nunca dependa de un factor externo para determinar el resultado de su escenario de prueba.
Pruebas de aceptación automatizadas
Hay varias prácticas hoy en día que utilizan pruebas de aceptación automatizadas (AAT), pero básicamente están haciendo lo mismo. El desarrollo impulsado por el comportamiento (BDD) y el desarrollo impulsado por pruebas de aceptación automatizadas (AATDD) son similares. Ambos siguen la misma práctica de crear la prueba de aceptación antes de desarrollar la característica.
Al final, la prueba de aceptación automatizada se ejecuta para determinar si la característica ofrece lo que se ha acordado. Por lo tanto, es fundamental que los desarrolladores, el negocio y el control de calidad escriban estas pruebas juntos. Sirven como pruebas de regresión en el futuro, y garantizan que la característica cumple con lo que se espera.
Pruebas de regresión
Sin AATs en su lugar, usted tiene que escribir pruebas de regresión después del hecho. Aunque ambas son formas de pruebas funcionales, la forma en que se escriben, cuándo se escriben y quién las escribe son muy diferentes. Al igual que las AAT, pueden realizarse a través de una API mediante código o una interfaz de usuario. Existen herramientas para escribir estas pruebas utilizando una interfaz gráfica de usuario.
Pruebas de rendimiento
Existen muchos tipos de pruebas de rendimiento, pero todas ellas prueban algún aspecto del rendimiento de una aplicación. ¿Aguantará la presión extrema? ¿Estamos probando el sistema para el alto calor? Es el simple tiempo de respuesta bajo carga lo que buscamos? ¿Qué hay de la escalabilidad?
A veces estas pruebas requieren emular un número masivo de usuarios. En este caso, es importante tener un entorno que sea capaz de realizar tal hazaña. Existen recursos en la nube para ayudar en este tipo de pruebas, pero también es posible utilizar recursos locales.
Pruebas de humo
¿Qué es una prueba de humo? Es una prueba básica que se suele realizar después de una ventana de despliegue o mantenimiento. El propósito de una prueba de humo es asegurar que todos los servicios y dependencias están en funcionamiento. Una prueba de humo no pretende ser una prueba funcional completa. Puede ser ejecutada como parte de un despliegue automatizado o desencadenada a través de un paso manual.
Proceso general de automatización de pruebas
Ahora que hemos visto los criterios para la automatización y suficientes tipos de pruebas automatizadas para tener una idea de las cosas, aquí está el proceso general de automatización de pruebas. Hay tres pasos principales para la automatización de pruebas: preparar, tomar medidas, informar de los resultados.
Preparar
Primero, tenemos que preparar el estado, los datos de la prueba, y el entorno en el que las pruebas tienen lugar. Como hemos visto, la mayoría de las pruebas requieren que el entorno esté en un determinado estado antes de que se realice una acción. En un escenario típico, esto requiere cierta preparación. O bien los datos tendrán que ser manipulados o la aplicación tendrá que ser puesto en un estado específico o ambos!
Tomar Acción
Una vez que el estado y / o el medio ambiente está en el estado predefinido, es el momento de tomar acción! El controlador de prueba ejecutará la prueba, ya sea a través de la llamada a la API de una aplicación o la interfaz de usuario o ejecutando el código directamente. El controlador de pruebas es responsable de «conducir» las pruebas, pero el sistema de gestión de pruebas asume la responsabilidad de coordinar todo, incluyendo la presentación de informes de resultados.
Informar de los resultados
Un sistema de automatización de pruebas registrará e informará de los resultados. Estos resultados pueden venir en un número de diferentes formatos y pueden incluso crear tickets de problemas o errores en un sistema de seguimiento de trabajo. El resultado básico, sin embargo, es un aprobado o un suspenso. Por lo general, hay un indicador verde o rojo para cada escenario de prueba para indicar el pase o el fracaso.
A veces, las pruebas no son concluyentes o no se ejecutan por alguna razón. Cuando esto sucede, el sistema de automatización tendrá un registro completo de la salida para que los desarrolladores puedan revisar. Este registro les ayuda a rastrear el problema. En el mejor de los casos, podrán reproducir el escenario una vez que hayan puesto una solución.
La conclusión
La conclusión es la siguiente: la automatización de las pruebas ayuda a mejorar la calidad con rapidez. Pero no todas las pruebas pueden ser automatizadas. Definitivamente hay una inversión involucrada. Con tantos tipos de pruebas, es importante que consigas la combinación adecuada. La pirámide de pruebas es una sencilla regla general que ayuda a conseguirlo. Dice que la mayoría de las pruebas deben ser pruebas unitarias, seguidas por las pruebas de servicio, y luego las pruebas de interfaz de usuario.
Un sistema de automatización de pruebas coordina las preocupaciones de las pruebas, incluyendo la gestión de los datos de prueba, la ejecución de las pruebas y el seguimiento de los resultados. La automatización de pruebas es el siguiente paso para los equipos que se están viendo abrumados por la carga de repetir las mismas pruebas manuales que deberían ser automatizadas.
Biografía del autor: Este post fue escrito por Phil Vuollet. Phil utiliza software para automatizar procesos para mejorar la eficiencia y la repetibilidad. Escribe sobre temas relevantes para la tecnología y los negocios, ocasionalmente da charlas sobre los mismos temas, y es un hombre de familia que disfruta jugando al fútbol y a juegos de mesa con sus hijos.