Gestin de Software

Testing en eXtreme Programming

Gestin de
Software
2006
Testing en eXtreme
Programming

Grupo 6
Responsables:
Nombre
Dayvis Malfar
Diego Cukerman
Fernando Ccaro
Juan Pablo
Cassinelli

Cdula
38606763
33483409
43473711
31000538
Pgina 1 de 22

Gestin de Software

Testing en eXtreme Programming

Renzo Sttimo

27661295

Pgina 2 de 22

Gestin de Software

Testing en eXtreme Programming

NDICE
1
2

DESCRIPCIN DEL DOCUMENTO.....................................................................3

INTRODDUCCIN A EXTREME PROGRAMMING.....................................................4
2.1
2.2

Qu es eXtreme Programming?.....................................................................................4
Las doce Prcticas........................................................................................................... 4

TESTING EN EXTREME PROGRAMMING.............................................................7

3.1
3.2
3.3
3.4
3.5
3.6

El Rol del Tester............................................................................................................... 7

Programacin por pares.................................................................................................. 8
Pruebas Unitarias............................................................................................................ 8
Herramientas para automatizar las pruebas unitarias....................................................9
Un ejemplo utilizando JUnit.............................................................................................9
Pruebas de aceptacin.................................................................................................. 13

3.7

Experiencia personal..................................................................................................... 16

3.6.1
3.6.2
3.6.3
3.6.4

4
5

El rol del cliente.................................................................................................................... 13

Criterios de aprobacin......................................................................................................... 14
Definicin de los casos de prueba......................................................................................... 14
Presentacin de los resultados de las pruebas de aceptacin...............................................15

CONCLUSIONES.......................................................................................18
REFERENCIAS.........................................................................................19

Pgina 3 de 22

Gestin de Software

Testing en eXtreme Programming

DESCRIPCIN DEL DOCUMENTO

Este informe tiene como objetivo investigar los mtodos y prcticas empleadas por la
metodologa de desarrollo de software eXtreme Programming (Programacin Extrema)
para realizar el testing de los productos que se construyen al emplear la misma.
Cabe destacar que este documento esta orientado a personas con conocimientos previos
en Extreme Programming.

Pgina 4 de 22

Gestin de Software

Testing en eXtreme Programming

INTRODDUCCIN A EXTREME PROGRAMMING

En este captulo daremos una pequea introduccin a eXtreme Programming, sin
pretender abarcar demasiado en esta metodologa.

2.1

Qu es eXtreme Programming?

eXtreme Programming de ahora en adelante XP, es una metodologa de desarrollo

de software gil, que considera a las personas como un factor decisivo para lograr el
xito de un proyecto. Por ser un proceso gil tiene como principal caracterstica su
adaptacin a entornos cambiantes. Esto es posible porque el proceso esta diseado
para adaptarse en forma inmediata a los cambios, con bajos costos asociados en
cualquier etapa del ciclo de vida.
XP es una metodologa gil para pequeos o medianos equipos, desarrollando
software cuando los requerimientos son ambiguos o rpidamente cambiantes. [Beck,
2000]
Esta diseada para trabajar en pequeos o medianos equipos de hasta 12 integrantes.
Esto fomenta la comunicacin e interaccin entre sus integrantes, logrando el trabajo
en equipo. De esta forma, es posible reducir el costo de transferir informacin entre los
mismos, al tener a todo el equipo compartiendo un mismo lugar de trabajo.
El cliente cumple un rol fundamental en XP, dirigiendo el proyecto a lo largo del mismo.
Este es quin fija las prioridades, y los programadores desarrollan lo que es necesario
para ese momento en particular. En pequeas iteraciones el sistema va creciendo
segn los requerimientos solicitados por el cliente, l cual puede observar el avance del
proyecto en todo momento.
2.2

Las doce Prcticas

Kent Beck enuncia doce prcticas que sirven como un punto de partida para un equipo
XP, las cuales se basan en los valores de simplicidad, comunicacin, retroalimentacin y
coraje.
Podemos plantear estas prcticas en tres capas:

Programacin:
Diseo Simple, Refactoring, Estndares de cdigo, Pruebas.

Prcticas del equipo:

Pequeas entregas, Metfora, Programacin por pares, Propiedad colectiva,
Integracin continua, 40 horas semanales.

Los procesos:
Cliente on-site, El juego de la planificacin, Pruebas, Pequeas entregas.

Como podemos observar hay prcticas que se repiten en las diferentes capas, ya que
estn relacionadas en cada una de ellas.
A continuacin se presenta un detalle de cada prctica:

El juego de la planificacin
Mediante esta prctica se realiza la planificacin del proyecto en XP. La misma
consiste en el plan de entregas, el plan de iteraciones, las historias de usuario, las
tareas y los casos de pruebas para las mismas.

Pequeas entregas
Las entregas deben ser lo ms pequeas posibles, conteniendo siempre los
requerimientos del negocio mas importantes para el cliente en ese momento
dado. De esta manera el cliente va obteniendo funcionalidades del sistema en
Pgina 5 de 22

Gestin de Software

Testing en eXtreme Programming

forma gradual hasta finalizar el proyecto. En cada entrega los programadores

obtienen retroalimentacin del cliente determinando si lo implementado es lo que
en realidad necesita.

