Testing en eXtreme Programming

Universidad de la República – Facultad de Ingeniería - InCo

30 de Mayo de 2006

[ Duración aproximada de la presentación: 45 minutos ]

Grupo 6

Dayvis Malfará Diego Cukerman Fernando Cócaro Juan Pablo Cassinelli Renzo Séttimo

2 / X

Agenda

01 Breve Introducción a eXtreme Programming

02 El Rol Tester

03 Programación por Pares

04 Pruebas Unitarias

05 Herramientas para automatizar las pruebas

06 Pruebas de Aceptación

07 Experiencia Personal

08 Conclusiones

3 / X

01 – Breve Introducción a XP¿Qué es eXtreme Programming?

Metodología de desarrollo de SWProceso ágilPersonas factor decisivoPequeños o medianos equiposEl cliente cumple un rol fundamentalValores

Simplicidad, Comunicación, Retroalimentación y Coraje

4 / X

01 – Breve Introducción a XP¿Qué es eXtreme Programming?

12 Prácticas (K. Beck)El juego de la planificaciónPequeñas entregasMetáforaDiseño simpleRefactoringPropiedad colectivaIntegración continua40 horas semanalesCliente on-siteEstándares de código

5 / X

01 – Breve Introducción a XP¿Qué es eXtreme Programming?

12 Prácticas (K. Beck)Programación por pares

Programador Supervisor Periódicamente intercambiar roles

Pruebas (testing) Durante todo el proyecto Unitarias Aceptación

6 / X

02 – El Rol Tester

Ayudar al clienteSeleccionar y escribir la pruebas de aceptaciónDefinir los criterios de calidad

Requiere experiencia y entrenamiento (L.Crispin y T.House)

Tacto y destreza en la comunicación No debe escribir las pruebas unitarias

Desarrollador – Herramientas para automatizar Exponer los resultados obtenidos

Todos tengan acceso

¿Qué implica?

7 / X

Agenda

01 Breve Introducción a eXtreme Programming

02 El Rol Tester

03 Programación por Pares

04 Pruebas Unitarias

05 Herramientas para automatizar las pruebas

06 Pruebas de Aceptación

07 Experiencia Personal

08 Conclusiones

8 / X

03 – Programación por paresQue es programación por pares?

Todo el código producido en XP es realizado en parejas.

Dos personas frente a una computadora.

El “conductor” es el que maneja el teclado y el ratón.

El “acompañante” tiene como tarea observar y corregir

9 / X

03 – Programación por pares

ConductorPensando la mejor manera de cómo implementar el código. Se preocupa por seguir los estándares.Concentrado en la sintaxis del lenguaje.

AcompañanteObserva y corrige en todo momento, los errores cometidos por el

conductor. Considera soluciones alternativas para mejorar el algoritmo o

corregir baches en el mismo.Piensa nuevos casos de prueba mientras se realiza el código.

Programación por pares y testing

10 / X

03 – Programación por pares

Se testea al mismo momento que se implementa el código.

Se reduce la probabilidad de faltas y fallas en el sistema.

Se cumplen con los estándares de programación establecidos.

La constante revisión produce código y un diseño con mayor calidad.

Eliminar las dependencias de personas que conocen partes del sistema.

Programación por pares y calidad

11 / X

04 – Pruebas Unitarias

Una prueba unitaria es la verificación de un módulo (unidad de código) determinado dentro de un sistema.

Son llevadas a cabo por los programadores encargados de cada módulo.

Nos aseguran que un determinado módulo cumpla con un comportamiento esperado en forma aislada antes de ser integrado al sistema.

Introducción

12 / X

04 – Pruebas Unitarias

La interfaz de un método no es clara.

La implementación es complicada.

Para testear entradas y condiciones inusuales. Luego de realizar modificaciones en el módulo.

Cuando usarlas?

13 / X

04 – Pruebas Unitarias

Se considera una actividad fundamental para XP.

En XP los cambios realizados son integrados en lapsos de tiempo muy breve.

Brinda una visión de lo que se quiere realizar.

Demuestra que lo implementado es lo que se pensaba al principio.

Es mas sencillo y rápido programar teniendo los casos de prueba escritos.

Importancia

14 / X

04 – Pruebas Unitarias

Brindan al programador una inmediata retroalimentación de como están realizando su trabajo.

El programador puede realizar cambios de forma segura respaldado por efectivos casos de prueba.

Permite saber si una determinada funcionalidad se puede agregar al sistema existente sin alterar el funcionamiento actual del mismo.

Beneficios

15 / X

04 – Pruebas Unitarias

La ausencia de ellas provocan horas en sesiones de debugging al momento de integrar el código con el sistema existente.

Aseguran que un determinado módulo cumpla con un comportamiento esperado.

Pueden ser automatizadas utilizando herramientas como xUnit, de forma tal de poder soportar un testing continuo y mantener organizados los casos de pruebas.

Por que usarlas?

16 / X

Agenda

01 Breve Introducción a eXtreme Programming

02 El Rol Tester

03 Programación por Pares

04 Pruebas Unitarias

05 Herramientas para automatizar las pruebas

06 Pruebas de Aceptación

