Testing Exploratorio

1. Testing Exploratorio Centro de Ensayos de Software Beatriz Pérez 2007

2. La sopa y el testing

3. Historia de las Pruebas • La primera referencia aparece en 1950 • Recién en 1957 fue distinguida del debugging • La Prueba de Software puede ser usada para mostrar la presencia de bugs, pero nunca su ausencia (Dijkstra en 1970) • “La prueba continúa estando entre las artes oscuras del desarrollo de software” Myers

4. Enfoques dinámicos y estáticos • El enfoque dinámicos apunta a ejecutar una parte o todo el software para determinar si funciona según lo esperado. • El enfoque estático se refiere a la evaluación del software sin ejecutarlo usando mecanismos automatizados (herramientas asistidas) y manuales tales como controles de escritorio, inspecciones y revisiones

5. Definiciones • Prueba es una actividad realizada para evaluar la calidad del producto y mejorarla, identificando defectos y problemas. • La prueba de software (testing) es la verificación dinámica del comportamiento de un programa contra el comportamiento esperado, usando un conjunto finito de casos de prueba, seleccionados de manera adecuada desde el dominio infinito de ejecución.

6. Verificación vs. Validación • Boehm usa dos preguntas para clarificar la diferencia entre estos términos • Verificación • ¿Estamos elaborando correctamente el producto? • Validación • ¿Estamos elaborando el producto correcto?

7. Errores, defectos y fallas ?! que puede generar puede generar Un defecto (interno) una falla (externa) un error humano

8. No es posible probar completamente un programa • Para probar completamente un sistema se deben ejercitar todos los caminos posibles del programa a probar. • Myers mostró en 1979 un programa que contenía un loop y unos pocos if, este programa tenia 100 trillones de caminos, un tester podía probarlos todos en un billón de años.

9. Selección de los casos de prueba • El objetivo debe ser maximizar el número de los errores encontrados por un número finito de los casos de prueba • La forma en cómo se seleccionan los casos de prueba es una de las principales decisiones a tomar

10. Actitud frente a las pruebas • Proceso destructivo de encontrar errores (cuya presencia se asume) en un programa • El tester debe adoptar una actitud destructiva hacia el programa, debe querer que falle, debe esperar que falle y debe concentrarse en encontrar casos de prueba que muestren sus fallas

11. Las pruebas en el tiempo Pruebas Unitarias Pruebas de Integración Pruebas Funcionales Pruebas del Sistema Pruebas de Aceptación

12. Prueba Funcional • El objetivo de la prueba funcional es validar cuando el comportamiento observado del software probado cumple o no con sus especificaciones. • La prueba funcional toma el punto de vista del usuario

13. Pruebas de regresión • Su objetivo es verificar que no ocurrió una regresión en la calidad del producto luego de un cambio • Implican la reejecución de alguna o todas las pruebas realizadas anteriormente • Regresión de • defectos solucionados • defectos viejos • efectos secundarios

14. Prueba de Aceptación • Es la prueba previa a poner en producción el software • El objetivo es verificar que el software está listo y puede ser usado por el usuario final para realizar las funciones y tareas para las que fue construido

15. Prueba de Aceptación (II) • Pueden ser: • Informal: se identifican las funciones pero no hay casos de prueba a seguir. El usuario final determina que hacer • Formal : extensión de la prueba del sistema • Alfa: Pruebas realizadas por el usuario final en la organización de desarrollo • Beta: El usuario final es responsable de crear el ambiente, seleccionar sus datos y decidir que funciones explorar. Identifica su propio criterio de aceptación

16. Psicología de las pruebas • El autor de un programa tiende a cometer los mismos errores al probarlo • Debido a que es “SU” programa inconcientemente tiende a hacer casos de prueba que no hagan fallar al mismo • Puede llegar a comparar mal el resultado esperado con el resultado obtenido debido al deseo de que el programa pase las pruebas