Metfora
La metfora le brinda al equipo una imagen del sistema la cual ellos pueden
utilizar para describir la estructura en forma simple y sencilla. Las ventajas de su
aplicacin es que hace ms fcil la comprensin del sistema y colabora para
mantener un diseo simple.

Diseo simple
El diseo se va creando en forma progresiva, sin prever las necesidades del
futuro. Al tener un diseo simple capaz de mantener las caractersticas actuales
del sistema, este puede adaptarse mejor a un entorno cambiante cuando surgen
nuevos requerimientos o cambian los actuales.

Pruebas
Las pruebas (testing) son una de las prcticas fundamentales en las cuales se
basa XP. Esta actividad se realiza en forma continua a lo largo del proyecto.
Existen dos tipos de pruebas, las unitarias y las de aceptacin.
Las pruebas unitarias son definidas por los programadores antes de comenzar a
escribir cdigo. stas deben contemplar cada mdulo del sistema que pueda
generar fallas. Para poder integrar el cdigo realizado al ya existente, el mismo
debe aprobar satisfactoriamente todos los casos de prueba definidos.
El cliente con ayuda del tester define las pruebas de aceptacin para cada historia
de usuario a principio de cada iteracin. Las pruebas de aceptacin se utilizan
para validar que cada requerimiento implementado funciona como se haba
especificado.

Refactoring
Significa mejorar el diseo del cdigo sin cambiar la funcionalidad actual. Aplicar
esta tcnica permite reducir la complejidad del cdigo y eliminar posibles
redundancias.

Programacin por pares

Todo el cdigo producido en XP es realizado en parejas, dos personas frente a una
computadora. Los roles en la pareja son de conductor y acompaante. El
conductor es el que maneja el teclado y el ratn (mouse), pensando la mejor
manera de cmo implementar el cdigo. El acompaante tiene como tarea
observar y corregir los errores cometidos por el conductor, considerar
soluciones alternativas y sugerir nuevos casos de prueba. Esta constante revisin
produce cdigo y un diseo con mayor calidad.
Peridicamente se debe intercambiar los roles de la pareja. De esta forma, se
asegura transmitir el conocimiento del sistema a todo el equipo y eliminar las
dependencias de personas que conocen partes del sistema.

Propiedad colectiva
Esta prctica se basa en que todo el cdigo desarrollado pertenece al equipo.
Todos los integrantes del equipo tienen la misma responsabilidad sobre todo el
sistema. Al ser el equipo el responsable, cualquier integrante esta autorizado a
realizar los cambios que se consideren necesarios para mejorar la calidad del
mismo.
De esta manera se logra descentralizar el conocimiento y no generar
dependencias hacia las personas.

Integracin continua
La integracin de cdigo se debe realizar en forma continua, esto implica al
menos en un lapso de un da de trabajo y de ser posible cada unas pocas horas.
La ventaja de la integracin continua es obtener retroalimentacin lo ms rpido
posible. Adems de ser ms sencilla que las integraciones que se realizan luego
de varias semanas de programacin.
Pgina 6 de 22

Gestin de Software

Testing en eXtreme Programming

40 horas semanales
Esta prctica expone que 40 es la cantidad de horas que se debe dedicar al
trabajo semanalmente. De esta manera se logra cometer menos errores por
cansancio y aumentar la productividad del equipo.

Cliente on-site
Para lograr un correcto funcionamiento de un proyecto en XP es necesario contar
con la presencia full-time del cliente en el lugar de trabajo, siendo ste un
integrante ms del equipo. Contar con un cliente en el lugar de trabajo fomenta la
comunicacin y reduce la posibilidad de malentendidos y tiempos de espera.

Estndares de cdigo
El equipo de programadores define en forma consensuada los estndares de
programacin que utilizar. De esta manera se logra obtener un cdigo uniforme,
como si el sistema fuera programado por una sola persona. Esta prctica fomenta
la comunicacin y facilita la implementacin de las prcticas de refactoring,
programacin en pareja y propiedad colectiva.

Pgina 7 de 22

Gestin de Software

Testing en eXtreme Programming

TESTING EN EXTREME PROGRAMMING

En este captulo presentaremos el testing en XP, explicando diferentes puntos acerca de
su metodologa.
Explicaremos el rol del tester, la prctica programacin por pares y todo lo referente a las
pruebas, tanto unitarias como de aceptacin.

3.1

El Rol del Tester

El tester es el responsable de ayudar al cliente a seleccionar y escribir las pruebas de
aceptacin para cada historia de usuario. Tiene la responsabilidad de ayudar al cliente a
tomar las decisiones correctas sobre que significa la calidad para su proyecto.
El tester se encarga de ayudar al cliente a definir los criterios de calidad para cada
historia de usuario. Estos criterios son necesarios para los programadores a la hora de
estimar la duracin de cada historia. Cuanto ms precisos sean los criterios ms
exactas sern las estimaciones [Crispin.2001]
Segn Lisa Crispin y Tip House [CRISPIN, HOUSE. 2002] el testing es la nica disciplina
que requiere experiencia y entrenamiento, adems de habilidad para resolver
problemas. Tambin involucra tener tacto y destreza en la comunicacin para generar
una relacin productiva con clientes y programadores.
El tester escribe las pruebas de aceptacin, pero NO debe escribir las pruebas unitarias,
esto lo debe hacer cada desarrollador empleando herramientas para su automatizacin.
Luego de ejecutar las pruebas de aceptacin el tester debe exponer los resultados
obtenidos, en un lugar al cual todos los integrantes del equipo puedan acceder, para
informar los defectos encontrados. Esto permite tener una clara visin del avance del
proyecto.