07 Experiencia Personal

08 Conclusiones

17 / X

05 – Herramientas para automatizar las pruebas

Framewors xUnit

Test Cases (casos de prueba) Prueba unitaria del modulo a testear.

Test Suites (suites de prueba). Agrupamiento de casos de prueba.

Permiten definir una vez y ejecutar reiteradamente

Simplifican la integración de módulos

18 / X

05 – Herramientas para automatizar las pruebas

Framewors xUnit

Acotan errores

Documentan el código.

Requieren de 100 % de los casos exitosos dar por terminada la prueba

Permiten reevaluar de forma automatiza después de cambios

Ejemplos JUnit, NUnit.

19 / X

05 – Herramientas para automatizar las pruebas

JUnit

Framework xUnit para la plataforma Java

Soporta ejecución en modo: Batch GUI Integrado con IDEs

Open Source (Desarrrollado por Kent Beck y Erich Gamma )

20 / X

05 – Herramientas para automatizar las pruebas

JUnit

Provee un conjunto de clases para que los programadores puedan crear sus caso de pruebas y ejecútalos de automáticamente.

Permite mantener separado los caso de prueba de clases testeadas, con lo cual para una clase java testeada existe otra que realiza su test (para clases importantes).

Permite La construcción de árboles de prueba

21 / X

Agenda

01 Breve Introducción a eXtreme Programming

02 El Rol Tester

03 Programación por Pares

04 Pruebas Unitarias

05 Herramientas para automatizar las pruebas

06 Pruebas de Aceptación

07 Experiencia Personal

08 Conclusiones

22 / X

06 - Pruebas de aceptación

Generalidades y Objetivos

El rol del cliente

Criterios de aprobación

Definición de los casos de prueba

Presentación de los resultados

23 / X

06 - Pruebas de aceptaciónGeneralidades y Objetivos (I)

Pruebas de caja negra

Definidas por el cliente

Asegurar que las funcionalidad del sistema cumplen con lo que se espera de ellas

Marcan el camino a seguir indicándole al equipo de desarrollo las funcionalidades más relevantes

24 / X

06 - Pruebas de aceptaciónGeneralidades y Objetivos (II)

Permiten que el cliente sepa cuando el sistema está funcionando (Jeffries-2000)

Permiten que los programadores conozcan qué es lo que resta por hacer (Jeffries-2000)

Tienen una importancia crítica para el éxito de una iteración

Deben estar prontas lo antes posible a partir del comienzo de la iteración

25 / X

06 - Pruebas de aceptaciónEl rol del cliente (I)

En XP las pruebas de aceptación son en última instancia responsabilidad del cliente

Los clientes son personas muy ocupadas y no tienen que ser expertos en calidad y testing

El tester debe reunirse con el cliente para interpretar sus ideas y escribir los casos de prueba

El cliente debe especificar criterios de estabilidad y performance para el sistema que se va a construir

26 / X

06 - Pruebas de aceptaciónEl rol del cliente (II)

Brindar los datos reales para la ejecución de las pruebas

Esto permite que las pruebas se asemejen al ambiente de producción

Según Crispin y Tip House (2002) los datos son tan importantes como las pruebas en sí mismas

Determinar las historias de usuario críticas que se tienen que implementar en cada iteración

27 / X

06 - Pruebas de aceptaciónCriterios de aprobación

Indican cuando una funcionalidad de iteración ha sido completada exitosamente

A diferencia de las pruebas unitarias no se exige un 100% de efectividad

Cuanto más alto es el % de efectividad exigido, más largo va a ser el tiempo estimado para la iteración

Incluir pruebas no críticas que si fallan se repiten a la siguiente iteración

28 / X

06 - Pruebas de aceptaciónDefinición de lo casos de prueba (I)

Los casos de prueba deben escribirse para realizar el testing desde el punto de vista del usuario

Brindar un feedback rápido y concreto de cómo se está desarrollando la iteración y el proyecto

Los casos de prueba exitosos de una iteración deben repetirse con éxito en las siguientes

Un error aunque sea en un sólo paso de un caso hace que se considere que falló el caso entero

29 / X

06 - Pruebas de aceptaciónDefinición de lo casos de prueba (II)

Resumen de un caso de prueba

30 / X

06 - Pruebas de aceptaciónDefinición de lo casos de prueba (II)

Pasos y acciones de un caso de prueba

Datos de entrada y resultados de un caso de prueba

31 / X

06 - Pruebas de aceptaciónPresentación de los resultados (I)

Es muy importante ya que no siempre se obtiene un 100% de efectividad

Sirve para que todo el equipo conozco los resultados de la iteración

Permiten evaluar el desempeño del grupo de desarrollo

La tendencia en las sucesivas iteraciones debe ser a acercarse al 100% de efectividad

32 / X

06 - Pruebas de aceptaciónPresentación de los resultados (II)

Ejemplo de presentación de los resultados (Jeffries 1999)

33 / X

Agenda

01 Breve Introducción a eXtreme Programming

02 El Rol Tester

03 Programación por Pares

04 Pruebas Unitarias

05 Herramientas para automatizar las pruebas

