El tema de cómo testear software siempre levanta mucha polémica, pero cuando entramos en un desarrollo Agile, hay además bastante confusión. La pregunta que he escuchado en más ocasiones es la de: ¿Cómo vamos a involucrar a un testeador desde un principio, si el desarrollo no está acabado?
Para resolver esta duda, hay que empezar mencionando que Agile es una metodología que pone mucho énfasis en la calidad. La calidad entendida no sólo como calidad del código (sin bugs, bien diseñado, etc.) sino como proceso global: Lo desarrollado es útil al negocio, responde a las expectativas cambiantes, se pone en producción en iteraciones relativamente cortas, etc.
Por eso, porque la calidad es algo que se mantiene en todo momento, un testeador se involucra desde el principio de la iteración. No se pone a trabajar sólo los dos últimos días del ciclo (como he oído en algunas ocasiones).
En general, un testeador:
- Colabora con el Product Owner para definir las condiciones de aceptación.
- Muchas veces, en esta fase se descubren "puntos oscuros" que ni el Product Owner tiene del todo claro. ¡Considero que esta parte es vital!
- El testeador se encarga de que las user stories sean claras y tengan sentido. Es en esta parte donde cobra importancia lo mencionado antes de la calidad no sólo entendida como código bien escrito.
- Crea los planes de test, los casos de test y los planes de regresión, a partir de dichas condiciones de aceptación.
- Se encarga de los entornos de test y del proceso de build (y muchas veces de los repositorios de código).
- Se encarga de la automatización del test.
- Testea.
- Informa de los resultados para estadísticas, análisis, etc. ¡Los testeadores suelen ser una parte importante de las sprint retrospective!
Por supuesto, hay múltiples variaciones, dependiendo del perfil de los testeadores con los que se cuente, pero los puntos mencionados antes son los que yo considero básicos cuando se habla de test en un entorno Agile.