Pgina 8 de 22

Gestin de Software

3.2

Testing en eXtreme Programming

Programacin por pares

Todo el cdigo producido en XP es realizado en parejas, dos personas frente a una
computadora. Los roles en la pareja son de conductor y acompaante. El
conductor es el que maneja el teclado y el ratn (mouse), pensando la mejor manera
de cmo implementar el cdigo. El acompaante tiene como tarea observar y corregir
en todo momento, los errores cometidos por el conductor, considerar soluciones
alternativas y sugerir nuevos casos de prueba. Esta constante revisin produce cdigo y
un diseo con mayor calidad.
El cdigo producido debe cumplir con todos los estndares de programacin
permitiendo el entendimiento de este por todos los programadores y acompaantes,
nunca debe haber mas de dos integrantes al mismo tiempo. Peridicamente se debe
intercambiar los roles de la pareja. De esta forma, se asegura transmitir el conocimiento
del sistema a todo el equipo y eliminar las dependencias de personas que conocen
partes del sistema.
La programacin en pareja tiene muchas ventajas. La constante revisin del cdigo, ya
que existe una persona observando todo lo que haga la otra programa. El alternar de
los integrantes de las parejas frecuentemente lo cual lleva a que todos tienen un
conocimiento general del sistema, eliminando las dependencias hacia personas que
conocen partes especificas del cdigo. Por otro lado permite que los programadores con
diferente experiencia puedan trabajar juntos, beneficiando a los ms inexpertos que
programan aprendiendo de los ms expedientes.
A su vez existe una prctica llamada Propiedad colectiva que se basa en que todo el
cdigo desarrollado pertenece al equipo, todos los integrantes del equipo tienen la
misma responsabilidad sobre todo el sistema. Al ser el equipo el responsable, cualquier
integrante esta autorizado a realizar los cambios que se consideren necesarios para
mejorar la calidad del mismo. De esta manera se logra descentralizar aun ms el
conocimiento y no generar dependencias hacia las personas.
Todo esto lleva a una constante verificacin del cdigo mientras este se esta
generando, reduciendo considerablemente de esta manera la probabilidad de faltas en
el sistema, por lo tanto la disminucin de fallas en el mismo, por otro lado lleva a
generar un cdigo claro y entendible por todos los programadores, con algoritmos y
casos de pruebas bien elaborados y revisados, mejorando as la calidad del producto.

3.3

Pruebas Unitarias
Una prueba unitaria es la verificacin de un mdulo (unidad de cdigo) determinado
dentro de un sistema. El concepto de mdulo vara de acuerdo al lenguaje de
programacin que estemos utilizando; por ejemplo, en Java sera una clase. Las pruebas
unitarias nos aseguran que un determinado mdulo cumpla con un comportamiento
esperado en forma aislada antes de ser integrado al sistema.
Los programadores realizan estas pruebas cuando: la interfaz de un mtodo no es clara,
la implementacin es complicada, para testear entradas y condiciones inusuales, luego
de modificar algo. stas deben contemplar cada mdulo del sistema que pueda generar
fallas. Para poder integrar el cdigo realizado al ya existente, el mismo debe aprobar
satisfactoriamente todos los casos de prueba definidos.
En XP los programadores deben escribir las pruebas unitarias para cada mdulo antes
de escribir el cdigo. No es necesario escribir casos de prueba para todos los mdulos,
slo para aquellos en que exista la posibilidad de que puedan fallar.
Luego de escribir el cdigo, los programadores ejecutan las pruebas, las cuales deben
resultar 100% efectivas para que el cdigo pueda integrarse al sistema. En caso
contrario hay que solucionar los errores y ejecutar nuevamente los casos de prueba
hasta lograr que ninguno de ellos.
Pgina 9 de 22

Gestin de Software

Testing en eXtreme Programming

Las pruebas son automatizadas utilizando herramientas como xUnit, de forma tal de
poder soportar un testing continuo y mantener organizados los casos de pruebas.
La ausencia de las pruebas unitarias lleva a tener que invertir una gran cantidad de
horas en sesiones de debugging al momento de integrar el cdigo con el sistema
existente.
Las pruebas unitarias brindan una inmediata retroalimentacin el la realizacin de su
trabajo, permiten al programador saber si una determinada funcionalidad se puede
agregar al sistema existente sin alterar el funcionamiento actual del mismo. Tambin
permiten la aplicacin de otras prcticas como refactoring y diseo simple al estar
respaldados por efectivos casos de prueba.
La retroalimentacin que se genera por la realizacin de las pruebas, deriva en un
constante aprendizaje sobre el sistema a realizar, lo cual permite que los
programadores desarrollen de forma ms rpida y eficiente.
3.4

Herramientas para automatizar las pruebas unitarias

