Los testers de software trabajan en muchos contextos diferentes - farmaceútico, servicios financieros, telefonía, desarrollo de productos, y muchos más. Y en cada lugar se desarrolla software usando distintas metodologías, como Cascada, RUP, Scrum, Extreme Programming (XP) y el famoso codificar-y-rezar (conocido afectuosamente como "programación ad hoc").

Cada vez más personas se preguntan cuál es la mejor forma de testear un proyecto ágil con éxito. Veamos juntos el tema.

Proyectos tradicionales vs. proyectos ágiles

Muchos dicen que los proyectos ágiles son distintos a los "tradicionales". Puede ser, pero no en los temas que piensan. Los proyectos ágiles son más rápidos (iteraciones cortas, software funcionando antes, y un sentido de foco y urgencia en todo el equipo desde el primer día), pero igualmente tienen los mismos problemas que otros ciclos de vida de proyecto más tradicionales:

1. A los equipos de proyectos ágiles les llegan malos requerimientos, como los que surgen en las primeras iteraciones de Cascada o RUP. Los proyectos ágiles no tienen tanto tiempo para elaborarlos en algo que parezca no ser tan malo, pero el enfoque ágil permite que los malos requerimientos no importen tanto.
   
2. En general planifican tanto como en otras metodologías, pero lo van haciendo de a poquito, a lo largo de todo el proyecto, de maneras diferentes (de maneras que permitan responder rápidamente al cambio para entregar valor).
   
3. Los equipos ágiles también tienen que resolver problemas de coordinación con múltiples participantes: manejar la comunicación con todo el equipo, brindar oportunidades de crecimiento a los miembros del equipo, planificar las vacaciones, feridados, etc. A diferencia de otros enfoques, en ágil no se confia en la documentación para solucionar estos problemas, sino que se favorece a la comunicación cara-a-cara como forma favorita de resolver estos temas.
   
4. En los proyectos ágiles la documentación existe, pero es más fluida. Se le da más importancia al código que funciona, por lo que el equipo prefiere dedicar su esfuerzo en crear tests automatizados que soporten al código, y mantener información valiosa en alguna Wiki (la cual cambia constantemente), usando prácticas ágiles como programación de a pares y reuniones diarias de parado, en vez de crear enormes libros de documentos que nadie lee por segunda vez. 
   

Para los testers, el desafió más grande de estar en un proyecto ágil es que el software está siempre cambiando. Hay código nuevo que se agrega para testear en forma diaria. En un proyecto ágil el sistema bajo test se transforma en un blanco móvil. Se necesitan nuevos enfoques de test para enfrentar este tipo de cambios, con diferentes habilidades, tácticas y herramientas. Hay algunos aspectos del testeo que no cambian, como ser la ejecución de los test, pero muchos testers necesitarán realizar cambios importantes a su estrategia de testing para brindar valor real a un proyecto de software ágil.

El cambio de estrategia

Pensemos en un espectro para el test de software. En un extremo tenemos un testeo manual totalmente guionado. Estamos hablando de pruebas escritas en tablas, completamente llenas de casos a testear. Esta es una punta del espectro. En el otro lado tenemos el testing de exploración libre, sin guiones para testear, usando sólo la experiencia y la intuición para encontrar problemas.

El testing exploratorio es invaluable para los proyectos ágiles. En muchos casos, el testeo exploratorio se alinea con el Manifiesto Ágil, respondiendo rápidamente al cambio y enfocándose en solucionar el problema. Como resultado, las habilidades y tácticas para realizar un testeo exploratorio se convierten en grandes aliados para testear un software que cambia continuamente.

Si la mayor parte de tu experiencia fue testeando proyectos que seguían un enfoque "en cascada", seguramente estás acostumbrado a pasar gran parte del tiempo diseñando los guiones de test basándote en documentos de requerimientos que indican cómo validar características específicas. Esta es una práctica muy aceptada para testear software, pero en realidad no funciona bien en los proyectos ágiles.

Uno de los motivos por los cuales esta práctica es inapropiada para proyectos ágiles es que necesita bastante tiempo inicial para que funcione. La mayoría de los proyectos ágiles tienen sprints de dos a cuatro semanas, y los casos de pruebas no se escriben en una noche. En general se necesitan de tiempo que un proyecto ágil no tiene. El test exploratorio es mucho más liviano. Tiene menos documentación, pero realizado de manera adecuada puede brindar la misma cobertura y el mismo grado de riesgo. El tema es encontrar el balance exacto en crear la estructura necesaria para realizar el seguimiento de lo realizado y poder evaluar los resultados. Una alternativa es usar el enfoque de Gestión de Tests basado en sesiones, creado por James Bach y Jon Bach.

