Tema"Definition of Done (Pruebas de Aceptación Automatizadas)" por José Manuel Beas y Alberto PeñaLugar Confirmado:IdealistaPlaza de las cortes, 2, 28014 http://www.idealista.com/pagina/donde-estamos IMPORTANTE Para el acceso a las oficinas de idealista se necesita enviar un correo con el nombre y nº de DNI a la dirección: eventoagil@idealista.com Día y Hora Confirmados:19 Enero 2010 - 19:30 Lista de asistentes:
Ideas de la sesión:La idea es contar un poquito (muy poco) de rollete sobre por qué automatizar las pruebas de aceptación y luego ponernos manos a la obra con Concordion. Luego, Alberto enseñará el mismo ejemplo con Fitnesse. Si conseguimos convencer a Ricardo de que nos enseñe un poquito de Robot Framework, será genial también, si no, siempre podremos dejarlo para otro momento. El objetivo de la sesión no es votar cuál es mejor, si Concordion o Fitnesse, porque está claro que Concordion es mucho mejor. :-) Je, je, en serio, la idea es simplemente ver que las pruebas de aceptación se pueden automatizar y ver cómo se puede hacer esto en vivo en directo. No veremos pruebas de aceptación de GUI, no es el objetivo de esta sesión, pero siempre podremos discutir al respecto. Lecturas recomendadas:
Resumen: Comenzamos con una presentación sobre el Definition of Done y las pruebas de aceptación para pasar después a un debate. Presentación ¿Cuando está algo terminado? Básicamente, cuando está listo para ponerlo en producción. Decirlo es fácil, hacerlo es otra cosa. Significa que funciona, no hay bugs, satisface al cliente, etc... ¿Qué ocurre si no definimos cuando está terminado? Aparece una sensación de falso progreso. Pensamos que tenemos una velocidad y que vamos acabando las cosas pero, cuando llega el momento de presentarselo al cliente, nos lo tira para atrás porque no es realmente lo que quería o porque nos falta cierta funcionalidad, etc Esto provoca que nuestra pila de trabajo contenga tanto nuevas funcionalidades como parcheos de las funcionalidades antiguas y, como todos sabéis, parchear fucnionalidades antiguas es mucho más complicado (y aburrido) que crear funcionalidad nueva. Esto provoca que nuestra velocidad disminuya. Otra consecuencia importante de no definir el terminado es que, probablemente, no cumplamos las espectativas del cliente. ¿Cómo definimos Terminado? Es muy importante que definamos que queremos hacer. Despes, se puede refinar con el quien, el como y el cuando. Una definición de terminado podría ser:
¿Pruebas de aceptación? ¿Qué es eso? Las pruebas de aceptación es un conjunto de tests creados junto al cliente que deben ser superados para que algo pueda darse por terminado. Son un requisito necesario pero no suficiente. Deben estar orientadas a las reglas de negocio, que son duraderas. Pueden hacerse todas manualmente, pero no es un modelo escalable. Por eso queremos automatizarlas en la medida de lo posible. La automatización de estas pruebas es complicada, por eso nos ayudamos de frameworks como Concordion, Fitnesses o Robotframework. ¿Qué debe cumplir una buena prueba de aceptación? Debe plantear unas especificaciones legibles. Ir al grano, sin ambigüedades. Ayudandose de ejemplos concretos. Deben especificar intenciones (basarse en el qué). Para ello podemos conviene usar el modelo GWT (given when then) No deben centrarse en casos de uso completos, deben ser especificaciones sencillas centradas en una regla. Un ejemplito. Deben aislarse lo más posible del "cómo". Como se hace algo puede cambiar a lo largo del desarrollo, pero el qué quiero permance (no acoplarse al SUT) Ciclo de vida de pruebas de aceptación Partiendo de una serie de historias de usuario, se reunen los expertos de negocio y los desarrolladores para crear las pruebas de aceptación. Se resuelven las dudas que aparecen y, si es necesario, se parten las historias en otras más pequeñas. Se desarrollan las historias y se comprueba que pasan las pruebas de aceptación. Si surgen dudas sobre alguna de las historias o los desarrolladores se dan cuenta de que se necesita alguna prueba más se vuelve a la reunión de especificación con negocio y se resuelven las dudas. Debate Tener pruebas no asegura que lo que haces es lo correcto. Es necesaria la participación del cliente para definir correctamente que pruebas hacer. Las pruebas de aceptación no son un requisito suficiente. Lo importante de las pruebas de aceptación es que te enfocan en lo que debes hacer, minimizando el desperdicio. Automatización de Pruebas Después se enseño ejemplo en Concordion y en FitNesse y hablamos sobre los pros y contras de cada uno, mezclado con opiniones sobre testing ágil y automatización de pruebas. Concordion y FitNesse Explicar un poco el ejemplo, como generar las pruebas de aceptación y explicar cada una de las "implementaciones" (Pendiente). Pros y Contras Concordion es más explicito. Utiliza HTML para las historias, pudiendo "esconder" las llamadas a las fixtures. El problema es que un cliente no sabe de HTML. FitNesse se basa en tablas de decisión, lo que le hace algo más restrictivo a la hora de generar los tests . Su parte buena es que es un wiki, algo a lo que cada vez más gente no técnica está acostumbrada. Conclusiones:
|
|
Reuniones >
2010-01-19 |