¿La automatización de pruebas reemplaza al Tester?

humano robot

Muy frecuentemente, surge este tema, ya sea como pregunta o como materia de discusión. Algunos parecen tener la fantasía de reemplazar a los Testers por un conjunto de pruebas automatizadas, que presionando un botón garanticen la calidad de un producto. Sin embargo, las cosas no son tan sencillas, y se corre el riesgo de perderse una parte importante de los beneficios de una prueba bien realizada.

Existen, dentro de la labor del Tester, dos conjuntos de actividades o tareas bien diferenciados.

Por un lado, tareas que son estructuradas, esquemáticas e incluso repetitivas. En este grupo, podemos incluir a las que en el mundo ágil se conocen como story tests, que son aquellos tests que se encargan de verificar que se cumplen los criterios de aceptación de cada una de las user stories. Estas pruebas normalmente cubren el camino feliz o correcto, es decir, la forma normal o esperada de utilizar la aplicación. Son bastante lineales, ya que surgen directamente de los criterios de aceptación. Contando con estos, el diseño de los tests no requiere mayor esfuerzo, y su ejecución no produce mayor emoción.

En este grupo también podemos incluir a las pruebas de regresión. Estas pruebas son fundamentalmente repetición de tests que ya se han realizado, con el objetivo de verificar que no se han introducido nuevos errores. Y son reiterativas por naturaleza. Es decir, que ante cada modificación que se le realiza al sistema, deben ejecutarse las mismas pruebas de regresión. Una y otra vez. No es difícil imaginar que en desarrollos con numerosas iteraciones, las pruebas de regresión llegan a ser la pesadilla del Tester.

De acuerdo a sus características, los tipos de pruebas que incluimos en este primer grupo son ideales para automatizar. Tanto las story tests como las pruebas de regresión, al ser estructuradas y repetitivas, qué mejor que dejarlas en manos de un robot. Por un lado, cualquier Tester estará de acuerdo en que son aburridas, de manera que le haremos un gran favor si se las ahorramos. Por otro lado, el robot nos garantiza una ejecución eficiente: no sólo van a ser más rápidas, sino que podremos estar seguros de que no se olvidará de nada y cumplirá al pie de la letra con todos los pasos necesarios para la ejecución de cada uno de los tests.

Ahora bien, del otro lado, tenemos otro conjunto de pruebas de características totalmente distintas. Son las que llamamos pruebas exploratorias. Estas pruebas son desestructuradas y requieren de creatividad. Típicamente, el Tester se sienta ante la aplicación y va ejecutando pruebas a medida que va descubriendo las funcionalidades, sin otra guía que su experiencia y creatividad. Muchas veces, estas pruebas se utilizan para suplir la falta de documentación. En muchos otros casos, son el complemento de las pruebas anteriores. La gran ventaja de este tipo de tests es que suelen revelar fallas desconocidas, aquello en lo que nadie pensó y la creatividad del Tester supo sacar a la luz.

Para este tipo de pruebas, los robots no son apropiados. Se necesita una persona, un Tester que además cuente con buenas habilidades y vasta experiencia, que va a combinar con su creatividad para descubrir aquello en lo que nadie pensó. Esta es la tarea que suele resultar más gratificante, desafiante y entretenida para los Testers, y la que nunca se van a aburrir de ejecutar. Es lo que hace el trabajo del Tester interesante y divertido.

En suma, ¿La automatización de pruebas reemplaza al Tester? En parte sí, y está bien que lo haga, en cuanto se enfoque en aquellas tareas repetitivas y estructuradas, que para un ser humano resultan monótonas y aburridas. Y en parte no, ya que no se puede encomendar a un robot una tarea desestructurada y creativa como el test exploratorio. Para eso es imprescindible un ser humano.

Lo que hay que entender, es que no conviene robotizar a un ser humano, poniéndolo a ejecutar tareas repetitivas, ni humanizar a un robot, esperando que aporte creatividad o pensamiento lateral. Para que los resultados sean exitosos, debemos aplicar cada recurso en lo que mejor sabe hacer.

Anuncios

Una iteración en la vida del Tester