En los ltimos aos se han creado una serie de frameworks que permiten automatizar
las pruebas unitarias, permitido definir estas y ejecutarlas en reiteradas ocasiones.
Estos frameworks son denominados xUnit.
Estos framewors se basan en los conceptos de Test Case y Test Suite, el primer es la
prueba unitaria del componente a testear, la segunda nos permite agrupar varias
pruebas unitarias para poder ejecutarlas en forma conjuntas.
La finalidad de los Test Case es probar funcionalidad de un determinado modulo. En
lenguajes orientados a objetos seria probar los mtodos de una clase. Los Test Suite
permiten agrupar todas las pruebas de un componente, permitiendo ejecutar de forma
conjunta todas las pruebas definidas para un Componente.
A medida que el desarroll va avanzando y se van definiendo mas caso de pruebas,
estas herramientas nos permiten hacer pruebas de regresin. De esta forma si hay
cambios en clases ya testeadas se les puede volver a evaluar su correctitud. Esto es
muy til en el caso de XP donde cuando hay cambios se evalan y hace una
refactorizacion para mantener de forma simple el producto, estas herramientas nos
permiten poder reevaluar que tras los cambios se sigan cumpliendo las pruebas
anteriormente definidas.
Las principales ventajas de la utilizacin de pruebas unitarias automticas en el
desarrollo son:
1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador
cambie el cdigo para mejorar su estructura (lo que se ha dado en llamar
refactorizacin), puesto que permiten hacer pruebas sobre los cambios y as
asegurarse de que los nuevos cambios no han introducido errores.
2. Simplifica la integracin: Puesto que permiten llegar a la fase de integracin
con un grado alto de seguridad de que el cdigo est funcionando
correctamente. De esta manera se facilitan las pruebas de integracin.
3. Documenta el cdigo: Las propias pruebas son documentacin del cdigo
puesto que ah se puede ver cmo utilizarlo.
4. Los errores estn ms acotados y son ms fciles de localizar: dado que
tenemos pruebas unitarias que pueden desenmascararlos.

3.5

Un ejemplo utilizando JUnit

JUnit es la framework xUnit para la plataforma Java, esta nos permite definir los casos
de prueba unitarios para las clases importantes del sistema. Permite ejecuta las clase
de forma controlada para poder evaluar si esta se comporta de la manera esperada.
JUnit ejecutara las pruebas sobra la clase y comparara contra los resultados esperados,
Pgina 10 de 22

Gestin de Software

Testing en eXtreme Programming

si los resultados son correctos indicara que las pruebas fueron exitosas, en caso que
alguno de los resultados no sea el esperado Junit indicara que se produjo un fallo he
indicara el o los mtodos que no pasaron sus evaluaciones. Es importante destacar que
Junit seguir con las pruebas aunque ya se haya detectado una falla.
Este framework es Open Source y fue desarrollado por Kent Beck y Erich Gamma, el
primero uno de los creadores de XP y el segundo conocido por ser uno de los lideres del
proyecto Eclipse y por sus trabajos en Patrones de Diseo.
En JUnit, los casos de prueba son clases que derivan de la clase TestCase, e
implementan mtodos sin parmetros de nombre testXXX, donde XXX es una
descripcin de lo que est probando ese mtodo (Beck y Gamma, n.f.).
Las pruebas implementadas que extendern de la clase TestCase tiene la posibilidad de
sobre-escribir los mtodos setUp() y tearDown(), los cuales son invocados antes y
despus de cada mtodo de test. Esto permite inicializar y liberar recursos entre la
ejecucin de los distintos mtodos en la clase, permitiendo asegurarse de que no hay
efectos colaterales entre la ejecucin de los distintos test.
El propio framework incluye formas de ver los resultados (runners) que pueden ser en
modo texto, grfico (AWT o Swing) o como tarea en Ant.
En la actualidad las herramientas de desarrollo como NetBeans y Eclipse cuentan con
plug-ins que permiten que la generacin de las plantillas necesarias para la creacin de
las pruebas de una clase Java se realice de manera automtica, facilitando al
programador enfocarse en la prueba y el resultado esperado, y dejando a la
herramienta la creacin de las clases que permiten coordinar las pruebas.
Los TestCase pueden unirse en rboles de TestSuite que invocan automticamente
todos los mtodos testXXX() definidos en cada TestCase. Un TestSuite es una
composicin de otros tests, bien TestCase u otros TestSuite. El comportamiento
compuesto exhibido por los TestSuite te permite ensamblar suites de tests, de una
profundidad arbitraria, y ejecutar todos los tests automticamente para obtener un
simple estado de pasado o fallado.
Los mtodos de prueba consisten en verificar que los resultados obtenidos sean los
esperados. Para esto JUnit ofrece un conjunto de mtodos (assert, assertEquals,
assertTrue y otros) que permiten realizar comparaciones entre objetos o comprobar la
veracidad de una condicin determinada.
Para realizar un caso de test en Junit se deben seguir los siguientes pasos.
Escribir un test para probar un nico componente de software. Enfocndose en escribir
test que comprueben el comportamiento que tiene el mayor potencial de rotura, as
puede maximizar los beneficios con respecto a la inversin en testeo.
Para escribir un test, sigue estos pasos:
1. Define una subclase de TestCase.
2. Sobrescribe el mtodo setUp() para inicializar el objeto(s) a probar.
3. Sobrescribe el mtodo tearDown() para liberar el objeto(s) a probar.
4. Define uno o ms mtodos testXXX() pblicos que prueben el objeto(s) y aserten
los resultados esperados.
5. Define un mtodo factora suite() esttico que cree un TestSuite que contenga
todos los mtodos testXXX() del TestCase.
6. Opcionalmente, define un mtodo main() que ejecute el TestCase en modo por
lotes.
Supongamos que tenemos la siguiente clase Money (moneda) con sus correspondientes
mtodos y propiedades:
Pgina 11 de 22

