Hoy en día la automatizacion de pruebas ha dado lugar para la sustitición de la mano de obra. Hace algunos años, el trabajo del probador o analista de pruebas solo se limitaba a la documentación, los informes y las pruebas manuales.

Antes de la automatización de pruebas los trabajadores mantenían un estrecho contacto con el analista de requisitos o el director del proyecto y, basándose en los requisitos del sistema, iniciaban la tarea de transformar los casos de uso del sistema en casos de prueba.

¿Cómo evolucionó la automatizacion de pruebas?

Las pruebas se recopilaron en un documento que serviría de base para seguir su ejecución, como una lista de comprobación que debería validarse en cada versión del sistema.

Esta compilación es bien conocida como Plan de Pruebas y además de contener todo esto paso a paso, también tenía otras informaciones importantes para la conducción de las pruebas, tales como:

Alcance, configuraciones del ambiente, datos que componían la masa de pruebas a ser utilizadas, roles y responsabilidades de los involucrados, fechas para la ejecución, ventanas de mantenimiento, diccionario de datos, métricas y una infinidad de informaciones que servirían de apoyo a esta etapa fundamental en el ciclo de vida del software.

La cantidad de casos de prueba podría llegar fácilmente a cientos, dependiendo de la complejidad del sistema. Muchas veces, esta documentación se guardaba en archivos de Office Word (.doc) o Excel (.xls), lo que complicaba su mantenimiento.

Un simple cambio en el nombre del botón tendría que modificarse en decenas de páginas de este documento. ¿Imagina una norma más compleja, algún requisito previo?

Esta documentación también funcionaba como entregables definidos en las actas de las reuniones y en las auditorías internas, y este enfoque de un documento más rígido era posible gracias al modelo de desarrollo que teníamos mayoritariamente en las empresas llamado Waterfall. Este modelo seguía una línea de fases secuenciales o, como su nombre indica, una cascada.

Las primeras herrramientas esclusivas para la automatización de pruebas empezaron a surgir en este último periodo. Algunas de ellas surgieron incluso de empresas como Microsoft e IBM, como IBM Rational, por ejemplo. 

Paralelamente, las metodologías de desarrollo de software fueron evolucionando hacia unas más ágiles, menos rígidas, con muchas iteraciones y entregas, y sujetas a constantes cambios en los requisitos para la automatización de pruebas.

En una búsqueda rápida en Internet, es posible ver miles de blogs, artículos y libros que hablan de Agile, Lean, SCRUM, Kanban, etc. También empezaron a surgir otras metodologías que introducen las pruebas en una fase temprana del código y se centran en el comportamiento y/o el dominio del software: DDD, TDD, BDD.

Los programadores escribieron sus pruebas, los equipos dieron los primeros pasos en las metodologías ágiles y los profesionales de las pruebas de software se introdujeron en el desarrollo, buscando formas de automatizar las pruebas repetitivas que se producían en cada iteración.

Se notó un movimiento de convergencia de esfuerzos de todo el equipo para entregar la máxima calidad incorporada en los productos, que se aplica en las empresas hasta hoy, incluso aquí, en VTEX.

Complejidad y aumento exponencial de los sistemas.

Hemos llegado a un momento en el que tenemos diferentes navegadores web, cada uno con sus propias particularidades, y dos sistemas operativos principales para dispositivos móviles. Hay una gran cantidad de estos dispositivos con diferentes tamaños de pantalla y resoluciones.

Para seguir el ritmo de estos cambios, han surgido servicios de pruebas entre navegadores y dispositivos que ayudan a potenciar las pruebas automatizadas, dando más velocidad y flexibilidad a los scripts. Estos servicios tienen en común la provisión de una infraestructura en la nube y la facilidad de paralelización de las ejecuciones de las pruebas.

Además de los diferentes navegadores y tamaños de pantalla, la validación entre diferentes versiones de un mismo navegador y/o sistema operativo es también una preocupación constante. Por ejemplo, una página web puede funcionar perfectamente en una versión X del navegador, pero se producen fallos en una versión Y.

Muchas veces la versión Y debe ser soportada por el sistema, por razones contractuales, de relación con el cliente u otras, incluso si el propio fabricante ya no soporta esa versión.Además, también han aumentado las pruebas de los requisitos no funcionales.

Por ejemplo, tenemos aplicaciones de vídeo en streaming que deben seguir funcionando incluso con poca señal de la antena de telefonía, sistemas que utilizan recursos internos de los dispositivos como el acelerómetro y multitud de pequeños detalles que pueden aumentar aún más el alcance de las pruebas.

En resumen, se observa que la complejidad, las dimensiones y los retos de las pruebas de software han aumentado a un ritmo exorbitante y así sigue.Toda esta transformación también ha repercutido en el perfil del profesional de las pruebas de software. Este profesional es más capaz de escribir código, utilizando herramientas DevOps y sistemas de integración continua, por ejemplo.

Esta transformación puede observarse fácilmente a través de la nomenclatura que han recibido a lo largo de los años. Hoy en día, tenemos numerosos términos para identificar un perfil que, a pesar de tener algunas características distintas en sus funciones, es básicamente un perfil que comparte el sentimiento de propietario del producto y tiene un enfoque en la calidad.

Podemos quedarnos aquí enumerando varios: Probador de Software, Analista de Pruebas, Analista de Calidad, Analista de QA, Gestor de Pruebas, Probador Ágil, Analista de Automatización de Pruebas, Analista de Garantía de Calidad, Ingeniero de Pruebas, etc.

El futuro ya está con nosotros.

Estamos rodeados de datos y cada vez surgen más aplicaciones basadas en ellos. Este tipo de aplicaciones dificulta el uso de técnicas de comprobación tradicionales, como la partición de equivalencias o el análisis de valores límite, porque las respuestas no son necesariamente binarias.

Por ejemplo: en aplicaciones de Inteligencia Artificial, Machine Learning, aplicaciones de reconocimiento de voz, reconocimiento facial y reconocimiento de imágenes en general, ¿cómo validar que un sistema ha reconocido correctamente un gato en la imagen? Sabemos que en estos sistemas hay falsos positivos y mucho fondo en las estadísticas.

¿Vamos a tener cada vez más profesionales cualificados para la tecnología y el hardware integrados? Vienen muchos asistentes virtuales y con ellos muchos retos para la automatización de pruebas.

La formación en estadística y ciencia de los datos puede ser un camino a seguir por estos profesionales.