Testing en eXtreme Programming

1. Testing en eXtreme Programming Grupo 6 Dayvis Malfará Diego Cukerman Fernando Cócaro Juan Pablo Cassinelli Renzo Séttimo Universidad de la República – Facultad de Ingeniería - InCo [ Duración aproximada de la presentación: 45 minutos] 30 de Mayo de 2006

2. Agenda 01Breve Introducción a eXtreme Programming 02El Rol Tester 03Programación por Pares 04Pruebas Unitarias 05Herramientas para automatizar las pruebas 06Pruebas de Aceptación 07Experiencia Personal 08Conclusiones

3. 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. 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. 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. 02 – El Rol Tester ¿Qué implica? ç • 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

7. Agenda 01Breve Introducción a eXtreme Programming 02El Rol Tester 03Programación por Pares 04Pruebas Unitarias 05Herramientas para automatizar las pruebas 06Pruebas de Aceptación 07Experiencia Personal 08Conclusiones

8. 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. 03 – Programación por pares Programación por pares y testing ç • 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.

10. 03 – Programación por pares Programación por pares y calidad ç • 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.

11. 04 – Pruebas Unitarias Introducción ç • 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.

12. 04 – Pruebas Unitarias Cuando usarlas? ç • 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.

13. 04 – Pruebas Unitarias Importancia ç • 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.

14. 04 – Pruebas Unitarias Beneficios ç • 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.

15. 04 – Pruebas Unitarias Por que usarlas? ç • 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.

16. Agenda 01Breve Introducción a eXtreme Programming 02El Rol Tester 03Programación por Pares 04Pruebas Unitarias 05Herramientas para automatizar las pruebas 06Pruebas de Aceptación 07Experiencia Personal 08Conclusiones

17. 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. 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. 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. 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. Agenda 01Breve Introducción a eXtreme Programming 02El Rol Tester 03Programación por Pares 04Pruebas Unitarias 05Herramientas para automatizar las pruebas 06Pruebas de Aceptación 07Experiencia Personal 08Conclusiones

22. 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. 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. 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. 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. 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. 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. 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. 06 - Pruebas de aceptación Definición de lo casos de prueba (II) ç Resumen de un caso de prueba

30. 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. 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. 06 - Pruebas de aceptación Presentación de los resultados (II) ç Ejemplo de presentación de los resultados (Jeffries 1999)

33. Agenda 01Breve Introducción a eXtreme Programming 02El Rol Tester 03Programación por Pares 04Pruebas Unitarias 05Herramientas para automatizar las pruebas 06Pruebas de Aceptación 07Experiencia Personal 08Conclusiones

34. Aplicación de XP al curso de IIS ç Buscar un par 07 – Experiencia personal • Idea de un día de desarrollo Requerimiento de Usuario Desarrollar Las Pruebas Diseñar Implementar Correr las Pruebas Integrar Pruebas Regresión

35. Características ç 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.

36. Roles ç 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

37. Fases en el proyecto ç 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

38. Las 12 prácticas en XP ç 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

39. Modificaciones ç 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

40. Modificaciones (II) ç 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.

41. Modificaciones (III) ç 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

42. Modificaciones (IV) ç 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

43. Pruebas ç 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

44. Programación en pares ç 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

45. ç 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. ¿ Preguntas ?