Con la llegada de las metodologías ágiles, el rol del Tester sufrió una transformación. Una de las principales diferencias con otras metodologías es el ritmo de las tareas de testing, que se expanden a lo largo de cada uno de los ciclos de desarrollo ágil, llamados iteraciones.

iteracion tester

Cómo son, día por día, las tareas del Tester durante cada una de esas iteraciones?

Día 1: En el primer día de cada iteración, las user stories de más alta prioridad se van tomando del backlog. El Tester, junto con el resto del equipo y el Product Owner, deberán trabajar en definir los criterios de aceptación para cada una de esas user stories. Es el momento de formular las preguntas de más alto nivel, para ir delineando la funcionalidad que entregará cada una de las user stories, como así también cuál va a ser el valor que le aportará al negocio.

Durante la segunda parte de la sesión de planificación, deberán identificarse y estimarse las tareas de testing para cada una de las stories. Típicamente, las tareas de testing son: “Definir casos de prueba”, “Escribir tests automatizados”, “Ejecutar prueba exploratoria”.

Días 2 y 3: En estos días, la principal tarea del Tester consiste en mantener conversaciones con el Product Owner, con el objetivo de refinar los criterios de aceptación para cada una de las user stories. La buena comunicación es clave en esta etapa, porque le permitirá al Tester dilucidar en detalle qué es lo que se espera de cada una de las funcionalidades. Este es un proceso que bien puede continuar en los días subsiguientes.

Asimismo, durante estos días, el Tester comenzará a diseñar los tests de aceptación. Esto debe verse como una tarea colaborativa, que ayudará a guiar el desarrollo, en la medida en que los desarrolladores escriban el código que pase esos tests. Esta tarea de escribir tests de aceptación continuará durante los siguientes días. Normalmente, el proceso de diseñar estos tests disparará nuevas preguntas, que generarán nuevas charlas con el Product Owner, a fin de continuar refinando los criterios de aceptación.

Días 4 y 5: Aquí es donde suele comenzar el test exploratorio, ya que normalmente ha finalizado el desarrollo de algunas de las user stories. Entonces, una vez que se ha asegurado de que los tests del “camino correcto” pasan, el Tester comienza a usar su creatividad para pensar en condiciones o escenarios en los que nadie pensó, y de esa forma encontrar errores inesperados. Generalmente, se seguirán ejecutando pruebas exploratorias hasta casi el final de la iteración.

Días 6 y 7: En la medida en que se van desarrollando más user stories, el Tester comienza a ejecutar pruebas que buscan verificar funcionalidades combinadas o integradas. El objetivo es asegurarse de que las nuevas funcionalidades se integran correctamente con las funcionalidades pre-existentes. Esta tarea seguirá adelante por un par de días por lo menos. El éxito de esta tarea depende en gran medida de que las user stories estén diseñadas correctamente

Días 8 y 9: Asumiendo que el desarrollo de todas las user stories está completo hacia el 8vo. ó 9no. día, es el momento de ejecutar pruebas end-to-end, que verifiquen tantos escenarios como sea posible, siempre basándonos en casos reales de uso del sistema. El principal objetivo de estas pruebas es verificar que todas las nuevas funcionalidades aumentan el valor del software para el negocio y que el mismo se halla en condiciones de ser entregado al cliente o usuario final.

Día 10: En el último día de la iteración, el equipo realiza una demostración de las user stories al Product Owner, buscando obtener su aceptación. Esta demo generalmente requiere un armado cuidadoso, como generar los datos necesarios o asegurarse de que todas las funcionalidades están listas para ser demostradas. Así, el equipo completo se concentrará en generar una versión que pueda ser presentada al cliente. El Tester, por ser quien está más familiarizado con las funcionalidades, suele ser el encargado de llevar adelante la demostración.

Asimismo, como cierre de la iteración, se suele realizar una reunión denominada retrospectiva, donde todo el equipo analiza la marcha de la iteración que está concluyendo, resaltando los aspectos positivos (que deben repetirse) y los que se pueden mejorar. El Tester aportará su visión a esa retrospectiva.

Aclaración: La duración de cada una de estas tareas no es taxativa, sino más bien indicativa, y puede variar de un proyecto a otro. Es decir, que algunas tareas podrían comenzar antes o después de lo indicado más arriba, y prolongarse por más tiempo, incluso más allá del final de la iteración.