¿Cómo enfoco el testing de forma ágil?

Implantaciones de Scrum, formaciones, cursos, congresos, empresas a las que vamos desde 233 Grados de TI… En la mayoría de las ocasiones o veo o alguien saca a la luz un problema recurrente: “estamos implantando Scrum, agilidad, pero al final…nos quedamos a medias. Seguimos haciendo el testing al final, no tenemos tiempo. QA siempre retrasa al equipo de desarrollo.”
Y efectivamente, en forma de pensar, creo que esta frase, se encuentra a medio camino entre un pensamiento tradicional y la agilidad, por ejemplo tipo Scrum.
En mi opinión, en un enfoque tradicional, QA y desarrollo son dos mundos separados.
Desarrollo va por una parte, y QA es el departamento que verifica, que da el visto bueno o no, tras el desarrollo. Son dos mundos: cuando desarrollo termina, lo que pase después no es problema suyo, a no ser que se encuentren errores.
Y viceversa. A QA no le tiene por qué importar el desarrollo, solo verifican que esté todo ok.
Pero cuando vamos a un proyecto ágil, la cosa cambia. Uno de los principales objetivos de la agilidad es mejorar la calidad del software, que tu empresa pueda moverse rápido: desarrollar poco a poco y contrastar ese desarrollo con el cliente (subiendo a producción en ciclos más cortos, p.e al final de un sprint de 2 semanas, cada semana, cada vez que hacemos un cambio etc.), para saber que vamos en buen camino y si no rectificar.
Para responder rápido, necesitamos un entorno altamente colaborativo. Equipos multidisciplinares, capaces de producir incrementos y mejoras en el software con la calidad esperada. En un equipo hay gente de distinto tipo:
– Una parte técnica (distintos perfiles de desarrollo, sistemas etc.).
– Una parte de negocio (Product Owner).
– Los testers, están entre la parte técnica y la de negocio. Ayudan por un lado a la parte de negocio a traducir lo que el cliente quiere en pruebas, que será lo que debe cumplir el software, lo que en definitiva tienen que implementar los desarrolladores.
Un tester ágil aporta una visión intermedia entre desarrollo y negocio: entiende el punto de vista del usuario, pero a la vez, tiene conocimientos a alto nivel de la complejidad que conlleva desarrollar software.
El éxito del equipo es conseguir aportar lo que el cliente quiere. Y para ello tenemos que colaborar entre todos y cumplir todas las actividades necesarias para terminar una funcionalidad.
– Si desarrollo termina de implementar algo, pero el Product Owner no da el visto bueno, realmente la funcionalidad no está terminada.
– Lo mismo, si QA no da el ok a la tarea.
– Si desarrollo espera feedback por parte de QA y no se lo da, tampoco es agilidad.
Etc.
Testers, desarrollo, Product Owner…Son un equipo con un objetivo común. Si una parte no termina, el trabajo de todos no ha terminado.
Por eso una historia de usuario no implica solo actividades de desarrollo, sino que el testing y las pruebas de aceptación (QA, Product Owner) deben estar incluidas en la definición de terminado de dicha historia.

La frase de “QA retrasa al equipo de desarrollo, la culpa es de QA,” no es un pensamiento ágil.

Si QA no llega, no termina a tiempo, también es problema de todo el equipo en general, igual que ocurre si desarrollo por algún motivo no termina a tiempo.
Aunque esto puede ocurrir por multitud de causas, si que es cierto que el enfoque del testing en el mundo ágil es un poco distinto al tradicional. No solo debemos probar al final del proceso.
El objetivo del testing no solo es detectar fallos, sino en la medida de lo posible, prevenir dichos fallos.
Por eso, la calidad, y el testing empiezan en fases tempranas de desarrollo, a distinto nivel (recuerda que existen distintos tipos de pruebas, no solo funcionales ¿Pruebas de integración, funcionales, de carga…? ¡Qué jaleo! ¿Qué diferencias hay?):
– Nivel más cercano al usuario: Verificar que se cumplen los criterios de aceptación de la historia de usuario (puede ser testing manual, o tenemos prácticas como BDD o ATDD).
– Nivel de desarrollador: Pruebas unitarias para prevenir que no haya errores a nivel del componente, de método, clase desarrollado.
– Por otra parte, dividimos el trabajo en pequeñas tareas, pequeños incrementos de código, que después se integran para que sea todo más sencillo que dejar la integración para el final. Hay que comprobar que esa integración no rompa nada del resto del software.
– Además, deberíamos buscar nuevas casuísticas. No quedarnos solo en verificaciones sencillas, sino en qué puntos podría fallar la plataforma (utilizando para ello el conocimiento de negocio y el técnico de los testers)
– Y no hagamos solo pruebas funcionales. Si las necesitamos, ejecutemos pruebas de sistema, de carga etc.
Los miembros del equipo deben considerar el trabajo del otro, trabajar en conjunto y estar informados.
En ciertas empresas ágiles incluso, fomento la regla de que cuando un desarrollador tiene alguna duda, no solo hable con el Product Owner, sino que un Product Owner y un tester estén presentes en la conversación. Y lo mismo ante una duda de un tester.

En testing ágil también entran las pruebas automáticas, para ser más rápidos.

Puede parecer que es invertir mucho en testing. Que es inviable en tiempo y en recursos. Que no puedes poner a un tester a verificar todas estas cosas, que no tienes personal.
Sí, es inviable tener a un equipo de testing manual ejecutando pruebas de regresión toda la plataforma cada vez que se hace una integración de código: es muy lento y muy pesado. Y ciertamente, creo que en esto desaprovechamos las cualidades de los testers.
Ahí es donde entra tener un balance entre pruebas automáticas y manuales.
Tener una batería de pruebas automáticas me va a permitir lanzar ciertas verificaciones muy a menudo y con resultados muy rápidos (por ejemplo, una batería de pruebas de regresión cuando el desarrollador integre su código en el control de versiones, gracias a una plataforma de Integración Continua).
Pero automatizar pruebas no significa que se elimine el testing manual.
Las pruebas que se suelen automatizar podríamos considerarlas verificaciones: una máquina no piensa. Los errores que podamos detectar con esas pruebas son errores que ya hemos detectado antes. O son lo que llamamos “happy paths”, las rutas más simples en las que una aplicación podría fallar.
Por eso, un tester manual es imprescindible. Automatizar esas pruebas va a facilitarle el trabajo a los testers, en el sentido de que pueden dedicarse al testing de verdad, nuevo, que vaya aportando valor en cada iteración: testeo de nuevas funcionalidades, búsqueda de errores más difíciles de encontrar, probar nuevas casuísticas. En definitiva, actividades que requieran más de su experiencia.
Por último, esas pruebas automáticas también ayudan a los desarrolladores.
Tener una batería de pruebas automáticas que se ejecuten y me den un informe de que “no he roto nada”, me proporciona más seguridad en lo que hago. Y esto es imprescindible para realizar refactorizaciones, mejora de calidad de código: tener algo que me garantice que los cambios que he hecho no han modificado el comportamiento del código con respecto a lo que había antes.
—
Esta es mi visión del testing ágil, donde la automatización de pruebas da para un próximo post.
¿Cuál es tu experiencia a la hora de integrar el testing en fases más tempranas del desarrollo, junto con la agilidad?