Testing Ágil: ¿eso qué es?

Agile Testing, Testing Ágil, Agile Tester, … Mucho se ha escrito sobre esto, pero realmente ¿qué significa?

En este artículo voy a tratar de plasmar la información que he ido recopilando de diversas fuentes para ofrecer una visión clara de lo que significa el testing ágil. Casi toda la información la he conseguido del libro Growing Agile: A Coach’s Guide to Agile Testing y del Agile Testing de Lisa Crispin. También te contaré algunos casos reales que me han sucedido a mí, o que me han contado 🙂

¿Cómo encaja un proceso tradicional de calidad en un desarrollo ágil?

Recordemos el Manifiesto Ágil:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

– Individuos e interacciones sobre procesos y herramientas

– Software funcionando sobre documentación extensiva

– Colaboración con el cliente sobre negociación contractual

– Respuesta ante el cambio sobre seguir un plan

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Manifiesto ágil

Un proceso de calidad tradicional suele ser «pesado». Necesita una documentación exhaustiva sobre los requerimientos del sistema y los casos de prueba que los probarán. Tendrá una serie de requerimientos de calidad que determinarán si el software «aprueba o suspende». Todo esto se hará en función de un Test Plan en base a fechas, recursos, etc. que se establece al principio del proyecto.

Para conseguir lo que el cliente necesita, este proceso no pone el énfasis en los individuos, el software funcionando, la colaboración y la respuesta al cambio -lo que promueve el movimiento ágil-, sino que se ciñe a planificaciones en función de una documentación necesariamente exhaustiva, contratos cerrados y poca colaboración.

Así que… ¿cómo encaja un proceso de calidad tradicional en el mundo ágil? La respuesta corta es que no encaja. Las organizaciones que conozco que lo han intentado han acabado haciendo mini-waterfall: un sprint de desarrollo seguido de un sprint de testeo, con suerte.

Para entender qué buscamos con las actividades de testing y calidad en un desarrollo ágil tenemos que cambiar la mentalidad tradicional. Pensar de forma diferente. Por eso te presento ¡el Manifiesto del Testing Ágil!

Ver el testing como una actividad en vez de como una fase

Tradicionalmente, las pruebas son una fase que va después del desarrollo. En metodologías ágiles, lo que algunos han cambiado es que el trozo que se desarrolla es más pequeño, pero las pruebas se siguen haciendo al final. No cambia nada respecto a metodologías tipo waterfall.

Ejemplo: En un trabajo tuvimos que probar un programa de instalación que actualizaba un software. El desarrollador hacía cambios en ese instalador y se lo pasaba a una tester que lo ejecutaba y comprobaba que los pasos de instalación eran correctos (pantallas, idiomas...) y que los archivos se actualizaban.

Sin embargo, ocurría algo una y otra vez: cada vez que la tester arrancaba el instalador, mostraba un error en la primera o segunda pantalla. Reportaba el error y lo enviaba de vuelta al desarrollador. Una y otra vez. El programador hacía cambios y ni siquiera hacía una ejecución de prueba, simplemente lanzaba "la bola" para que "lo pruebe QA". 

Esta forma de trabajar es lenta y frustrante. ¿No habría sido más productivo que el programador hubiera hecho alguna prueba básica antes de enviar el software a la tester? O mejor aún, ¿y si trabajaran juntos?

Una forma sencilla de saber si esto te está pasando es ver como está organizado tu cuadro de tareas. Si tienes una columna para test, esto es una señal de que las pruebas todavía se consideran una fase.

En testing ágil, las pruebas son una actividad que se hace junto al desarrollo. Pensar de esta manera hace que sea posible considerar la idea de realizar tareas de pruebas antes de comenzar el trabajo de implementación.

Hay tareas de calidad que pueden hacerse antes de empezar el desarrollo. Por ejemplo, trasladar los criterios de aceptación a tests automatizados. Estos tests deberían fallar, pero una vez que se escribe el código, las pruebas ya pasarán correctamente. Escribí sobre esto hace algún tiempo en este artículo: Encuentra bugs antes de que nazcan con Story Testing

Trabajar de esta manera elimina la idea de que las pruebas son siempre algo que se hace al final.

Una forma de visualizar esto es que, en lugar de tener una columna para test en tu cuadro de tareas, las tareas de test tengan un post-it de diferente color (si tu cuadro es físico) o un tipo diferente. Por ejemplo si usas Jira, las tareas de test podrían tener un icono diferente. En esta entrada te cuento más: Cómo gestionar tareas de Agile Testing con JIRA y sin plugins