06 Pruebas de Aceptación

07 Experiencia Personal

08 Conclusiones

34 / X

07 – Experiencia personalAplicación de XP al curso de IIS

Idea de un día de desarrollo

Desarrollar Las Pruebas Diseñar Implementar

Requerimiento de Usuario

Correr lasPruebas

Integrar

Buscar un par

Pruebas Regresión

35 / X

07 – Experiencia personal

Grupo de 7 estudiantes Herramienta de desarrollo: GeneXus + GxFlow Herramienta para pruebas automatizadas: Rational

Robot Cliente: SECIU Proyecto: Expediente electrónico Objetivo: realizar una aplicación Web que permita el

seguimiento de expedientes, tanto electrónicos como papel para toda la universidad.

Características

36 / X

07 – Experiencia personal

Sin cambios de XP a GXP Desarrolladores – pares, unitarias, refactoring, etc.Encargado de registrar – estimaciones, visión global, etc.Entrenador (docente del curso)Consultor (grupo de pasantes) – conocimientos de GeneXus.

Con algunos cambiosCliente

Define requerimientos en las reuniones de requerimientos No escribe historias ni pruebas funcionales.

Verificador (libera de trabajo al cliente) Ayuda al cliente a definir criterios y escribe las pruebas funcionales.

NuevoAnalista – escribe las historias y las valida con el cliente

Roles

37 / X

07 – Experiencia personal

Exploración: instalaciones, entrenamiento, definición de la arquitectura, reuniones de requerimientos, etc.

Planificación: liberaciones, mejorar historias, definición de pruebas de aceptación, seguimiento del proyecto, etc.

Producción: liberación del producto, correr pruebas funcionales, etc.

Duración 15 semanas

Fases en el proyecto

38 / X

07 – Experiencia personal

Cliente en el lugar Programación por pares 40 horas semanales Integración continua Propiedad colectivaEstándares de codificaciónPruebas automatizadas Planificación de la liberaciónDiseño simpleRefactorizarPequeñas liberaciones

Las 12 prácticas en XP

39 / X

07 – Experiencia personal

Cliente en el LugarEscribir requerimientosContestar preguntasRealizar priorizacionesEscribir pruebas funcionales

ProblemasInfraestructura de la Facultad, trabajamos en casaLa Organización del cliente:

No cuenta con la infraestructuraNo puede escribir los requerimientos

Solución: se define el rol de Analista

Modificaciones

40 / X

07 – Experiencia personal

40 horas semanalesLa regla es no trabajar más de 40 horas a la semana.Nunca trabajar extra dos semanas seguidas

Para XP en IIS:La regla es trabajar 15 horas a la semanaNunca trabajar más de 20 horas dos semanas seguidas

Problemas:La cantidad de horas definidas son pocas, y las estimaciones

incorrectasSe ve la necesidad de omitir el punto dos y trabajar hasta que la

historia quede lista.

Modificaciones (II)

41 / X

07 – Experiencia personal

Integración continuaIntegrar y probar al menos una vez por día.Si no, la chance de conflictos crece y el costo de la integración crece

desmesuradamente. Para XP en IIS:

Se integra cada 3 días (2 veces por semana)Se tiene una maquina para realizar la integraciónLas máquinas se encuentran instaladas en el clienteSe utilizan estas máquinas para las validaciones con el Cliente

Modificaciones (III)

42 / X

07 – Experiencia personal

Pruebas automatizadasPruebas funcionalesPruebas unitarias

Herramienta: Junit - La unidad es una clase

En XP en IIS:La unidad es un objeto GenexusLas pruebas unitarias y funcionales son GUIHerramienta: Rational RobotEl verificador escribe las pruebas funcionales

Modificaciones (IV)

43 / X

07 – Experiencia personal

Pruebas automatizadas (reducir la tasa de defectos)Rational Robot (SQA basic)

Funcionales Unitarias

DesarrolladoresEscribir pruebas para cada objeto Gx antes de desarrollarlo.Hacer prototipos de interfaz para hacer las pruebas.

VerificadoresLos scripts grabados con robot sirven al cliente para la aceptaciónTrabaja junto con el cliente para definir los criterios de prueba

Pruebas

44 / X

07 – Experiencia personal

Los pares son dinámicos Deben definirse semanalmente como cambiaran los pares de

desarrollo, los pares deben cambiar por lo menos 2 veces por semana.

Problema: planificación. Se gana en la calidad del código desarrollado

El código está bajo revisión continuaAplicación de estándares de codificaciónDefinición de pruebas unitarias

No siempre es posible trabajar en pares

Programación en pares

45 / X

08 - Conclusiones

El tester es el responsable de ayudar al cliente El tester escribe las pruebas de aceptación La práctica de programación por pares

código se encuentra bajo revisión continua. mejora en la calidad del código se apega al estándar definido

Casos de prueba más completos El diseño simple no quiere decir un mal diseño Todo el equipo sabe estado del proyecto Todas las pruebas deben ser automatizadas Las pruebas de aceptación son pruebas de caja negra Se deben presentar los resultados de las mismas a todo el

equipo de desarrollo

46 / X

¿ Preguntas ?