17. Niveles de Independencia • Pruebas diseñadas por las personas que escribieron el software • Pruebas diseñadas por personas distintas pero del equipo de desarrollo. • Pruebas diseñadas por personas de otro grupo de la organización (área de testing) • Pruebas diseñadas por personas de otra organización (outsourcing)

18. Desarrollo y Testing Ciclo de vida del desarrollo Planificar el Proyecto Diseñar el Sistema Desarrollar el Sistema Capturar los Requerimientos Diseñar las Pruebas Configurar el Entorno Ejecución de las Pruebas Seguimiento de Incidentes Planificación del Testing Ciclo de vida del testing

19. Proceso Actividades Ciclo dePrueba Diseño de las Pruebas Configuración Planificación Evaluación y Cierre Ejecución Seguimiento y Control Artefactos Plan de Pruebas Inventario de Prueba Reporte de Prueba Informe Final de Pruebas Casos de Prueba

20. Estrategias de testing funcional Pruebas Casos de Prueba Producto • Testing planificado • Diseño de casos de prueba • Ejecución de pruebas, incluso por otro tester • Testing exploratorio • Diseño y ejecución de pruebas simultáneos

21. Testing Exploratorio El testing exploratorio es un proceso simultáneo de exploración del producto (aprendizaje), diseño y ejecución de pruebas. James Bach

22. Sesión de testing exploratorio Misión Resultados Casos de Prueba

23. Testing Exploratorio nuevas ideas de pruebas porque podemos encontrar sorpresas mente abierta Periódicamente hay que reubicarse respecto a la misión!

24. Sesiones • Misión • Describe qué se probará del producto, los tipos de incidentes que se buscan y los riesgos involucrados. • Sesión • Indica un itinerario • Se establece a partir de la misión • Registro

25. Estrategia de Aplicación • Existen estilos sin ninguna estructura y documentación • Selección de las distintas estrategias depende • necesidades de gerenciar y medir el testing exploratorio • formalizarlo en mayor o menor grado

26. Estilos de testing exploratorio • Estilo Libre • Funcional parcial • Realizado por usuarios • Humo exploratorio • Regresión exploratorio • Basado en sesiones

27. Estilo libre • Aplicable en las primeras etapas de construcción de un producto, cuando los requerimientos, especificaciones y funcionalidades son aún ambiguos e inestables • El resultado de aplicar el estilo libre consiste únicamente en el reporte de los incidentes detectados.

28. Funcional parcial • Probar funcionalidades individuales inmediatamente luego de implementadas • Validar requerimientos y concepciones reales del diseño • Permite una rápida retroalimentación a los desarrolladores en etapas tempranas del ciclo de desarrollo

29. Realizado por usuarios • Usuarios exploran adecuación a los escenarios reales de su trabajo • Tienen conocimiento del negocio, roles y responsabilidades variadas, determinan misiones específicas, no es preciso simularlas

30. Humo exploratorio • Tener una visión global y rápida sobre el nivel de calidad de una nueva versión de un producto • Útil cuando las actualizaciones se producen periódica y frecuentemente. • Se recorre la lista de funcionalidades básicas para detectar defectos o cambios en las funcionalidades. • Se recorre la lista de las correcciones para verificar que realmente se hayan realizado

31. Regresión exploratorio • Se concentra en las correcciones y mejoras desarrolladas • Se basa fuertemente en la experiencia del tester para explorar la posible introducción de nuevos defectos o el surgimiento de efectos negativos colaterales

32. Basado en Sesiones • Organiza el testing exploratorio en sesiones documentadas adecuadamente • Una sesión comprende • itinerario, que se establece a partir de la misión • heurísticas a ser usadas. • Los resultados incluyen: • notas escritas sobre los pasos seguidos • observaciones

33. Basado en Sesiones (II) • Su principal ventaja radica en que a pesar de su bajo costo relativo, permite elaborar reportes de avance, registrar el itinerario seguido, gestionar y medir el proceso. • Su desventaja es que depende fuertemente de las habilidades y preparación de los testers.

34. Testing exploratorio en la práctica