Gestin de Software

Testing en eXtreme Programming

class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}
public int amount() {
return fAmount;
}
public String currency() {
return fCurrency;
}
public Money add(Money m) {
return new Money(amount()+m.amount(), currency());
}
public boolean equals(Object anObject) {
if (! anObject instanceof Money)
return false;
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
}
La siguiente tabla muestra una breve descripcin de los mtodos de la clase:
Mtodo

Descripcin

public Money(int amount,

currency)
public Money add(Money m)
public
boolean
anObject)

String

equals(Object

Constructor de la clase Money.

Devuelve un objeto Money resultante de la suma
de los dos montos.
Indica si dos objetos Money son iguales,
comparando sus propiedades (Currency y Value).

Los pasos a seguir, para construir un caso de prueba para la clase Money, son los
siguientes:
1. Definir la clase de prueba que derive de la clase TestCase.
import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.framework.Test;
public class MoneyTest extends TestCase {
//
private Money mobj12USD;
private Money mobjf14USD;
//
}
2. Sobreescribir el mtodo setUp() para inicializar el/los objetos implicados en la
prueba (si es necesario).
Pgina 12 de 22

Gestin de Software

Testing en eXtreme Programming

protected void setUp() {

mobj12USD = new Money(12, "USD");
mobjf14USD = new Money(14, "USD");
}
3. Sobreescribir el mtodo tearDown() para liberar el/los objetos implicados en la
prueba (si es necesario).
4. Definir uno o ms mtodos con signatura testXXX() que prueban las diferentes
funcionalidades y casos de la clase.
public void testAdd() {
Money expected = new Money(26, "USD");
Money result = mobj12USD.add(mobjf14USD);
assert(expected.equals(result));
}
public void testEquals() {
assert(!mobj12USD.equals(null));
assert(mobj12USD, mobj12USD);
assertEquals(mobj12USD, new Money(12, "USD")); // (1)
assert(!mobj12USD.equals(mobjf14USD));
}
5. De ser necesario, definir un mtodo de clase suite() que crea una TestSuite a la
que se aaden todos los mtodos testXXX() del TestCase.
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new MoneyTest("testEquals"));
suite.addTest(new MoneyTest("testAdd"));
return suite;
}
6. Definir un mtodo main() que ejecuta el TestCase (o invocar el Test Runner en
modo grfico y especificar el caso de prueba o la suite).
public static void main(String args[]) {
test.textui.TestRunner.run(suite());
}
La interfaz de usuario en modo grfico presenta una barra de progreso la cual toma
color verde si todas las pruebas ejecutadas son 100% satisfactorias, o color rojo si fall
alguna. En este ltimo caso se despliega en una lista la descripcin de las fallas o
errores generados.

Figura 1. Interfaz de usuario de Junit (Beck y Gamma, n.f.)

Pgina 13 de 22

Gestin de Software

Testing en eXtreme Programming

La automatizacin de las pruebas unitarias permite al programador ejecutar todas las

pruebas cuantas veces sea necesario, logrando as determinar en forma inmediata si el
cambio realizado a un mdulo del sistema se puede integrar al mismo sin alterar el
funcionamiento actual.
3.6

Pruebas de aceptacin
Las pruebas de aceptacin son pruebas de caja negra definidas por el cliente para cada
historia de usuario, y tienen como objetivo asegurar que las funcionalidades del sistema
cumplen con lo que se espera de ellas. En efecto, las pruebas de aceptacin
corresponden a una especie de documento de requerimientos en XP, ya que marcan el
camino a seguir en cada iteracin, indicndole al equipo de desarrollo hacia donde
tiene que ir y en qu puntos o funcionalidades debe poner el mayor esfuerzo y
atencin.
Las pruebas de aceptacin permiten al cliente saber cuando el sistema funciona, y que
los programadores conozcan que es lo que resta por hacer. (Jeffries et al. 2000, 45)
Las pruebas de aceptacin tienen una importancia crtica para el xito de una iteracin.
Por lo tanto el tester debe tenerlas prontas lo antes posible a partir del comienzo de la
iteracin, y lograr que el cliente las apruebe para poder presentrselas cuanto antes al
equipo de desarrollo.

3.6.1 El rol del cliente

