Upload
pamela-calavetta
View
220
Download
1
Embed Size (px)
DESCRIPTION
.
Citation preview
3Desarrollo Guiado por los Test de Aceptacin
Added by Ignacio Sagulo, last edited by Ignacio Sagulo on Jun 14, 2011
Table of Contents
Glosario Metodologa
Deuda Tcnica
Metricas,
Indicadores (borrador)
Desarrollo
Guiado por los Test de
Aceptacin
Product Backlog
Documentacin
Agil
Info sobre Velocity
Item del Backlog
Modelo de
Dominio
Modelo de
Dominio Unico
Modelos
Temporarios y
Permanentes
Modelos y
Documentos
Prcticas de
Modelado Agiles
Prcticas de
Espacio de Trabajo
Informativo
Radiador de
Informacin
Referencias
Planificacin
Scrum
Story Time Meeting
Manual de Calidad
Mapa de Procesos
Organization Charts
El Desarrollo Guiado por los Test de Aceptacin (o "Acceptance TDD") es una prctica que est descripta en detalle en el libro
Bridging the communication gap (en el libro se llama Agile Acceptance Testing)
Resumimos a continuacin las ideas principales
Comunicacin y visin compartida
Los criterios de aceptacin y sus ejemplos asociados (tests) permiten que todo el equipo (cliente, analistas, desarrolladores y
testers) tenga una visin compartida de lo que hay que construir.
En vez de escribir requerimientos abstractos y detallados, una tcnica muy importante para detallar la funcionalidad del
sistema es escribir tests de aceptacin y asociar ejemplos a estos tests (ver un criterio de Aceptacin con ejemplos)
Los ejemplos juegan un papel central en la comunicacin del equipo y con el cliente, para lograr entender y describir qu es
lo que hay que construir. La relacin entre ejemplos, tests y requerimientos se muestra en la siguiente Figura (ver pag 27)
Cuando se discute con el cliente la funcionalidad se busca expresar y discutir la funcionalidad usando ejemplos conctretos.
Estos ejemplos permiten elaborar los requerimientos. A nivel de metodologia, los ejemplos se arman en Specification
Workshops ( Ver capitulo 4)
"The key feature of these examples is that they should provide enough information for developers to implement and for testers to verify
the stories planned for the iteration"
Estos ejemplos son posteriormente refinados por el equipo de desarrollo y muchos pueden convetirse en Tests.
Estos tests sirven para verificar los requerimientos
Lo que se propone en Bridging de Gap es que todo el equipo participe en el Workshop de Especificacin, aunque esto
podra hacerse con distintas dinmicas ( ej adelantdose y preparando el back-log para la siguiente iteracion en una
reunin del tipo Story Time Meeting ) En el Capitulo 9 se describe una forma de encajar esta prctica con las iteraciones
de Scrum ( seccin Fitting into Iterations). Es interesante observar que el Workshop de Especificacin se realiza antes del
Sprint Planning
Cuando surge una duda o una ambiguedad funcional, se escribe y plantea un ejemplo que hay que resolver. Esto requiere
entonces respuestas precisas y claras
Cuando se especifican los tests se utiliza y se refina el lenguaje ubicuo del Modelo de Dominio Unico (ver en el Capitulo
4, la seccin "Building a domain language" )
Guia del desarrollo
Antes de empezar a programar, los programadores tienen y conocen los Test de Aceptacion. Los tests de aceptacin son
el Objetivo a cumplir por los programadores.
La idea no es que los programadores prueben los tests al final, sino que tienen en cuenta los tests desde el comienzo y los
tests guan toda la construccin.
Los programadores, y todo el equipo, son responsables de los tests. Ej si un programador descubre que falta un test, lo
agrega y comunica al resto del equipo. Aunque claro que si el equipo tiene un tester, ste juega un rol central en relacin a
los tests
Objetivos de la prctica
Introducir la CALIDAD EN EL PROCESO y no que la calidad sea algo que se controla "al final" como en las
metodologas ms tradicionales
Se PREVIENEN los bugs en vez solamente controlar que no haya bugs al final
Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca... http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574
1 de 3 07/09/2011 07:27 p.m.
Como se nombr antes, que todo el equipo tenga una visin compartida de lo que hay que construir.
Tener una visin comn entre todos (cliente y equipo de desarrollo) de las condiciones de aceptacin del sistema.
Esto permite lograr el real "working code" que est aprobado por el cliente.
Se minimiza, o mejor an se elimina, el GAP entre "est programado" y "est testeado" permitiendo una medicin
clara del avance del proyecto usando la Velocidad del equipo y llevando Release Burndown Chart
La utilidad de est prctica puede ponerse de manifiesto cuando medimos el GAP entre el "est programado" y "est
testeado/aprobado" . Este gap se puede medir adaptando ligeramente el Release Burndown Chart ver aca
Otros comentarios
Un paso muy recomendable, aunque no necesario, es lograr que estos ejemplos/tests se ejecuten en forma automtica con
herramientas como Fit-Fitness
La tcnica se complementa muy bien con User Stories, porque all se escribe mucho menos en forma de requerimientos
detallados. Entonces est prctica permite detallar los requerimientos en la forma de tests. De todas formas, tambin
puede usarse con Casos de Uso.
Ver como definir test en Velocity en esta pgina
Cul es la relacin entre "Acceptance TDD" y TDD ?
Ambas prcticas tienen en comn que parten de los test , pero se realizan a distintos niveles y con distintos objetivos
TDD es una prctica que aplica el programador para guiar el desarrollo de cdigo. El objetivo es definir el comportamiento
de una unidad de cdigo acotada en forma de test antes de empezar a programar
Acceptance TDD es una prctica que aplica el equipo, en la cual el trabajo de todo el equipo est fuertemente guiado por
los test de aceptacin que se escriben en forma temprana. El objetivo, entre otras cuestiones, es definir el comportamiento
del sistema a traves de los ejemplos / tests.
En la siguiente figura se muestra la relacin entre "Acceptance TDD" y el TDD realizado por el programador:
Referencias
Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca... http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574
2 de 3 07/09/2011 07:27 p.m.
Ver un Ejemplo de Documentacion Funcional con Test de Aceptacion.pdf del proyecto Midawi
Bridging the communication gap
http://gojko.net/2010/08/04/lets-change-the-tune/ : blog del autor de Bridging the communication gap
http://www.infoq.com/news/2011/04/representing-agile-testing : un articulo que muestra distintas formas de escribir
test de aceptacin
http://xprogramming.com/xpmag/jatRtsMetric est prctica permite implementar la mtrica de "Running Tested
Features" ( RTF
Test Driven_ TDD and Acceptance TDD for Java Developers.pdf : la parte III del libro est dedicada a este tema
"Building products with Acceptance TDD"
Acceptance TDD Explained: esta pgina est basada en el libro anterior
Capitulo 16 de Succeeding with Agile
http://testobsessed.com/2010/07/19/why-test-automation-costs-too-much/
Printed by Atlassian Confluence 2.10.3, the Enterprise Wiki.
Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca... http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574
3 de 3 07/09/2011 07:27 p.m.