Por otro lado, el testing exploratorio no necesita mucha preparación por anticipado. Es es muy importante porque las metodologías ágiles hacen énfasis en el voluntarismo y la planificación constante. El voluntarismo quiere decir que, dentro del alcance de un sprint, los miembros del equipo elijen las tareas que realizarán. La planificación constante significa que las características del producto se re-priorizan al inicio de cada sprint, basándose en las nuevas necesidades acorde al mercado y la situación. El efecto es simple: no hay un plan para cada una de todas las posibles características, ni para el proyecto global. Las características pueden ir cambiando y acomodándose según cambien las necesidades. En consecuencia, se necesita poder testear cualquier cosa, en cualquier momento, con la mínimia preparación posible.

Agilizando el proceso de testing

Ya sin requerimientos detallados y sin un proceso de control de cambios que mantengan a estos requerimientos estáticos, la habilidad más importante es la de tomar decisiones acerca del trabajo que se hará a continuación, cómo se llevará a cabo, y cómo le daremos valor a nuestro cliente. Todo se basa en en ver el software como historias que le dan valor a los usuarios, y estructurar el trabajo alrededor de estas historias (muy parecido a como los desarrolladores organizan su trabajo: historias alrededor de las cuales se organiza el trabajo).

En un proyecto con cambios continuos, es importante tomar buenas decisiones respecto a lo que se testea, y cuándo se testea. Si se prueban características que todavía no están terminadas y se generan defectos, perderemos credibilidad ante el resto del equipo (y esto es un error común que se comete cuando el software evoluciona rápidamente). Necesitamos estar siempre conscientes y en conocimiento del estado del software. Esto significa hablar con los desarrolladores, prestar atención en la reuniones diarias, y estar familizarizados y atentos a cualquier sistema que se para seguimiento del proyecto.

Una prácticas que puede resultar útil es el tour de aplicación. El tour de aplicación consiste simplemente en usar la aplicación de distintas maneras para mejorar nuestro entendimiento sobre cómo funcionan las cosas, y en dónde podrían estar los riesgos. El objetivo es tan tanto encontrar defectos, sino más bien crear un modelo mental de cómo funciona el software, qué hace, y cuáles características fueron implementadas. Todos los testers deberían invertir algo de tiempo en hacer un tour por la aplicación en cada iteración. Esto ayuda a mantenerse en contacto con la dirección general que está tomando la aplicación.

Asegurarse de no quedar afuera

El respeto y la credibilidad son críticos en un equipo de proyectos ágiles. En estos equipos, los desarrolladores suelen tener mucha habilidad, no sólo en la codificación sino también en la creación de tests automáticos, especialmente si usan prácticas como Desarrollo Guiado por Test (TDD). No cometan el error de tratarlos como si no supieran de qué se trata el testing.

Es importante ganarse el respeto del equipo de desarrollo. Hay varias formas de lograrlo, como el juego "cinco bugs en cinco minutos". Pero en última instancia la mejor forma de ganarse el respeto es poder agregar valor al proyecto. Algunas formas que se puede lograr:

1. Brindar una perspectiva nueva y fresca sobre la aplicación. Es común que los desarrolladores estén tan inmersos en la aplicación que pierdan el punto de vista del usuario real.
   
2. Hacer un buen trabajo aislando los bugs. Cuando se encuentra un defecto, invertir algo de tiempo extra en encontrar la manera más simple de reproducirlo. Además, usar software para poder grabar la prueba (como Selenium) y adjuntar el resultado al reporte de error.
   
3. Hablar con los desarrolladores antes de ingresar un reporte de error. A veces un único defecto puede tener varios síntomas, y en general no es útil crear un reporte por cada síntoma encontrado. El desarrollador puede ayudarnos a comprender las implicancias del defecto, y evitar así ingresar docenas de informes que en última instancia responden al mismo problema.
   

Los mejores equipos ágiles quieren la ayuda de testing. Reconocen todo el valor extra que brinda un buen tester que está enfocado en el proyecto. Lo importante es no quedar aislado. Esto significa que el tester tiene que convertirse en un consejero del equipo. Hay que averiguar qué información valora el equipo y qué información necesita (podrían no coincidir), y enfocarse en brindar un balance entre esta información.

Los equipos ágiles son rápidos, con muchos de los mismos problemas que los proyectos tradicionales (afortundamente, estos problemas tienden a aparecer más rápido), y con algunos desafíos propios. Convertirse en un tester efectivo en este ambiente puede requerir cambiar la estrategia y encontrar nuevas técnicas para estructurar el trabajo y aprender más eficientemente. Y no olvidarse que una parte importante dentro del proyecto es también divertirse.

Si realmente no querés quedarte atrás, podés dejar que la diversión sea el barómetro que mida tu situación. En la mayoría de los equipos ágiles, el respeto se gana a través de la capacidad para resolver problemas, y las personas disfrutan trabajar junto a quienes respetan. 

Traducido de Software testing on an agile project: How to get started.