Centro de Ensayos de Software Beatriz Pérez 2007

Presentación del tema: "Centro de Ensayos de Software Beatriz Pérez 2007"— Transcripción de la presentación:

1 Centro de Ensayos de Software Beatriz Pérez 2007
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
?! puede generar que puede generar un error humano Un defecto (interno) una falla (externa)

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
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 Capturar los Requerimientos Diseñar el Sistema Desarrollar el Sistema Planificación del Testing Diseñar las Pruebas Configurar el Entorno Ejecución de las Pruebas Seguimiento de Incidentes Ciclo de vida del testing

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

20 Estrategias de testing funcional
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 Pruebas Producto Casos de Prueba Dos de las estrategias de testing funcional son: Testing planificado y Testing exploratorio. La estrategia de testing planificado es la mas conociada, y existen 2 instancias: Cuando se diseñan los casos de prueba y cuando los casos son ejecutados, por la misma persona o por otra diferente a quien los diseño. Al utilizar esta estrategia, existen diferentes tecnicas a aplicar para diseñar los casos de prueba. En la estrategia de testing esploratorio, el diseño y la ejecución de las pruebas son simultaneas. 20

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 Unir el “aprendizaje” con el modelo mental. El modelo mental se va refinando, enriqueciendo con el continuo aprendizaje. 21

22 Sesión de testing exploratorio
Casos de Prueba Construcción de un modelo mental del comportamiento del producto Definición de la misión del testing Diseño y ejecución de pruebas simultáneos Registro de resultados Resultados de las pruebas ejecutadas influencian las siguientes El testing exploratorio es confundido con el testing "ad hoc" . Sin embargo el testing "ad hoc" se refiere a un proceso de una busqueda improvisada de bugs. Exploratory Testing: An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply: The outcome of this test influences the design of the next test. [James Bach] Ad Hoc Testing. Testing carried out using no recognised test case design technique. Misión Resultados

23 Testing Exploratorio mente abierta porque podemos encontrar sorpresas
nuevas ideas de pruebas mente abierta porque podemos encontrar sorpresas Ejemplificar el tema de la misión desde el punto de vista de un arqueólogo,…… Marcar los desvíos del ómnibus con otro color y también en el grafo. Periódicamente hay que reubicarse respecto a la misión! 23

24 Sesiones Misión Sesió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 24

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
Ahora les vamos a mostrar una experiencia real donde el CES ofrece un servicio de testing funcional.

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/ Unión Europea. Co-financia PNUD El CES, es un consorcio creado en Junio de 2004 entre la Cámara Uruguaya de Tecnologías de la Información (CUTI) y el instituto de computación de la Universidad de la República (UdelaR). DESDE sus inicios cuenta con financiación de la unión europea. PNUD: Programa de Naciones Unidas para el Desarrollo

36 Servicios Testing independiente Consultoría Capacitación
Tres grandes areas de servicios: testing independiente consultoría: asesoría a departatamentos internos de testing de las empresas, mejora de procesos, aplicación de tecnicas, utilización de herramientas. Muchas veces del analisis de la consultoría sugen necesidades específicas de capacitación. y capacitación en testing (funcional, performance, introducción a la disciplina, uso de herramientas, testing para usuarios finales) Hemos capacitado a organismos del estado a usuarios que hacen pruebas. los tipos de servicio independiente son muy variados, por ejemplo: se puede testar todo un sistema o solo algunos módulos, se puede tercerizar todo el testing o contratar puntalmente un testing determinado. Tambien se diferencia si el testing es funcional o de plataformas o si es realizado en los laboratorios del ces en los del cliente o en laboratorios asociados 36

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 El seguimiento: Cubrimiento de funcionalidades Seguimiento de incidentes Seguimiento del proyecto

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. Para poder controlar las pruebas y conocer el cubrimiento de funcionalidades que se iba obteniendo con el testing exploratorio, se mantuvo un registro de trazabilidad de las funcionalidades ya ejercitadas. Al finalizar cada jornada de trabajo, el líder de proyecto recopilaba la información de las funcionalidades ejercitadas durante las sesiones, incluyendo los incidentes encontrados, y actualizaba el documento de trazabilidad. 43

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 Razón por la que se ejecutó cada funcionalidad (por necesidad, por ser parte de la meta o por curiosidad)

47 Resultados Funcionalidades planificadas: 465
Funcionalidades probadas: 607 Incidentes: 120 Funcionalidades con incidentes: 154 Se fue refinando el inventario

48 Resultados Se fue refinando el inventario

49 Resultados Gravedad 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

51 Aspectos a mejorar Utilización de herramientas
Para gestionar la información de cubrimiento y avance de las sesiones Para documentar las sesiones Obtener mejores mediciones Incidentes detectados por sesión Tiempo de preparación y ejecución de la sesión

52 Aspectos a destacar Testing exploratorio es esencial en el proceso de testing Mejora el testing planificado El buen testing requiere desarrollo continuo de habilidades que pueden ser aprendidas. Es importante documentar los pasos de la sesión y resultados obtenidos: elaborar reportes de avance registrar el itinerario seguido

53 ¿Preguntas?

54 Gracias! Beatriz Pérez