En XP las pruebas de aceptacin son en ltima instancia responsabilidad del cliente ya
que deben reflejar los requerimientos y las funcionalidades que se quieren obtener en
cada iteracin. Es ms, en algunos proyectos realizados con la metodologa XP, el
cliente llega a escribir las pruebas de aceptacin.
Sin embargo la mayora de los clientes, especialmente cuando son externos al proyecto,
son personas muy ocupadas con trabajos de tiempo completo, por lo tanto no disponen
de demasiado tiempo para dedicarle al proyecto. Adems generalmente no tienen ni la
experiencia ni los conocimientos tcnicos necesarios para escribir correctamente las
pruebas de aceptacin. Por esta razn el tester debe reunirse con el cliente para
interpretar sus ideas y sus necesidades y luego poder escribir los casos de prueba
correspondientes. Tambin es importante que el tester gue al cliente en la definicin de
los criterios de calidad, realizando diferentes cuestionarios e identificando lo que es
crucial para el.
Es importante tambin que el cliente especifique criterios de estabilidad y performance
si los mismos son relevantes para la iteracin. Por ejemplo, si un sistema tiene que
manejar un gran nmero e usuarios o transacciones a una velocidad determinada, el
grupo de desarrollo debe aumentar las horas estimadas para contemplar estas
caractersticas. En muchos casos, la estabilidad y la performance del sistema se
convierten en historias de usuario independientes.
Por otra parte, es responsabilidad del cliente brindar los datos para poder ejecutar las
pruebas de aceptacin. Estos datos podran ser creados o generados especficamente
para las pruebas, pero generalmente los clientes ya cuentan con archivos o datos reales
que pueden poner a disposicin del equipo de desarrollo. Esto permite que estas
pruebas sean lo ms parecidas posible al ambiente de produccin en donde se va a
utilizar el sistema, logrando as una disminucin importante de las fallas detectadas
luego de la implantacin del mismo. Segn Crispin y Tip House (2002) los datos de
prueba son tan importantes como las pruebas en s mismas.
La mayora de los clientes no tienen claro en una primera instancia todas las
caractersticas de cada historia de usuario. Muchas veces asumen que los
programadores conocen todas sus necesidades, lo que provoca decepcin en el
Pgina 14 de 22

Gestin de Software

Testing en eXtreme Programming

momento en el cual el cliente recibe las funcionalidades implementadas durante la

iteracin. Es por esto que el tester debe interactuar con el cliente de manera de no
dejar ningn detalle sin especificar dentro de las pruebas de aceptacin.
Crispin (2001) propone la revisin de las pruebas de aceptacin junto con los
programadores, ya que muchas veces existen pruebas unitarias que se superponen con
alguna prueba de aceptacin propuesta por el cliente. Es ms, en ocasiones los
programadores sugieren que determinadas pruebas de aceptacin se realicen como
pruebas unitarias, logrando as optimizar el esfuerzo.
3.6.2 Criterios de aprobacin
En XP las pruebas de aceptacin cumplen con el objetivo de indicarnos cuando las
funcionalidades de una iteracin han sido completadas exitosamente. A diferencia de
las pruebas unitarias, el criterio de aprobacin de las pruebas de aceptacin no tiene
que se necesariamente de 100% de efectividad. Todos sabemos que es imposible
esperar un cdigo totalmente libre de errores, por lo tanto es necesario definir un
criterio de aprobacin para saber cuando el software est listo para ser liberado.
El cliente podra demandar que el 100% de los casos de prueba sean exitosos para
pasar de iteracin. Sin embargo como en XP las iteraciones tienen que terminar en
fecha y los tiempos lmites de entrega no son negociables, esto provocara un tiempo
de estimacin mayor para cada historia de usuario. Por lo tanto, generalmente se
sugiere que el cliente incluya pruebas de aceptacin no crticas. Si estas pruebas se
superan exitosamente generan una cuota extra de confianza en el cliente, pero si las
mismas fallan en el fin de una iteracin el cliente puede decidir repetir dichas pruebas
al final de la siguiente iteracin aumentando el grado de criticidad de las mismas.
3.6.3 Definicin de los casos de prueba
Una vez que se comprendieron los requerimientos del cliente para las pruebas de
aceptacin estamos en condiciones de comenzar a definir los casos de pruebas. Cabe
recordar que el objetivo de estas pruebas no es tener un conjunto de casos escritos que
cubran el 100% del cdigo, sino poder realizar el testing del sistema desde el punto de
vista del usuario. En XP se considera que las pruebas de aceptacin deben consistir en
un conjunto mnimo (no pobre ni insuficiente) de casos que cubran los requerimientos
de negocios fundamentales planteados por el cliente.
Para escribir los casos de prueba se deben tener en cuenta ciertas consideraciones
importantes. En primer lugar cada caso debe servir para obtener un feedback rpido y
concreto de cmo se est desarrollando la iteracin y el proyecto. Se tienen que tratar
de evitar los casos de pruebas extensos que incluyan un gran nmero de pasos. Los
casos escritos deben ser concisos y hay que documentar por separado los pasos del
caso y los datos de prueba en s mismos. Es importante sealar tambin que todos los
casos de prueba cumplidos con xito en iteraciones anteriores se deben seguir
cumpliendo en todas las iteraciones, y si se produce un error aunque sea en un nico
paso del caso de prueba se considera que todo el caso fall.
A continuacin presentamos un ejemplo de un caso de prueba de aceptacin tomado
de Crispin (2001). En la figura 1 se muestra el resumen del caso, en la figura 2 se
detallan los pasos del caso y las acciones que se deben llevar a cado, y en la figura 3 se
especifican los datos de las diferentes pruebas realizadas.

Pgina 15 de 22

