Tuve el placer de conocer a Lisa Crispin y Janet Gregory en el evento al que asistí en Boston, el Agile Testing Days USA. El primer día del evento participé en un tutorial que duró todo el día, donde ellas presentaron las básicas del testing en equipos ágiles, así como algunas dinámicas bien interesantes.
Algo que me gustó es que hicieron mucho foco en que la calidad y el testing son responsabilidad de todo el equipo, y estuvimos discutiendo mucho en grupos sobre distintos aspectos estratégicos, que hablan de las actividades de testing, independientemente de quién las haga.
Dinámica de Cuadrantes de Testing Ágil
Si no conocés los cuadrantes del testing ágil, mirá primero este post donde comento al respecto. Para el taller de testing ágil que dictamos con Gabriel, habíamos preparado una dinámica relacionada al cuadrante del testing ágil. Lo que presentaron acá tenía una variedad que me resultó bastante interesante. Una visión que no había tenido relacionada al cuadrante, es que se puede pensar todo el lado izquierdo como las pruebas que se hacen antes de tener al producto para probar, y las que están a la derecha como las pruebas que se hacen luego de tener el producto terminado. Entonces, con el fin de pensar más en actividades de testing más tempranas en el proceso de desarrollo, nos forzaron a utilizar solo la parte izquierda del cuadrante.
Dinámica de la Pirámide de Automatización
Si no conocés la pirámide, leé este post primero. Nos proporcionaron un contexto y una descripción de un producto. Luego, nos dieron distintos casos de prueba. El desafío consistía en pensar en grupo en qué nivel de la pirámide nos parecía más adecuado automatizar una prueba para ese caso.
Otro punto de vista distinto acá, fue el tema de vincular la capa superior de la pirámide (UI automation) con las features, API testing con stories y unit testing con las tasks. Supongo que no siempre es así de fácil hacer ese vínculo, pero es una forma más de ver el modelo en V tradicional adaptado a las prácticas ágiles. Esto se ve en la siguiente slide:
The End Game
Le llaman “the end game” al momento en el que se “congela” el código que se va a liberar, y se hace una última prueba para ahí aprobar el pasaje a producción. Esto dice que suele ser así incluso en Continuous Delivery (no es así en Continuous Deployment). Hay casos en que esto puede ser de horas, o (como muchos casos que conozco) de muchos días. Durante esos días no se puede avanzar en nuevos desarrollos, sino que el equipo está más que nada atento a ajustar todo lo necesario para ese release.
Las preguntas a pensar acá fueron:
- ¿Cuánto dura nuestro “end game”?
- ¿Lo planificamos adecuadamente?
- ¿Alguna actividad se podría hacer antes? ¿qué nos impide adelantar esas actividades?
Gherkin y Fitness
Estuvimos escribiendo criterios de aceptación en Gherkin, lo cual sería útil para implementar una estrategia de ATDD (aceptance testing driven development), BDD (behavior driven development) o SBE (specification by example), con algo como Cucumber o JBehave. También estuvimos practicando la especificación en tablas para seguir un enfoque del estilo propuesto por herramientas como Fitness. Todo esto tiene como fin el poder guiar al desarrollo con ejemplos de negocio.
Cerrando
Hablamos de la importancia de los T-Shape Skills, de la colaboración entre desarrollo y testing, y muchas cosas más. Creo que me gustaron las últimas dos slides del curso como para enfatizar cosas importantes:
En esta última me resultó particular que hable que el testing sirva para aportar a la confianza, lo cual me hizo pensar en este post que escribí hace poco al respecto.
Viendo el tutorial en perspectiva, creo que no vi nada nuevo, pero de todos modos aprendí un montón. Lisa y Janet hicieron una dupla muy buena para dictar el taller, mantener a la gente atenta y activa.