35. Centro de Ensayos de Software • Consorcio CUTI – Facultad de Ingeniería (UdelaR) • Proyecto: “Desarrollo tecnológico en sectores claves de la economía uruguaya”. URY/2003/5906. Unión Europea. Co-financia PNUD

36. Servicios • Testing independiente • Consultoría • Capacitación

37. Producto a probar • Aplicación web • Algunas funcionalidades de la aplicación habían sido probadas anteriormente por el CES • Nueva versión • nueva plataforma y manejador de base de datos • Documentación del producto: manual de usuario aún no actualizado

38. Producto a probar (II) • Un mes para hacer una prueba completa de todas las funcionalidades del producto • Al mes, el equipo de desarrollo liberaría una nueva versión con los incidentes ya corregidos. En esa segunda versión sólo se ejecutarían pruebas de regresión

39. Planificación • Equipo de 6 personas, dirigido por un líder • Existían 2 testers que conocían el producto • Diseñaron las misiones de testing exploratorio • Contestaban dudas

40. Planificación • Basada en el análisis de riesgo del producto • Inventario de Funcionalidades • A partir de los menúes de la aplicación • 520 funcionalidades • Se dejaron 55 fuera del alcance a partir del análisis de riesgo • Dos ciclos de prueba • Ciclo 1 se probarían 465 funcionalidades • Ciclo 2 se realizaría regresión de incidentes

41. Estrategia • Testing exploratorio basado en sesiones • Las misiones se definieron en base a: • los principales ciclos funcionales de la aplicación (5 misiones) • grupos de funcionalidades relacionadas (10 misiones) • Las misiones que cubrían las funcionalidades de mayor prioridad fueran asignados a más de una persona • cubrimiento más exhaustivo y rico.

42. Seguimiento Inventario de Funcionalidades Incidentes Se utilizó la herramienta Mantis Interfaz web Para cada incidente reportado se registraba: Descripción, categoría, prioridad, ciclo, módulo Comunicación fluida con el cliente Permitió cumplir con los plazos

43. Cubrimiento de Funcionalidades Se mantuvo un registro de trazabilidad de las funcionalidades ya ejercitadas. En función de los resultados obtenidos en cada jornada, se definían las misiones para las siguientes sesiones. La realimentación constante fue guiando el foco de las pruebas a lo largo del proyecto.

44. Sesiones individuales • Cada tester: • Leía la misión • Aclaraba las dudas con quien la había diseñado • Fijaba el itinerario de la sesión • Ejecutaba las pruebas • El tiempo registrado en cada sesión incluía • ejecución de las pruebas • registro en el sistema de seguimiento de los incidentes encontrados.

45. Sesiones individuales • La duración promedio de las sesiones dependió de la persona que ejecutaba la sesión • Mínimo: sesiones de 1 hora de duración en promedio • Máximo: sesiones de 3 horas de duración en promedio. • Se definieron 20 misiones y 40 sesiones

46. Registro de las sesiones • Se definió una plantilla: • Ciclo de prueba • Fecha y duración en minutos • Tester que realizó la ejecución • Misión de la sesión • Funcionalidades que fueron ejercitados al realizar la sesión • Razón por la que se ejecutó cada funcionalidad: por necesidad, por ser parte de la misión o por curiosidad • Datos de prueba • Observaciones: son aquellas cosas que llamaron la atención • Identificadores de los incidentes encontrados

47. Resultados Funcionalidades planificadas: 465 Funcionalidades probadas: 607 Incidentes: 120 Funcionalidades con incidentes: 154

48. Resultados

49. Resultados • SATISFACCIÓN DEL CLIENTE!

50. Resultados obtenidos • Satisfacción del cliente • Con cubrimiento e incidentes encontrados • Estrategia útil para obtener resultados rápidamente • Buena práctica guiar las misiones en función de los resultados que se obtenían • Informes de avance diarios permitieron dar visibilidad al cliente • Problemas para unificar la forma en que se redactan las sesiones