Testing Exploratorio

Testing Exploratorio

Centro de Ensayos de Software

Beatriz Pérez

2007

TechNight: Si no te gusta la sopa… Dos platos!!!!!

La sopa y el testing


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

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

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

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?


?!un error humano Un defecto

(interno)

una falla

(externa)

puede generarque puede generar

Errores, defectos y fallas


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

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

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

Pruebas Unitarias

Pruebas de Integración

Pruebas del Sistema

Pruebas de Aceptación

Pruebas Funcionales


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

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

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)

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

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

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

Ciclo de vida del desarrollo

Planificación del Testing

Configurar el Entorno

Diseñar lasPruebas

Ejecución de las Pruebas

Seguimiento de Incidentes

Ciclo de vida del testing

Planificar el Proyecto

Capturar los Requerimientos

Desarrollar el Sistema

Diseñar el Sistema

Proceso

PlanificaciónPlanificaciónDiseño de las PruebasDiseño de las Pruebas

Configuración Configuración Evaluación y Cierre

Evaluación y Cierre

Plan de Pruebas

Actividades

Casos de Prueba

Artefactos

Inventario de Prueba

Informe Final de Pruebas

EjecuciónEjecución

Reporte de Prueba

Ciclo de Prueba

Seguimiento y Control Seguimiento y Control


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


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

Casos de

Prueba

Misión

Resultados



mente abierta porque podemosencontrar sorpresas

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

nuevas ideas de pruebas


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

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

Estilo Libre

Funcional parcial

Realizado por usuarios

Humo exploratorio

Regresión exploratorio

Basado en sesiones


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

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

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

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

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

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)

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


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

Centro de Ensayos de Software


Servicios Testing independiente

Consultoría

Capacitación


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)

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

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ó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

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 Inventario de Funcionalidades Incidentes

• Se utilizó la herramienta MantisInterfaz 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

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

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 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

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 Funcionalidades planificadas: 465 Funcionalidades probadas: 607 Incidentes: 120 Funcionalidades con incidentes: 154


Resultados Cubrimiento de funcionalidades

26%

74%

Con incidentes

Sin incidentes


Resultados

SATISFACCIÓN DEL CLIENTE!

Incidentes por gravedad

1% 16%

74%

9%

urgente

alta

normal

baja


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

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

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?


Gracias!

Beatriz Pérez

[email protected]

www.ces.com.uy

Testing Exploratorio

Documents

Transcript of Testing Exploratorio