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 SW  Proceso ágil  Personas factor decisivo  Pequeños o medianos equipos  El cliente cumple un rol fundamental  Valores  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ón  Pequeñas entregas  Metáfora  Diseño simple  Refactoring  Propiedad colectiva  Integración continua  40 horas semanales  Cliente on-site  Está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 cliente  Seleccionar y escribir la pruebas de aceptación  Definir 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 pares Que 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  Conductor  Pensando la mejor manera de cómo implementar el código.  Se preocupa por seguir los estándares.  Concentrado en la sintaxis del lenguaje.  Acompañante  Observa 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ón Generalidades 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ón Generalidades 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ón El 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ón El 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ón Criterios 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ón Definició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ón Definición de lo casos de prueba (II)  Resumen de un caso de prueba

30 / X 06 - Pruebas de aceptación Definició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ón Presentació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ón Presentació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 personal Aplicación de XP al curso de IIS   Idea de un día de desarrollo Desarrollar Las Pruebas DiseñarImplementar Requerimiento de Usuario Correr las Pruebas 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 cambios  Cliente  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.  Nuevo  Analista – 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 colectiva  Estándares de codificación  Pruebas automatizadas  Planificación de la liberación  Diseño simple  Refactorizar  Pequeñas liberaciones Las 12 prácticas en XP 

39 / X 07 – Experiencia personal  Cliente en el Lugar  Escribir requerimientos  Contestar preguntas  Realizar priorizaciones  Escribir pruebas funcionales  Problemas  Infraestructura de la Facultad, trabajamos en casa  La Organización del cliente:  No cuenta con la infraestructura  No puede escribir los requerimientos Solución: se define el rol de Analista Modificaciones 

40 / X 07 – Experiencia personal  40 horas semanales  La 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 semana  Nunca trabajar más de 20 horas dos semanas seguidas  Problemas:  La cantidad de horas definidas son pocas, y las estimaciones incorrectas  Se 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 continua  Integrar 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ón  Las máquinas se encuentran instaladas en el cliente  Se utilizan estas máquinas para las validaciones con el Cliente Modificaciones (III) 

42 / X 07 – Experiencia personal  Pruebas automatizadas  Pruebas funcionales  Pruebas unitarias  Herramienta: Junit - La unidad es una clase  En XP en IIS:  La unidad es un objeto Genexus  Las pruebas unitarias y funcionales son GUI  Herramienta: Rational Robot  El 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  Desarrolladores  Escribir pruebas para cada objeto Gx antes de desarrollarlo.  Hacer prototipos de interfaz para hacer las pruebas.  Verificadores  Los scripts grabados con robot sirven al cliente para la aceptación  Trabaja 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 continua  Aplicación de estándares de codificación  Definició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 ?