Está en la página 1de 3

Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca...

1 de 3

http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574

Desarrollo Guiado por los Test de Aceptacin


3 Added by Ignacio Sagulo, last edited by Ignacio Sagulo on Jun 14, 2011

Table of Contents

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

Glosario Metodologa Comunicacin y visin compartida


Deuda Tcnica
Los criterios de aceptacin y sus ejemplos asociados (tests) permiten que todo el equipo (cliente, analistas, desarrolladores y
Metricas,
testers) tenga una visin compartida de lo que hay que construir.
Indicadores (borrador)
En vez de escribir requerimientos abstractos y detallados, una tcnica muy importante para detallar la funcionalidad del
Desarrollo
sistema es escribir tests de aceptacin y asociar ejemplos a estos tests (ver un criterio de Aceptacin con ejemplos)
Guiado por los Test de
Los ejemplos juegan un papel central en la comunicacin del equipo y con el cliente, para lograr entender y describir qu es
Aceptacin
lo que hay que construir. La relacin entre ejemplos, tests y requerimientos se muestra en la siguiente Figura (ver pag 27)
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
Cuando se discute con el cliente la funcionalidad se busca expresar y discutir la funcionalidad usando ejemplos conctretos.
Espacio de Trabajo
Estos ejemplos permiten elaborar los requerimientos. A nivel de metodologia, los ejemplos se arman en Specification
Informativo
Workshops ( Ver capitulo 4)
Radiador de
"The key feature of these examples is that they should provide enough information for developers to implement and for testers to verify
Informacin
the stories planned for the iteration"
Referencias
Estos ejemplos son posteriormente refinados por el equipo de desarrollo y muchos pueden convetirse en Tests.
Planificacin
Estos tests sirven para verificar los requerimientos
Scrum
Lo que se propone en Bridging de Gap es que todo el equipo participe en el Workshop de Especificacin, aunque esto
Story Time Meeting
podra hacerse con distintas dinmicas ( ej adelantdose y preparando el back-log para la siguiente iteracion en una
Manual de Calidad
reunin del tipo Story Time Meeting ) En el Capitulo 9 se describe una forma de encajar esta prctica con las iteraciones
Mapa de Procesos
de Scrum ( seccin Fitting into Iterations). Es interesante observar que el Workshop de Especificacin se realiza antes del
Sprint Planning
Organization Charts
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

07/09/2011 07:27 p.m.

Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca...

2 de 3

http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574

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

07/09/2011 07:27 p.m.

Desarrollo Guiado por los Test de Aceptacin - Sistema de Gestin de Ca...

3 de 3

http://confluence.cub2k.com/pages/viewpage.action?pageId=37686574

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.

07/09/2011 07:27 p.m.

También podría gustarte