Testing exploratorio
This presentation is the property of its rightful owner.
Sponsored Links
1 / 54

Testing Exploratorio PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

Testing Exploratorio. Centro de Ensayos de Software Beatriz Pérez 2007. La sopa y el testing. Historia de las Pruebas. La primera referencia aparece en 1950 Recién en 1957 fue distinguida del debugging

Download Presentation

Testing Exploratorio

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Testing exploratorio

Testing Exploratorio

Centro de Ensayos de Software

Beatriz Pérez

2007


La sopa y el testing

La sopa y el testing


Historia de las pruebas

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


Enfoques din micos y est ticos

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


Definiciones

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.


Verificaci n vs validaci n

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?


Errores defectos y fallas

Errores, defectos y fallas

?!

que puede generar

puede generar

Un defecto

(interno)

una falla

(externa)

un error humano


No es posible probar completamente un programa

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.


Selecci n de los casos de prueba

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


Actitud frente a las pruebas

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


Las pruebas en el tiempo

Las pruebas en el tiempo

Pruebas

Unitarias

Pruebas

de Integración

Pruebas

Funcionales

Pruebas

del Sistema

Pruebas

de Aceptación


Prueba funcional

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


Pruebas de regresi n

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


Prueba de aceptaci n

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


Prueba de aceptaci n ii

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


Psicolog a de las pruebas

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


Niveles de independencia

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)


Desarrollo y testing

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


Proceso

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


Estrategias de testing funcional

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


Testing exploratorio1

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


Sesi n de testing exploratorio

Sesión de testing exploratorio

Misión

Resultados

Casos de Prueba


Testing exploratorio2

Testing Exploratorio

nuevas ideas

de pruebas

porque podemos

encontrar sorpresas

mente abierta

Periódicamente hay que reubicarse respecto a la misión!


Sesiones

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


Estrategia de aplicaci n

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


Estilos de testing exploratorio

Estilos de testing exploratorio

  • Estilo Libre

  • Funcional parcial

  • Realizado por usuarios

  • Humo exploratorio

  • Regresión exploratorio

  • Basado en sesiones


Estilo libre

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.


Funcional parcial

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


Realizado por usuarios

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


Humo exploratorio

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


Regresi n exploratorio

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


Basado en sesiones

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


Basado en sesiones ii

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.


Testing exploratorio en la pr ctica

Testing exploratorio en la práctica


Centro de ensayos de software

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


Servicios

Servicios

  • Testing independiente

  • Consultoría

  • Capacitación


Producto a probar

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


Producto a probar ii

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


Planificaci n

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


Planificaci n1

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


Estrategia

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.


Seguimiento

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


Cubrimiento de funcionalidades

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.


Sesiones individuales

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.


Sesiones individuales1

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


Registro de las sesiones

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


Resultados

Resultados

Funcionalidades planificadas: 465

Funcionalidades probadas: 607

Incidentes: 120

Funcionalidades con incidentes: 154


Resultados1

Resultados


Resultados2

Resultados

  • SATISFACCIÓN DEL CLIENTE!


Resultados obtenidos

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


Aspectos a mejorar

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


Aspectos a destacar

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


Preguntas

¿Preguntas?


Gracias

Gracias!

Beatriz Pérez

[email protected]

www.ces.com.uy


  • Login