Otra técnica útil es añadir una columna «Revisar» después de “En Progreso». Muchos equipos hacen revisiones de código o de los casos de prueba en cada historia. La idea de esta columna es hacer una revisión de cada tarea tan pronto como se termine. Si las tareas son pequeñas, serán revisiones cortas, que aseguran que al menos dos personas en el equipo han visto cada pedacito de trabajo. Esto puede ayudar a detectar y solucionar problemas.

Mejor prevenir bugs que encontrarlos

Otra de las ideas comúnmente aceptadas es que el objetivo de las pruebas es encontrar errores. De hecho, algunas organizaciones miden la productividad del tester en función del número de errores que encuentra. Esta forma de pensar limita el alcance del testing y refuerza la idea de que las pruebas son algo que se hace al final.

El testing ágil tiene como objetivo prevenir errores. Busca eliminar suposiciones e incógnitas antes de empezar a programar, para eso es fundamental que cliente, desarrollador y tester tengan la misma comprensión de cómo debe funcionar algo.

Un ejemplo del libro Growing Agile: A Coach's Guide to Agile Testing que utilizo en los talleres es el siguiente: un cliente pide crear un informe que muestre los datos de ventas promedio de los últimos seis meses. ¿Qué preguntas harías al cliente para implementarlo? Aunque el requisito parece bastante obvio, surgen muchas preguntas como:
- Si ejecuto el informe el 2 de febrero, ¿los datos de febrero están incluidos o no?
- ¿Cómo debería calcularse el promedio?
- ¿Quién puede tener acceso al informe?
- ¿En qué formato debe salir?
- ¿Es necesario almacenar el informe o se creará cada vez que alguien lo ejecute?
- ¿Quién usará el informe y por qué lo necesita?
- etc.

Cuando la lista llega a unas 10-12 preguntas, les digo: cada pregunta que no hagáis, pero sí implementéis, lo haréis en base a una suposición y será como tirar una moneda al aire, a ver si acertáis. Imagina el retrabajo y los errores que podrían salir si programarais este requisito sin saber las respuestas a estas preguntas.

La mejor manera de prevenir errores es hacer preguntas. No hay que tener miedo de hacer preguntas que parezcan obvias. En los refinamientos de las historias de usuario hay que sacar a la luz cualquier suposición. Aquí es donde se empiezan a prevenir los defectos.

Es importante entender por qué se necesita algo y cómo se puede probar. Si hay muchas maneras de interpretar algo, discutir con todo el equipo las opciones hasta que todos tengan la misma imagen de lo que se quiere hacer.

Otro buen momento para preguntar es en la reunión diaria (si trabajas en SCRUM). Escucha lo que dicen los demás y pon atención a frases como «yo pensaba» o “yo esperaba que…». Esto significa que se habían hecho suposiciones erróneas. Pregunta para entender qué pasa y asegúrate de que todo el equipo lo tenga claro para evitar futuros malentendidos.

¿Esto quiere decir que no es importante encontrar errores? No, en absoluto. Sigue siendo vital encontrar encontrar errores antes de que salgan a producción. Pero prevenir un error o detectarlo en una fase temprana ahorra muchísimo tiempo en su arreglo. Tiempo valioso que podemos dedicar a entregar más valor a nuestros usuarios o clientes.

¿Verificas o pruebas?

Hay testers a los que les cuesta entender los métodos ágiles porque sin documentos de especificación detallados no pueden hacer pruebas.
Esto sucede porque consideran que su trabajo es comparar cómo funciona un software respecto a su especificación e informar de las discrepancias.

Lo único que el tester está haciendo es comprobar cómo los desarrolladores siguieron unas especificaciones. Nada más. Dice poco sobre la calidad de un producto o, lo más importante, si es adecuado para el propósito para el que fue creado. A este trabajo lo llamamos ‘verificar’ (check en inglés).

¿Sabes quiénes son realmente buenos verificando cosas? Los ordenadores. En las pruebas ágiles, el trabajo de verificación debe automatizarse para que los testers puedan liberarse y hacer el tipo de trabajo que las máquinas no pueden hacer, como participar en los refinamientos de las historias de usuario, pruebas exploratorias, de usabilidad, etc.

En testing ágil, los testers son los representantes de los usuarios. Deben asegurar que el producto satisface sus necesidades reales. Pero para poder hacer este trabajo necesitan entender quiénes son sus usuarios y lo que están tratando de lograr con el producto.

