Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porBlanca Eva Modificado hace 9 años
1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
29 / X 06 - Pruebas de aceptación Definición de lo casos de prueba (II) Resumen de un caso de prueba
30
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
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
32 / X 06 - Pruebas de aceptación Presentación de los resultados (II) Ejemplo de presentación de los resultados (Jeffries 1999)
33
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
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
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
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
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
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
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
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
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
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
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
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
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
46 / X ¿ Preguntas ?
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.