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.