Gestin de Software

Testing en eXtreme Programming

FIGURA 2 Resumen del caso de prueba Login

FIGURA 3 Pasos y acciones del caso de prueba Login (abreviado)

FIGURA 4 Datos de entrada y resultados del caso de prueba Login

Por ltimo cabe mencionar que XP recomienda la automatizacin de los casos de
pruebas de aceptacin para permitir que sean ejecutados por lo programadores ni bien
tengan una porcin del cdigo ms o menos terminada. De todas formas esto depende
de cada caso y del tipo de proyecto, ya que algunas veces el costo de automatizar los
casos de prueba y luego mantenerlos es muy alto y por lo tanto se opta por la ejecucin
manual de los mismos. Es muy comn que los casos de pruebas de una iteracin no se
puedan automatizar en esa misma iteracin por problemas de tiempo, pero a veces
esta tarea se puede realizar en iteraciones siguientes ya que estos casos se van a
correr en todas las sucesivas iteraciones.
3.6.4 Presentacin de los resultados de las pruebas de aceptacin

Pgina 16 de 22

Gestin de Software

Testing en eXtreme Programming

Otra importante diferencia entre las pruebas de aceptacin y las pruebas unitarias es
que para las de aceptacin la presentacin de lo resultados es importante, en cambio
para las unitarias no tiene mucho sentido ya que siempre se requiere un 100% de
efectividad. Beck (2000) recomienda la exhibicin de los resultados que se obtienen al
ejecutar las pruebas de aceptacin, generando reportes y grficas que desplieguen los
porcentajes de efectividad obtenidos. Estos ndices permiten evaluar si el equipo de
desarrollo esta realizando un buen trabajo o no. Es importante mantener esta
informacin estadstica actualizada y visible para todos los integrantes del proyecto.
Crispin (2001) propone el siguiente cuadro de resumen donde presenta tanto grfica
como numricamente los casos de pruebas escritos, ejecutados y exitosos.

FIGURA 5 Cuadro de resumen de los casos y resultados de las pruebas de

aceptacin
Otro ejemplo presentado en Jeffries 1999 intenta mostrar la cantidad de casos de
pruebas de aceptacin ejecutados en cada iteracin, diferencindolos entre los casos
exitosos, los casos que fallaron y los que no fueron validados por el cliente.

FIGURA 6 Resultados de las pruebas de aceptacin al final de cada iteracin

En la figura 5 podemos observar que hay una clara tendencia que indica que en cada
iteracin se incrementen los casos escritos y ejecutados con respecto a la anterior.
Adems para que el proyecto culmine de forma exitosa es necesario que en las
Pgina 17 de 22

Gestin de Software

Testing en eXtreme Programming

iteraciones finales los casos con error y los no validados por el cliente disminuyan,
llegando a la ltima iteracin con el 100% de los casos validados.
3.7

Experiencia personal
En esta seccin se da una opinin personal referente al desarrollo y testing en XP,
basado en la experiencia adquirida en el curso de ingeniera de software en el ao
2003.
En ese ao se pona en prctica esta metodologa de desarrollo a modo de evaluacin,
la idea era ver la factibilidad de incorporar dicha metodologa a las ya existentes en el
curso (RUP y ModsGx). Por lo visto no result muy satisfactoria dicha metodologa, ya
que no se ha vuelto a aplicar, en un principio porque el coach se ve sobrecargado al
momento de dirigir los grupos, ya que los grupos saben muy poco (o nada) de la
metodologa y todo es nuevo para los estudiantes.
Dos de los actuales integrantes de este grupo fuimos partcipes de dicha experiencia,
asumiendo los roles de Analista Desarrollador y Verificador Desarrollador.
Los grupos que aplicaron esta metodologa estaban compuestos por siete integrantes,
se desarrollaba sobre GeneXus + WorkFlow utilizando para ello el generador java
desarrollando para Web. Ambos grupos que aplicaron GXP (GeneXus Extreme
Programming) tenin un cliente comn, el SECIU, a manos de la Ing. Mariela de Leon.
El proyecto a desarrollar fue un prototipo de factibilidad referente al manejo y
seguimiento de expedientes tanto electrnicos como en papel para la Universidad.
Dado que la metodologa exige ciertos puntos bsicos fue necesario introducir
modificaciones, como por ejemplo incorporar un rol nuevo que libere al cliente de la
escritura de historias (Analista), recorte de horas de trabajo (XP supone 40 horas
semanales GXP 15 horas semanales), el verificador asume la responsabilidad de
escribir las pruebas funcionales y validarlas con el cliente, se modific tambin el
concepto de cliente on site o cliente en el lugar ya que se pactaban reuniones
semanales con el y el equipo de desarrollo.
Los equipos de desarrollo encontraron dificultades al momento de realizar las pruebas
tanto unitarias por parte de los desarrolladores como tambin las pruebas funcionales
por parte del verificador, ya que la herramienta usada (Racional Robot) hace fuerte uso
de la interfaz grfica, la cual estaba en constante modificacin, lo cual hacia perder
varias horas en retrabajo por parte de quienes realizaban los scripts de pruebas.
No queda claro el concepto de unidad, ya que por ejemplo en Java una unidad pede ser
considerada una clase y verificarla con jUnit, en cambio en GeneXus tenemos el
concepto de objeto GeneXus (transaccin, reporte, procedimiento y webpanel), e
intentar probar un procedimiento con Rational Robot en una prueba unitaria resultaba
compleja. Lo cual llevaba un entrenamiento adicional sobre la herramienta Rational
Robot, cuyo resultado era que el test unitario se realizara a mano o no se realizara
(esto implicara un desviamiento total sobre la metodologa ya que se exige que las
pruebas sean automatizadas) y dejando para probar directamente la unidad dentro de
la prueba funcional.
Una de las prcticas claves en XP es la programacin en pares, dicha prctica se
debera seguir como en XP tradicional, pero dado que los integrantes de los equipos
tienen discordancia horaria es difcil conseguir pares para rotar dos veces a la semana.
Como solucin a este problema surge la idea de juntarnos los fines de semana y luego
de la reunin semanal, continuar con el desarrollo haciendo el cambio de par
respectivo.
Esto no quiere decir que XP no sea aplicable sino que se necesitan ciertas condiciones
para encarar un proyecto con esta metodologa, y es difcil conseguirlo en el contexto
de la facultad.
Pgina 18 de 22

