Testing en XP

 

Gestión de Software

Testing en eXtreme Programming

Gestión de Software 2006 Testing en eXtreme  Programming 

Grupo 6 Nombre Dayvis Malfará Diego Cukerman Fernando Cócaro Juan uan Pa Pabl bloo Ca Cass ssin inel ellili

Cédula 3860676-3 3348340-9 4347371-1 31000533-88

Renzo SSééttimo

2766129-5 Página 1 de 19

 

Gestión de Software

Testing en eXtreme Programming

Página 2 de 19

 

Gestión de Software

Testing en eXtreme Programming

Este informe tiene como objetivo investigar los métodos y prácticas empleadas por la metodología de desarrollo de software eXtreme Programming  (Programación 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.

Página 3 de 19

 

Gestión de Software

Testing en eXtreme Programming

En este capít capítulo ulo darem daremos os una pequeña introducció introducciónn a eXtrem eXtremee Program Programming, ming, sin prete pretender nder abarcar demasiado en esta metodología.

eXtreme Programming de ahora en adelante XP, es una metodología 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 característica su adaptación a entornos cambiantes. Esto es posible porque el proceso esta diseñado para adaptarse en forma inmediata a los cambios, con bajos costos asociados en cualquier etapa del ciclo de vida. “XP es una metodología ágil para pequeños o medianos equipos, desarrollando software cuando los  requerimientos son ambiguos o rápidamente cambiantes.”  [Beck, 2000]

Esta diseñada para trabajar en pequeños o medianos equipos de hasta 12 integrantes. Esto fomenta la comunicación e interacción entre sus integrantes, logrando el trabajo en equipo. De esta forma, es posible reducir el costo de transferir información 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 quién fija las prioridades, y los programadores desarrollan lo que es necesario para ese momento en particular. En pequeñas iteraciones el sistema va creciendo según los requerimientos solicitados por el cliente, él cual puede observar el avance del proyecto en todo momento.

Kent Beck enuncia doce prácticas que sirven como un punto de partida para un equipo XP, las cuales se basan en los valores de simplicidad, comunicación, retroalimentación y coraje. Podemos plantear estas prácticas en tres capas: 

Programación: Diseño Simple, Refactoring, Estándares de código, Pruebas.



Prácticas del equipo: Pequeñas Pequ eñas entre entregas, gas, Metá Metáfora, fora, Progra Programació maciónn por pares pares,, Propie Propiedad dad colec colectiva, tiva, Integra Integración ción continua, 40 horas semanales.



Los procesos: Cliente on-site El juego de la planificación, Pruebas, Pequeñas entregas. ,

Como podemos observar hay prácticas que se repiten en las diferentes capas, ya que están relacionadas en cada una de ellas.  A continuación se presenta un detalle de cada práctica: •

•

El juego de la planificación Mediante esta práctica se realiza la planificación 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. Pequeñas entregas Las entregas deben ser lo más pequeñas 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 forma gradual hasta finalizar el proyecto. En cada entrega los programadores obtienen retroalimentación del cliente determinando si lo implementado es lo que en realidad necesita. Página 4 de 19

 

Gestión de Software •

•

•

•

Testing en eXtreme Programming

Metáfora La metáfora 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 aplicación es que hace más fácil la comprensión del sistema y colabora para mantener un diseño simple. Diseño simple El diseño se va creando en forma progresiva progresiva,, sin prever las necesidade necesidadess del futuro. Al tener un diseño simple capaz de mantener las características 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 prácticas fundamentales en las cuales se basa XP. Esta actividad activ idad se realiz realizaa en forma continua a lo largo del proye proyecto. cto. Existen dos tipos de prueba pruebas, s, las unitarias y las de aceptación. Las pruebas unitarias son definidas por los programadores antes de comenzar a escribir código. Éstas deben contemplar cada módulo del sistema que pueda generar fallas. Para poder integrar el código 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 aceptación para cada historia de usuario a principio de cada iteración. Las pruebas de aceptación se utilizan para validar que cada requerimiento implementado funciona como se había especificado. Refactoring

Significa mejorarlaelcomplejidad diseño del del código sin ycambiar funcionalidad actual. Aplicar esta técnica permite reducir código eliminarlaposibles redundancias. •

•

•

•

Programación por pares To Todo do el có códi digo go prod produc ucid idoo en XP es real realiz izad adoo en pare pareja jas, s, do doss pe pers rson onas as fr fren ente te a un unaa computadora. Los roles en la pareja son de “conductor” y “acompañante”. El “conductor” es el que man anej ejaa el te tecl clad adoo y el ra rató tónn (mouse), pens pensan ando do la me mejo jorr ma mane nera ra de có cómo mo implementar el código. El “acompañante” tiene como tarea observar y corregir los errores cometidos por el “conductor”, considerar soluciones alternativas y sugerir nuevos casos de prueba. Esta constante revisión produce código y un diseño con mayor calidad. Periódicamente 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 práctica se basa en que todo el código 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. Integración continua La integración de código se debe realizar en forma continua, esto implica al menos en un lapso de un día de trabajo y de ser posible cada unas pocas horas. La ventaja de la integración continua es obtener retroalimentación lo más rápido posible.  Además de ser más sencilla que las l as integraciones que se realizan luego de varias semanas de programación. 40 horas semanales Esta práctica expone que 40 es la cantidad de horas que se debe dedicar al trabajo semanalmente. esta manera se logra cometer menos errores por cansancio y aumentar la productividad delDeequipo. Página 5 de 19

 

Gestión de Software •

•

Testing en eXtreme Programming

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 más del equipo. Contar con un cliente en el lugar de trabajo fomenta la comunicación y reduce la posibilidad de malentendidos y tiempos de espera. Estándares de código El equipo de programadores define en forma consensuada los estándares de programación que utilizará. utilizará. De esta manera se logra obtener un códig códigoo uniforme, como si el sistema fuera progra pro grama mado do por una sol solaa per person sona. a. Esta Esta prá prácti ctica ca fom foment entaa la com comuni unicac cación ión y fac facili ilita ta la im imple plemen mentaci tación ón de las prá prácti cticas cas de refactoring, pro progra gramac mación ión en par pareja eja y pro propie piedad dad colectiva.

Página 6 de 19

 

Gestión de Software

Testing en eXtreme Programming

En este este capí capítu tulo lo pr pres esen enta tarem remos os el te testi sting ng en XP XP,, ex expli plica cand ndoo dife diferen rentes tes pu punt ntos os acer acerca ca de su metodología. Explicaremos el rol del tester, la práctica programación por pares y todo lo referente a las pruebas, tanto unitarias como de aceptación.

El tester  es el responsable de ayudar al cliente a seleccionar y escribir las pruebas de aceptación para cada historia de usuar usuario. io. Tiene la responsabi responsabilidad lidad de ayud ayudar ar 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. usuar io. Estos criterios son necesarios para los programa programadores dores a la hora de estim estimar ar la durac duración ión de cada cada hi hist stor oria ia.. Cuan Cuanto to má máss pr prec ecis isos os sean sean lo loss cr crite iterio rioss má máss ex exac actas tas se será ránn las las estim estimac acio ione ness [Crispin.2001] Según Lisa Crispin y Tip House [CRISPIN, HOUSE. 2002] el testing es la única disciplina que requiere experiencia y entrenamiento, además de habilidad para resolver problemas. También involucra tener tacto y destreza en la comunicación para generar una relación productiva con clientes y programadores. El tester  las pruebas empleando de aceptación, pero NO debe escribir las pruebas unitarias, esto lo debe hacerescribe cada desarrollador herramientas para su automatización. Luego de ejecutar las pruebas de aceptación el tester debe exponer los resultados obtenidos, en un lu luga garr al cu cual al todo todoss lo loss in inte tegra grante ntess de dell equi equipo po pu pued edan an acce accede der, r, para para in infor forma marr los de defe fect ctos os encontrados. Esto permite tener una clara visión del avance del proyecto.

Página 7 de 19

 

Gestión de Software

Testing en eXtreme Programming

Todo el código producido en XP es realizado en parejas, dos personas frente a una computadora. Los roles en la pareja son de “conductor” y “acompañante”. El “conductor” es el que maneja el te tecla clado do y el ratón ratón (m (mous ouse) e),, pe pens nsan ando do la me mejor jor ma mane nera ra de cóm cómoo imple impleme menta ntarr el có códi digo. go. El  “acompañante” 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 revisión produce código y un diseño con mayor calidad. El cód código igo pro produc ducido ido deb debe cum cumpli plirr programadores con tod todos os losy es estánd tándare aress de nunca pro progra grama mación ción per permit mitien dodos el entendimiento de este poretodos los acompañantes, debe haber masiendo de integrantes al mismo tiempo. Periódicamente se debe intercambiar los roles de la pareja. De esta fo form rma, a, se aseg asegura ura tran transm smititir ir el cono conocim cimie iento nto de dell sist sistem emaa a to todo do el equi equipo po y el elim imin inar ar las las dependencias de personas que conocen partes del sistema. La programación programación en pareja tiene muchas ventaja ventajas. s. La const constante ante revisión del código, 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 código. Por otro lado permite que los programadores con diferente experiencia puedan trabajar juntos, beneficiando a los más inexpertos que programan aprendiendo de los más expedientes.  A su vez existe una práctica llamada Propiedad colectiva que se basa en que todo el código desarrollado pertenece al equipo, todos los integrantes del equipo tienen la misma responsabilidad sobre todo elque sistema. Al ser el equipo el responsable, cualquier integrante esta autorizado a realizar los cambios se consideren necesarios para mejorar la calidad del mismo. De esta manera se logra descentralizar aun más el conocimiento y no generar dependencias hacia las personas. Todo esto lleva a una constante verificación del código mientras este se esta generando, reduciendo co cons nsid idera erable bleme mente nte de esta esta ma mane nera ra la prob probab abili ilida dadd de falta faltass en el si sist stem ema, a, po porr lo tanto tanto la disminución de fallas en el mismo, por otro lado lleva a generar un código claro y entendible por todos tod os los pro progra gramad madores ores,, con alg algori oritmo tmoss y cas casos os de pru prueba ebass bie bienn ela elabora borados dos y rev revisa isados dos,, mejorando así la calidad del producto.

Una prueba unitaria es la verif verificación icación de un módulo (unida (unidadd de códig código) o) determina determinado do dentr dentroo de un sistema. El concepto de “módulo” varía de acuerdo al lenguaje de programación que estemos utilizando; por ejemplo, en Java sería una clase. Las pruebas unitarias nos aseguran que un determinado módulo cumpla con un comportamiento esperado en forma aislada antes de ser integrado al sistema. Los programadores realizan estas pruebas cuando: la interfaz de un método no es clara, la implementación es complicada, para testear entradas y condiciones inusuales, luego de modificar algo. Éstas deben contemplar cada módulo del sistema que pueda generar fallas. Para poder integrar el código 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 módulo antes de escribir el código. No es necesario escribir casos de prueba para todos los módulos, sólo para aquellos en que exista la posibilidad de que puedan fallar. Luego de escribir el código, los programadores ejecutan las pruebas, las cuales deben resultar 100% efectivas para que el código pueda integrarse al sistema. En caso contrario hay que solucionar errores y ejecutar utilizando nuevamente los casos decomo prueba hasta ninguno ellos. Las pruebaslosson automatizadas herramientas xUnit, de lograr forma que tal de poder de soportar un testing continuo y mantener organizados los casos de pruebas. Página 8 de 19

 

Gestión de Software

Testing en eXtreme Programming

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 código con el sistema existente. Las pruebas unitarias brindan una inmediata retroalimentación el la realización de su trabajo, permiten al programador saber si una determinada funcionalidad se puede agregar al sistema existente sin alterar el funcionamiento actual del mismo. También permiten la aplicación de otras prácticas como refactoring y diseño simple al estar respaldados por efectivos casos de prueba. pru eba. La retroalimentación que se genera por la realización de las pruebas, deriva en un constante aprendizaje sobre el sistema a realizar, lo cual permite que los programadores desarrollen de forma más rápida y eficiente.

En los últimos años se se han creado una sserie erie de frameworks que permiten automatizar las prueb pruebas as unitarias, unitari as, perm permitido itido definir estas y ejecut ejecutarlas arlas en reiterad reiteradas as ocasione ocasiones. s. Estos frame frameworks works 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 métodos 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 regresión. 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 cuandoo hay cambio cuand cambioss se evalúan y hace una refac refactoriza torizacion cion para mantener mantener de forma sim simple ple el produ product cto, o, esta estass herr herram amie ienta ntass nos pe perm rmititen en pode poderr re reev evalu aluar ar qu quee tra trass lo loss camb cambios ios se si siga gann cumpliendo las pruebas anteriormente definidas. Las principales ventajas de la utilización de pruebas unitarias automáticas en el desarrollo son: 1. : Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten permi ten hacer prueb pruebas as sobre los cambi cambios os y así asegura asegurarse rse de que los nuevos cambios no han introducido errores. 2. : Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración. 3. : Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo. 4. : dado que tenemos pruebas unitarias que pueden desenmascararlos.

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, 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 falloseguirá he indicara el pruebas o los métodos nohaya pasaron sus evaluaciones. destacar queunJunit con las aunqueque ya se detectado una falla. Es importante Página 9 de 19

 

Gestión de Software

Testing en eXtreme Programming

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 Diseño. En JUnit, los casos de prueba son clases que derivan de la clase TestCase, e implementan métodos sin parámetros de nombre testXXX, donde XXX es una descripción de lo que está probando ese método (Beck y Gamma, n.f.). Las pruebas implementadas que extenderán de la clase TestCase tiene la posibilidad de sobreescribir los métodos setUp() y tearDown(), los cuales son invocados antes y después de cada método de test. Esto permite inicializardey liberar entrecolaterales la ejecuciónentre de losladistintos métodos en la clase, permitiendo asegurarse que norecursos hay efectos ejecución de los distintos test. El propio framework incluye formas de ver los resultados (runners) que pueden ser en modo texto, gráfico (AWT o Swing) o como tarea en Ant. En la actual actualidad idad las herram herramientas ientas de desar desarrollo rollo como NetB NetBeans eans y Eclip Eclipse se cuentan con plug-i plug-ins ns que permiten que la generación de las plantillas necesarias para la creación de las pruebas de una clase Java se realice de manera automática, facilitando al programador enfocarse en la prueba y el resultado esperado, y dejando a la herramienta la creación de las clases que permiten coordinar las pruebas. Los TestCase pueden unirse en árboles de TestSuite que invocan automáticamente todos los métodos testXXX() definidos en cada TestCase. Un TestSuite es una composición de otros tests, bienmite TestCase ularotros TestSuite. El de comportamiento compuesto exhibido porr los TestSuite te per permi te ens ensamb amblar sui suites tes de tes tests, ts, una pro profun fundid didad ad arbi arbitrar traria, ia, y eje ejecuta cutar tod todos os los tes tests ts automáticamente para obtener un simple estado de pasado o fallado. Los métodos de prueba consisten en verificar que los resultados obtenidos sean los esperados. Para esto JUnit ofrece un conjun conjunto to de métodos (assert, assertE assertEquals, quals, assertT assertTrue rue y otros) que perm permiten iten realizar comparaciones entre objetos o comprobar la veracidad de una condición 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. Enfocándose en escribir test que comprueben el comportamiento que tiene el mayor potencial de rotura, así puede maximizar los beneficios con respecto a la inversión en testeo. Para escribir un test, sigue estos pasos: 1. Def Define ine una sub subclas clasee ddee TTest estCas Case. e. 2. Sobres Sobrescribe cribe eell méto método do set setUp() Up() ppara ara in inicializ icializar ar el ob objeto(s jeto(s)) a pprobar. robar. 3. Sobres Sobrescribe cribe eell méto método do tea tearDow rDown() n() para libera liberarr el oobjeto(s bjeto(s)) a pr probar. obar. 4. Defi Define ne uno uno o má máss mé méto todos dos tes testX tXXX XX() () públi públicos cos que prue pruebe benn el obje objeto to(s (s)) y aser aserten ten los resultados esperados. 5. Def Define ine un métod métodoo fa factor ctoría ía suite() suite() está estático tico que cre creee un Tes TestSu tSuite ite que cont contenga enga tod todos os los métodos testXXX() del TestCase. 6. Opcion Opcionalmen almente, te, defi define ne un mé método todo ma main() in() que eejecute jecute eell TestC TestCase ase en m modo odo por llotes. otes. Supongamos que tenemos la siguiente clase Money (moneda) con sus correspondientes métodos y propiedades: class Money { private int fAmount; private String fCurrency;

Página 10 de 19

 

Gestión de Software

Testing en eXtreme Programming 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 descripción de los métodos de la clase: Método

Descripción

public M public Mone oney(i y(int nt am amount ount,, Str String ing ccurre urrency ncy)) public Money add(Money m)

Con Constru structor ctor de llaa cl clase ase Mon Money. ey. Devuelve un objeto Money resultante de la suma de los dos montos. Indi Indica ca si do doss obj objeto etoss Money Money so sonn igu igual ales es,, com compa para rand ndoo sus propiedades (Currency y Value).

pu publi blicc bo bool olea eann equa equals( ls(Ob Objec jectt an anOb Objec ject) t)

Los pasos a seguir, para construir un caso de prueba para la clase Money, son los siguientes: 1. Defin Definirir la cl clase ase ddee prue prueba ba que deriv derivee de la clase TestC TestCase. ase. import import junit.framework.TestCase; junit.framework.TestSuite; import junit.framework.Test; public class MoneyTest extends TestCase { //… private Money mobj12USD; private Money mobjf14USD; //… }

2. Sobree Sobreescribir scribir el m método étodo se setUp() tUp() pa para ra inicia inicializar lizar el/ el/los los objeto objetoss implic implicados ados en la pru prueba eba (si es necesario). protected void setUp() { mobj12USD = new Money(12, "USD"); mobjf14USD = new Money(14, "USD"); }

Página 11 de 19

 

Gestión de Software

Testing en eXtreme Programming

3. Sobree Sobreescribir scribir el m método étodo tea tearDown rDown() () para libe liberar rar el/lo el/loss objetos im implicado plicadoss en la prueb pruebaa (si es necesario). 4. Def efin inir ir uno uno o más méto todo doss co conn si sign gnat atuura te tesstXXX tXXX() () qu quee pru rueb eban an las las dife difere rent ntes es 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 nec necesa esario, rio, de defini finirr un mé método todo de cla clase se sui suite() te() qu quee crea una Te TestSu stSuite ite a la que se añaden todos los métodos testXXX() del TestCase. public static Test suite() { TestSuite suite = new TestSuite(); TestSuite(); suite.addTest(new MoneyTest("testEquals")); suite.addTest(new MoneyTest("testAdd")); return suite; }

6. Defi Defini nirr un méto método do ma main in() () que que ej ejec ecuta uta el Test TestCa Case se (o in invo voca carr el Test Run Runne nerr en mod modoo gráfico 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 gráfico 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 descripción de las fallas o errores generados.

La automatización de las pruebas unitarias permiter al ejecutar todas las pruebasa cuantas cuanta s veces sea necesario, logrando así determinar determina enprogramador forma inmed inmediata iata si el cambio realizado un módulo del sistema se puede integrar al mismo sin alterar el funcionamiento actual. Página 12 de 19

 

Gestión de Software

Testing en eXtreme Programming

Las pruebas de aceptación 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 aceptación corresponden a una especie de documento de requerimientos en XP, ya que marcan el camino a seguir en cada iteración, indicándole al equipo de desarrollo hacia donde tiene que ir y en qué puntos o funcionalidades debe poner el mayor esfuerzo y atención.  “Las pruebas de aceptación permiten al cliente saber(Jeffries cuandoetelal.sistema funciona, y que los programadores conozcan que es lo que resta por hacer.” 2000, 45) Las pruebas de aceptación tienen una importancia crítica para el éxito de una iteración. Por lo tanto el tester debe tenerlas prontas lo antes posible a partir del comienzo de la iteración, y lograr que el cliente las apruebe para poder presentárselas cuanto antes al equipo de desarrollo.

En XP las pruebas de aceptación son en última instancia responsabilidad del cliente ya que deben reflejar los requerimientos y las funcionalidades que se quieren obtener en cada iteración. Es más, en algunos proyectos realizados con la metodología XP, el cliente llega a escribir las pruebas de aceptación. Sin embargo la mayoría de los clientes, especialmente cuando son externos al proyecto, son personas muy ocupadas trabajos tiempo completo, porno lo tanto de demasiado tie tiempo mpo par para a ded dedica icarle rle alconpro proyec yecto. to. de Ade Además más genera generalme lmente nte tie tienen nennonidisponen la ex exper perienc iencia ia ni los conocimientos técnicos necesarios para escribir correctamente las pruebas de aceptación. Por esta razón el tester debe reunirse con el cliente para interpretar sus ideas y sus necesidades y luego poder escribir los casos de prueba correspondientes. También es importante que el tester guíe al cliente en la definición de los criterios de calidad, realizando diferentes cuestionarios e identificando lo que es crucial para el. Es importante también que el cliente especifique criterios de estabilidad y performance si los mismos son relevantes para la iteración. Por ejemplo, si un sistema tiene que manejar un gran número e usuarios o transacciones a una velocidad determinada, el grupo de desarrollo debe aumentar las horas estimadas para contemplar estas características. caracterí sticas. En muchos casos, la estabilidad y la performance del sistema se convierten en historias de usuario independientes. Por otra parte, es responsa responsabilidad bilidad del cliente brindar los datos para poder ejecutar las prueba pruebass de aceptación. Estos datos podrían ser creados o generados específicamente para las pruebas, pero generalmente los clientes ya cuentan con archivos o datos reales que pueden poner a disposición del equipo de desarrollo. Esto permite que estas pruebas sean lo más parecidas posible al ambiente de producción en donde se va a utilizar el sistema, logrando así una disminución importante de las fallas detectadas luego de la implantación del mismo. Según Crispin y Tip House (2002) los datos de prueba son tan importantes como las pruebas en sí mismas. La mayoría de los clientes no tienen claro en una primera instancia todas las características de cada historia de usuario. Muchas veces asumen que los programadores conocen todas sus necesidades, lo qu quee prov provoc ocaa de dece cepc pción ión en el mo mome ment ntoo en el cu cual al el cl clie iente nte re reci cibe be las las fu funci ncion onal alid idad ades es implementadas durante la iteración. Es por esto que el tester debe interactuar con el cliente de manera de no dejar ningún detalle sin especificar dentro de las pruebas de aceptación. Crispin (2001) propone la revisión de las pruebas de aceptación junto con los programadores, ya que muchas veces existen pruebas unitarias que se superponen con alguna prueba de aceptación propuesta por el cliente. Es más, en ocasiones los programadores sugieren que determinadas pruebas de aceptación se realicen como pruebas unitarias, logrando así optimizar el esfuerzo.

Página 13 de 19

 

Gestión de Software

Testing en eXtreme Programming

En XP las pruebas de acept aceptación ación cumplen con el objeti objetivo vo de indic indicarnos arnos cuando las funcion funcionalidade alidadess de una iteración han sido completadas exitosamente. A diferencia de las pruebas unitarias, el criterio de aprobación de las pruebas de aceptación no tiene que se necesariamente de 100% de efectividad efect ividad.. Todos sabem sabemos os que es impos imposible ible esperar un códig códigoo totalm totalmente ente libre de errores, por lo tanto es necesario definir un criterio de aprobación para saber cuando el software está listo para ser liberado. El cliente podría demandar que el 100% de los casos de prueba sean exitosos para pasar de iteración. Sin embargo como en XP las iteraciones tienen que terminar en fecha y los tiempos límites de entrega no son negociables, esto provocaría un tiempo de estimación mayor para cada historia de usuario. Por lo tanto, generalmente se sugiere que el cliente incluya pruebas de aceptación no críticas. 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 iteración el cliente puede decidir repetir dichas pruebas al final de la siguiente iteración aumentando el grado de criticidad de las mismas.

Una vez que se comprendieron los requerimientos del cliente para las pruebas de aceptación 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 código, sino poder realizar el testing del sistema desde el punto de vista del usuario. En XP se considera que las pruebas de los aceptación deben de consistir en un conjunto mínimo (no pobre insuficiente) de casos que cubran requerimientos negocios fundamentales planteados por elnicliente. 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 rápido y concreto de cómo se está desarrollando la iteración y el proyecto. Se tienen que tratar de evitar los casos de pruebas extensos qu quee in incl cluy uyan an un gr gran an núme número ro de pa paso sos. s. Los Los caso casoss escri escrito toss debe debenn se serr co conc ncis isos os y ha hayy qu quee documentar por separado los pasos del caso y los datos de prueba en sí mismos. Es importante señalar también 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 continuación presentamos un ejemplo de un caso de prueba de aceptación 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.

Página 14 de 19

 

Gestión de Software

Testing en eXtreme Programming

Por último cabe mencionar que XP recomienda la automatización de los casos de pruebas de aceptación para permitir que sean ejecutados por lo programadores ni bien tengan una porción del código más 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 ejecución manual de los mismos. Es muy común que los casos de pruebas de una iteración no se puedan automatizar en esa misma iteración 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.

Otraaceptación importante importante entre pruebas deesacep aceptación tación y en las cambio pruebaspara unitari unitarias es que no para las de la diferencia presentación de las lo resultados importante, lasasunitarias tiene mucho sentido ya que siempre se requiere un 100% de efectividad. Beck (2000) recomienda la exhibición de los resultados que se obtienen al ejecutar las pruebas de aceptación, generando reportes y gráficas 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 información estadística actualizada y visible para todos los integrantes del proyecto. Cri Crispi spinn (20 (2001) 01) pro propon ponee el siguie siguiente nte cua cuadro dro de res resume umenn don donde de pre presen senta ta tan tanto to grá gráfica fica com comoo numéricamente los casos de pruebas escritos, ejecutados y exitosos.

Página 15 de 19

 

Gestión de Software

Testing en eXtreme Programming

Otro ejemplo presentado en Jeffries 1999 intenta mostrar la cantidad de casos de pruebas de aceptación ejecutados en cada iteración, diferenciándolos entre los casos exitosos, los casos que fallaron y los que no fueron validados por el cliente.

En la figura 5 podemos observar que hay una clara tendencia que indica que en cada iteración se incrementen los casos escritos y ejecutados con respecto a la anterior. Además para que el proyecto culmine de forma exitosa es necesario que en las iteraciones finales los casos con error y los no validados por el cliente disminuyan, llegando a la última iteración con el 100% de los casos validados.

En esta sección se da una opinión personal referente al desarrollo y testing en XP, basado en la experiencia adquirida en el curso de ingeniería de software en el año 2003. En ese año se ponía en prácti práctica ca esta metod metodología ología de desarrollo a modo de evaluación evaluación,, la idea era ver la factibilidad de incorporar dicha metodología a las ya existentes en el curso (RUP y ModsGx). Por lo visto no resultó muy satisfactoria dicha metodología, ya que no se ha vuelto a aplicar, en un Página 16 de 19

 

Gestión de Software

Testing en eXtreme Programming

principio porque el coach  se ve sobrecargado al momento de dirigir los grupos, ya que los grupos principio saben muy poco (o nada) de la metodología y todo es nuevo para los estudiantes. Dos de los actuales integrantes de este grupo fuimos partícipes de dicha experiencia, asumiendo los roles de Analista – Desarrollador y Verificador – Desarrollador. Lo Loss gr grup upos os que que ap aplilica caron ron esta esta me meto todol dolog ogía ía esta estaba bann co comp mpue uest stos os po porr si siet etee int integ egran rante tes, s, se desarrollaba sobre GeneXus + WorkFlow utilizando para ello el generador java desarrollando para Web. Ambos grupos que aplicaron GXP (GeneXus Extreme Programming) tenáin un cliente común, 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 electrónicos como en papel para la Universidad. Dado que la metodología exige ciertos puntos básicos fue necesario introducir modificaciones, como por ejemplo incorporar un rol nuevo que libere al cliente de la escritura de historias (Analista), recorte rec orte de horas de traba trabajo jo (XP supon suponee 40 hora horass sem semana anales les – GX GXPP 15 hora horass sem semana anales) les),, el verificador verif icador asume la respon responsabili sabilidad dad de escrib escribirir las pruebas funcionales y valid validarlas arlas con el cliente, se modificó también 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 equ equipo iposs de des desarro arrollo llo enc encont ontraro raronn dificu dificultad ltades es al mom moment entoo de rea realiz lizar ar las pru pruebas ebas tan tanto to unitarias por parte de los desarrolladores como también las pruebas funcionales por parte del verificador, ya que la herramienta usada (Racional Robot) hace fuerte uso de la interfaz gráfica, la cual estaba en constante modificación, modificación, lo cual hacia perder varias horas en retrab retrabajo ajo 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” (transacción, 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 implicaría un desviamiento total sobre la metodología ya que se exige que las pruebas sean automatizadas) y dejando para probar directamente la unidad dentro de la prueba funcional. Una de las prácticas claves en XP es la programación en pares, dicha práctica se debería seguir como en XP tradicional, pero dado que los integrantes de los equipos tienen discordancia horaria es difícil conseguir pares para rotar dos veces a la semana. Como solución a este problema surge la idea de juntarnos los fines de semana y luego de la reunión 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 metodología, y es difícil conseguirlo en el contexto de la facultad.

Página 17 de 19

 

Gestión de Software

Testing en eXtreme Programming

El tester es el responsable de ayudar al cliente a seleccionar y escribir las pruebas de aceptación para cada historia de usuar usuario. io. Tiene la responsabi responsabilidad lidad de ayud ayudar ar 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 práctica de programación programación por pares puede resultar muy buena si los pares se llevan bien y son unidos, las ventajas se ven en que el código se encuentra bajo revisión continua. Se ve una mejora en la calidad del código ya que se utiliza siempre el estándar. Los casos de prueba se pueden discutir con el par al momento de implementar, lo que puede llevar a tener casos de prueba más completos. La práctica de “diseño simple” no quiere decir un mal diseño, sino el diseño ó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, proye cto, y adqui adquiere ere un conocimien conocimiento to global sobre las funcio funcionalidad nalidades es (o histo historias) rias) del mism mismo, o, ya que la continua rotación de los pares evita la aparición 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 duranteunitarias la implementación un correctas, módulo. Luego de terminada la implementación del mismo las pruebas deben ser de todas asegurando así el buen funcionamiento del módulo, es necesario que todas las pruebas sean correctas para poder integrar el módulo nuevo al sistema existente. Todas las pruebas deben ser automatizadas ya que en cada integración deben correrse todas las unitarias como funcionales y deben pasar a ser 100% correctas, de lo contrario es factible que el módulo nuevo tenga conflictos con el sistema de la etapa anterior. La automatización de las pruebas  Fomentan Fom entan el camb cambio: io: facilitan la refac refactoriza torización, ción, puesto que permiten hacer prueb pruebas as sobre los cambios y así asegurarse de que los nuevos nu evos cambios no han introducido errores. error es.  Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.  Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.  Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. En XP las pruebas de aceptación son pruebas de caja negra y debería ser responsabilidad del cliente la escritura de casos y definición de criterios para la aceptación del sistema. Las pruebas de aceptación en XP permiten verificar que las funcionalidades de cada iteración se cumplan correctamente. Se debe definir un criterio de aprobación 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.

Página 18 de 19

 

Gestión de Software

Testing en eXtreme Programming

  [BECK, [BE CK, Kent. 200 2000] 0]

Extreme Programming Programming Explaine Explained: d: Embrance Embrance Change.

Massachusetts:

 Addison-Wesley. [CRISPIN. 2001] 2001] CRISPIN Lisa. 2001. Extreme Rules of the Road. [online] [citado 12/04/2 12/04/2004]. 004]. Disponible en internet: [CRISP [CR ISPIN, IN, HOU HOUSE. SE. 20 2002 02]] CRI CRISPI SPIN, N, L.; L.; TIP HO HOUSE USE.. 2002 2002.. Testin Testing g Extreme Extreme Programming Programming. Massachusetts: Addison-Wesley. [JEFFRIES, Ron. 1999b] Extreme Testing . [online] [citado 12/04/20 12/04/2004]. 04]. Disponible en internet: [FACULTAD DE INGENIERÍA] Memoria organizacional 2003 . Disponible en internet:

Página 19 de 19