En el anterior artículo hablábamos del sentido de las iteraciones/sprints en las metodologías ágiles, y una de las cosas que resaltaba era la necesidad de la entrega de valor continúa.
Para esto hay una cosa fundamental que no debemos olvidar: que la calidad, en el sentido más amplio de la palabra, no es opcional. No me refiero sólo al típico “que no falle”, sino a ¿entrega el valor esperado? ¿Resuelve los problemas que debería? ¿Cómo se comporta esto ante condiciones anormales de negocio (p.ej.: 1000 usuarios)?
Ante esto, cuando estamos trabajando con esta mentalidad, debemos de poner la calidad como foco desde el principio. Se acabó esa forma de pensar en la que los testers son un equipo, normalmente el enemigo, de los desarrolladores. Ese típico ir y venir de descripciones de fallos (seguro que todos recordáis el mítico Pong).
Recordemos, en las metodologías ágiles siempre hablamos de equipo. Esto no quiere decir que dentro del mismo no haya gente que sepa más acerca de un tema que de otro, eso es lógico, pero todos forman parte del mismo barco. Si este se hunde, todos al agua. Y en este caso es lo mismo, la gente que define y ejecuta las pruebas de la aplicación son parte del equipo, y por tanto debemos incluirlas y colaborar con ellas. No son un equipo a parte que vive de la sangre de los desarrolladores … bueno vale aquí me he pasado …
Y como parte del equipo, ¿cuándo intervienen?. Tradicionalmente la ejecución (y a veces hasta la definición) de las pruebas se ha dejado para el final, esto siempre me ha recordado mi época de estudiante, ese dejar el estudiar para el día antes del examen. Y, como ya sabréis muchos, ese momento suele ser demasiado tarde.
Con las pruebas es igual, si las dejamos para el final, para esa famosa fase de corrección de errores o estabilización, lo que suele ocurrir es que el tiempo se acaba o que finalmente no disponemos del tiempo suficiente para probar las cosas.
La definición, preparación y hasta ejecución de pruebas tiene que ser algo que venga desde el principio, más allá de prácticas recomendables (o necesarias) como pruebas unitarias o de integración durante el desarrollo. Estoy hablando de incorporar a la gente que va a definir las pruebas también en reuniones como el sprint planning.
En estas reuniones iniciales, al igual que obtenemos todos los detalles de lo que necesitamos construir y hacer durante la iteración, también necesitamos saber bajo qué condiciones lo que vamos a crear va a ser aceptado. Esto, por supuesto, debería pertenecer a nuestra Definition of Done, de modo que cualquier historia de usuario o requerimiento, que no pase sus pruebas de aceptación no debería de ser dado por válido.
Ahora bien, ¿qué podemos hacer para asegurar el valor en cada sprint?. Lo más claro es, probar, probar y volver a probar.
Empezaremos con nuestros requerimientos. Todo requerimiento debe de llevar, al menos, un conjunto de pruebas de aceptación definidas al principio. Esto, por supuesto, será algo vivo. A medida que avancemos las completaremos, mejoraremos, crearemos nuevas, al igual que se hace en Scrum con el Sprint Backlog a nivel de desarrollo.
También, desde el inicio podemos empezar con pruebas de exploración, ya sea con las primeras funcionalidades que se vayan completando a nivel de desarrollo, como sobre prototipos, que son una herramienta muy útil para asegurar el feedback temprano del cliente o los usuarios.
Otro método aprendido en el libro Agile Testing de Lisa Crispin, es el uso de ejemplos. Esto consiste en, para cada funcionalidad, describir un ejemplo de uso al menos. De modo que sepamos cual es el procedimiento que realizarán los usuarios. Estos pueden ser ejemplos básicos, o ejemplos más completos estilo end to end.
En definitiva y como conclusión, si queremos entregar valor sprint a sprint, debemos:
-
Incorporar la calidad desde el principio, no esperando al final.
-
Incluir el equipo de pruebas como parte integral del equipo. No es un grupo de personas que viene a posteriori a validar lo que hemos hecho, pertenecen integralmente al equipo que va a construir el producto y desde el principio.
Por supuesto, y como en todas las metodologías, cada situación es potencialmente distinta y siempre nos podemos encontrar con entornos en los que tengamos que hacer, por ejemplo, iteraciones de estabilización o iteraciones en paralelo para pruebas.
Incluso en ocasiones, podemos llegar a realizar iteraciones de release previas al despliegue.
Pero ojo, esto no es una iteración en la que hemos dejado para luego la calidad. Todo resultado
de iteración, aunque no despleguemos, debe ser potencialmente entregable. En estas iteraciones nos concentraremos en convertirlo en entregable. De todos modos este tipo de iteración, suele darse en proyectos muy grandes.
Más información:
Agile Testing quadrants por Brian Marick
Agile Testing de Lisa Crispin y Janet Gregory
En Genbeta Dev | Ser ágil es algo más que iterar
Luis Fraile lleva trabajando en entornos Microsoft desde más de 10 años, empezando con Visual Basic 6, y posteriormente desde la primera versión del .NET Framework, habiendo participado en multitud de proyectos relacionados con estas tecnologías.
En los últimos años, a parte de desarrollar, también se ha dedicado a ayudar a equipos a la hora de abordar procesos de metodologías ágiles, especialmente en entornos Microsoft con tecnologías como Team Foundation Server. También es colaborador habitual de la revista Dotnetmania, así como ponente en eventos, a nivel nacional, relacionados con gestión de ciclo de vida y Team Foundation Server.
Puedes seguirlo en Twitter: @lfraile
Sus blogs son: lfraile.net y geeks.ms/blogs/lfraile