Cuando un usuario solicita una función, es importante preguntar: «¿Cómo lo probarías?» o «¿Cómo sabrás si funciona?«. Estas preguntas ayudan a comprender el resultado de lo que el cliente está buscando. Después hay que trasladar estas respuestas a criterios de aceptación para que el equipo pueda garantizar que el producto hace lo que se pidió.

En resumen: No seas un verificador, sé un tester.

Ayudar a construir en lugar de destruir

Una de las cosas que se piensa de los testers es que les gusta romper cosas. El problema con esta forma de pensar es que crea una división entre los desarrolladores y los testers: Los desarrolladores construyen, y los testers intentan romperlo. Esto también refuerza la idea de que las pruebas son una fase que se hace al final.

Pero en el mundo del agilismo la labor de los testers es ayudar a construir el mejor sistema posible. No deben celebrar cuando encuentran un error, sino cuando el producto funciona y resuelve un problema.

La mejor forma de trabajar en este sentido es descubrir cómo probar el sistema desde el punto de vista del usuario y compartirlo con los desarrolladores antes de que comiencen a programar.

Una buena técnica es que el equipo de desarrollo (product owner, programadores, testers...) reciban los mismos cursos que hacen los usuarios finales del producto. Otra es acompañar a los usuarios reales en su día a día para entender cómo trabajan con nuestro software.

Escribir los casos de prueba siguiendo un enfoque BDD o ATDD ayuda a comprender lo que se espera del software y las necesidades de negocio que se quieren satisfacer.

Todo el equipo es responsable de la calidad

Tradicionalmente el tester o el equipo de QA es el responsable de la calidad. Son los que tienen la última palabra sobre si un producto está listo para ser puesto en producción o no.

El problema con esta forma de pensar es que implica que solo el tester se preocupa por la calidad. También refuerza la idea de que el testing sea una fase.

En testing ágil, todo el equipo es responsable de la calidad. Esto ayuda a los equipos a darse cuenta de que las pruebas son una actividad en la que todos participan.

Cuando los usuarios encuentren un error en producción, nadie debería preguntarle al tester por qué no lo encontró. Todo el equipo trabaja junto para solucionarlo y decidir acciones para evitar que vuelva a suceder en el futuro.

Es frecuente que los desarrolladores discutan sobre la implementación y los testers sobre las pruebas. Sin embargo, desarrolladores y testers deben discutir juntos cuáles son todas las tareas. Que todos entiendan cómo se garantizará la calidad es una excelente manera de ayudar a los equipos a tomar como propia la calidad del producto.

Una vez que se adopta esta mentalidad, los testers ya no son las únicas personas que tienen trabajo al final de un desarrollo, sino que todo el equipo está involucrado.

Manifiesto del Testing Ágil

En resumen, los cinco principios del testing ágil:

• Testear a lo largo del desarrollo sobre testear al final
• Prevenir errores sobre encontrar errores
• Entender qué se está probando sobre verificar funcionalidad
• Ayudar a construir el mejor sistema sobre romper el sistema
• Responsabilidad de todo el equipo sobre responsabilidad del tester

Por último no quiero dejar fuera la definición que dan Lisa Crispin y Janet Gregoy de Testing Ágil:

Prácticas de testing colaborativas que se realizan de forma continua, desde el inicio hasta la entrega y más allá, apoyando la entrega frecuente de valor para nuestros clientes. Las actividades de test se centran en incorporar la calidad en el producto, utilizando ciclos de retroalimentación rápidos para validarlo. Estas prácticas fortalecen y apoyan la idea de que la calidad es responsabilidad de todo el equipo. Donde:

– Incorporar la calidad en el producto significa que los equipos se centran en prevenir malentendidos sobre cómo deben comportarse las características, así como prevenir defectos en el código.
– Guiar el desarrollo con ejemplos concretos significa utilizar prácticas como ATDD (desarrollo guiado por pruebas de aceptación), BDD (desarrollo guiado por el comportamiento) o SBE (especificación por ejemplos).
– Las actividades de prueba incluyen (pero no se limitan a) conversaciones para construir una comprensión compartida, hacer preguntas para probar ideas y suposiciones, automatizar pruebas, realizar pruebas exploratorias, probar atributos de calidad como rendimiento, confiabilidad, seguridad y aprender del uso en producción.
– Todo el equipo utiliza retrospectivas y pequeños experimentos para mejorar continuamente las pruebas y la calidad y encontrar lo que funciona en su contexto.

https://agiletester.ca/ever-evolving-never-set-stone-definition-agile-testing/

Y hasta aquí todo, ¡deja tu comentario!