testing en extreme programming universidad de la república – facultad de ingeniería - inco 30 de...
TRANSCRIPT
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 ?