Gestin de Software

Testing en eXtreme Programming

Pgina 19 de 22

Gestin de Software

Testing en eXtreme Programming

CONCLUSIONES
El tester es el responsable de ayudar al cliente a seleccionar y escribir las pruebas de
aceptacin para cada historia de usuario. Tiene la responsabilidad de ayudar al cliente a
tomar las decisiones correctas sobre que significa la calidad para su proyecto.
El tester escribe las pruebas de ACEPTACION, pero NO las pruebas UNITARIAS, esto lo
debe hacer cada desarrollador.
La prctica de programacin por pares puede resultar muy buena si los pares se llevan
bien y son unidos, las ventajas se ven en que el cdigo se encuentra bajo revisin
continua. Se ve una mejora en la calidad del cdigo ya que se utiliza siempre el
estndar.
Los casos de prueba se pueden discutir con el par al momento de implementar, lo que
puede llevar a tener casos de prueba ms completos.
La prctica de diseo simple no quiere decir un mal diseo, sino el diseo ptimo que
se ajuste solo a las necesidades.
Unas de las principales ventajas que vemos en XP es que todo el equipo es conciente
del estado del proyecto, y adquiere un conocimiento global sobre las funcionalidades (o
historias) del mismo, ya que la continua rotacin de los pares evita la aparicin de
expertos en determinadas reas del sistema.
Las pruebas unitarias como se dijo anteriormente son una actividad fundamental en XP,
deben ser automatizadas y elaboradas antes y durante la implementacin de un
mdulo. Luego de terminada la implementacin del mismo las pruebas unitarias deben
ser todas correctas, asegurando as el buen funcionamiento del mdulo, es necesario
que todas las pruebas sean correctas para poder integrar el mdulo nuevo al sistema
existente.
Todas las pruebas deben ser automatizadas ya que en cada integracin deben correrse
todas las unitarias como funcionales y deben pasar a ser 100% correctas, de lo
contrario es factible que el mdulo nuevo tenga conflictos con el sistema de la etapa
anterior.
La automatizacin de las pruebas
Fomentan el cambio: facilitan la refactorizacin, puesto que permiten hacer
pruebas sobre los cambios y as asegurarse de que los nuevos cambios no han
introducido errores.
Simplifica la integracin: Puesto que permiten llegar a la fase de integracin con
un grado alto de seguridad de que el cdigo est funcionando correctamente. De
esta manera se facilitan las pruebas de integracin.
Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto
que ah se puede ver cmo utilizarlo.
Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos
pruebas unitarias que pueden desenmascararlos.
En XP las pruebas de aceptacin son pruebas de caja negra y debera ser
responsabilidad del cliente la escritura de casos y definicin de criterios para la
aceptacin del sistema.
Las pruebas de aceptacin en XP permiten verificar que las funcionalidades de cada
iteracin se cumplan correctamente.
Se debe definir un criterio de aprobacin de las mismas que puede no ser de un 100%
de efectividad.
Se deben presentar los resultados de las mismas a todo el equipo de desarrollo.

Pgina 20 de 22

Gestin de Software

Testing en eXtreme Programming

Pgina 21 de 22

Gestin de Software

Testing en eXtreme Programming

REFERENCIAS
[BECK, Kent. 2000] Extreme Programming Explained: Embrance Change. Massachusetts:
Addison-Wesley.
[CRISPIN. 2001]
12/04/2004].
article.pdf>

CRISPIN Lisa. 2001. Extreme Rules of the Road. [online] [citado

Disponible

en

internet:

<http://www.testing.com/agile/crispin-xp-

[CRISPIN, HOUSE. 2002] CRISPIN, L.; TIP HOUSE. 2002. Testing Extreme Programming.
Massachusetts: Addison-Wesley.
[JEFFRIES, Ron. 1999b]
Extreme Testing. [online] [citado 12/04/2004].
Disponible en internet:
<http://www.xprogramming.com/publications/SP99 Extreme
Web.pdf>

for

[FACULTAD DE INGENIERA] Memoria organizacional 2003.

Disponible en internet:
<http://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/index.htm
>

Pgina 22 de 22