1. GESTIÓN DE PRUEBAS
EN DESARROLLO SOFTWARE
25 de octubre de 2011 – Facultade de Informática

2. Agenda
I. ¿Qué software necesita pruebas?
II.¿Qué pruebas necesita mi software?
III.¿Cómo hago pruebas a mi software?
[pausa]
Taller de pruebas software

3. I. ¿Qué software necesita
pruebas?

4. ¿Qué sabemos de las pruebas
software?
● ¿Para qué sirven?
● ¿Cómo se hacen?
● ¿Cuándo se hacen?
● ¿Quién las hace?

7. ¿Qué es un bug?
El software...
● NO hace algo que debería
● Hace algo que NO debería
● Hace algo que NO dice su especificación
● Hace algo que su especificación NO dice,
pero debería

8. ¿Qué es un bug?
El software...
● NO hace algo que debería
● Hace algo que NO debería
● Hace algo que NO dice su especificación
● Hace algo que su especificación NO dice,
pero debería
...es difícil de entender, de usar, lento.

9. ¿Qué los causa?
● Especificación
– Porque no se escribe, no se detalla,
cambia constantemente o no se propaga
● Diseño
– No se detalla suficiente, cambia y no se
comunica
● Código
– Complejidad, documentación pobre,
presión, errores tontos

10. ¿Cuánto cuestan?
● “El 50% del coste del proyecto”
● “Al menos 1/3 y probablemente más de
1/2 del coste del proyecto”
● “Al menos la mitad del coste de todas
las demás actividades del proyecto”

11. ¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación
– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas
– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente

12. ¿Cuánto cuestan?
● ¡Más cuanto más tarde se detectan!
– Cuesta 0'10 € cambiar una especificación
– Cuesta entre 1 y 10 € corregir un error
durante el desarrollo o las pruebas
– Cuesta desde 100 € subsanarlo si lo
encuentra el cliente
… en el caso medio.

13. Mariner I, 1962

14. Intel Pentium FDIV, 1994

15. El rey león, 1994/95

16. Ariane 5, 1996

17. Mars Climate Orbiter, 1999

18. “Efecto 2000”

19. En el peor de los casos...

20. Therac-25, 1985/87

21. MIM-104 Patriot, 1991

22. London Ambulance Service, 2000-hoy

23. Toyota Prius, 2010

24. Definitivamente, no hacer pruebas
resulta más caro

25. Definitivamente, no hacer pruebas
resulta más caro
… y además el coste de mantenimiento
cae drásticamente
cuando se prueba

26. Definitivamente, no hacer pruebas
resulta más caro
… y además el coste de mantenimiento
cae drásticamente
cuando se prueba bien

27. ¿Para qué valen las pruebas?
● Las pruebas exitosas son las que
encuentran errores
● Las pruebas no pueden demostrar que
el software no tiene
fallos
● Las pruebas no pueden
demostrar que el
software se ajusta a su
especificación

28. ¿Para qué valen las pruebas?
● Las pruebas pueden mostrar la
presencia de errores
● Las pruebas pueden mostrar que los
intentos de hacer fallar el software con
respecto a su especificación fracasaron
● Las pruebas pueden mostrar que no se
pudo encontrar ninguna
disconformidad con respecto a la
especificación

29. ¿Para qué valen las pruebas?
● No se puede probar un programa
por completo
● No siempre se pueden arreglar todos
los errores que se encuentran
● A veces, cuantas más pruebas, menos
errores se encuentran (paradoja del
pesticida)
● Casi siempre, cuantos más errores se
encuentran, más errores hay

30. ¿Para qué vale
la gestión de pruebas?
● Debemos ser capaces de responder
claramente y con cierta confianza a:
– ¿Está el producto listo?
– ¿La cobertura de pruebas es suficiente?
● Si la respuesta es no...
debe estar claro por qué

31. ¿Para qué vale
la gestión de pruebas?
● Las pruebas deben estar bien
integradas con el ciclo de desarrollo y
vida del proyecto, sea cual sea, para
poder responder a
– Qué hay que probar
– Cuándo se empieza a probar
– Cuándo se para de probar
– Quién hace qué
– Cuáles son los resultados

32. II.¿Qué pruebas necesita mi
software?

33. Historia
● Prehistoria (<1956): depuración
– Objetivo: que el software se ejecute
● Edad Antigua (1957-1978): demostración
– Objetivo: respaldar empíricamente que el
software cumple su especificación
● Edad Media (1979-1982): destrucción
– Objetivo: forzar la aparición de errores

34. Historia
● Edad Moderna (1983-1987): evaluación
– Objetivo: detectar errores en el diseño o en
la especificación
● Edad Contemporánea (>1998): prevención
– Objetivo: prevenir errores de diseño y de
especificación
● Métodologías ágiles
● Test-driven development

35. ¿Qué sabemos de las pruebas
software?
Verificación Validación
¿Desarrollamos el ¿Desarrollamos el
software software correcto?
correctamente?

36. ¿Qué sabemos de las pruebas
software?
Verificación Validación
¿Desarrollamos el ¿Desarrollamos el
software software correcto?
correctamente?
(de acuerdo a su (de acuerdo a la
especificación) necesidad del
usuario)

37. ¿Qué sabemos de las pruebas
software?
● Niveles de prueba
– Pruebas de unidad
– Pruebas de integración
– Pruebas de sistema
– Pruebas de aceptación

38. ¿Qué sabemos de las pruebas
software?
● Técnicas de prueba
– Dinámicas vs. Estáticas vs. Simbólicas
● Requieren o no de la ejecución del
software, o lo simulan
– Caja blanca vs. Caja negra
● Necesitan o no de conocimiento sobre la
estructura interno del software
– Positivas vs. Negativas
● Buscan o no ejercitar el software en
condiciones normales de uso y
funcionamiento

39. ¿Qué sabemos de las pruebas
software?
● Técnicas de prueba:
– Funcionales
● Se ocupan de lo que el software debe hacer
● Suelen ser técnicas dinámicas de caja negra
– Estructurales
● Se ocupan de lo que el software debe hacer
● Suelen ser técnicas de caja blanca
– No funcionales
● Se ocupan de cómo el software debe hacerlo
● Suelen ser técnicas dinámicas de caja negra

40. Técnicas de prueba
● Pruebas funcionales de caja negra
– Particiones equivalentes
● Se examina el conjunto de posibles
entradas para una unidad y se divide en
rangos que, de acuerdo con la
especificación, deban recibir el mismo
tratamiento
● Para cada rango, se elige un elemento
representante, bajo la premisa de que
cualquier valor dentro de cada rango es
tan bueno para encontrar errores
como el resto

41. Técnicas de prueba
● Pruebas funcionales de caja negra
– Valores-frontera
● Complementa la técnica de particiones
equivalentes seleccionando valores de
entrada (y de salida) pertenecientes a las
fronteras entre rangos
● Las fronteras no siempre son obvias
(especialmente a la salida):
– primero/último, inicio/fin, vacío/lleno,
lento/rápido, grande/pequeño,
cercano/lejano, mínimo/máximo,
encima/debajo, corto/largo, pronto/tarde,
alto/bajo... (+/-1)

42. Técnicas de prueba
● Pruebas funcionales de caja negra
– Mapas de transiciones
● Para unidades con estado/memoria
● Fronteras en los mapas de transiciones
suelen rebelar problemas de
temporización, race conditions,...

43. Técnicas de prueba
● Pruebas funcionales de caja negra
– Árboles causa-efecto + tablas de
decisión
– Selección de datos aleatoria
● En realidad, que siga la gramática
especificada para la unidad
● Generará datos que ni probadores ni
desarrolladores se plantearían
normalmente

44. Técnicas de prueba
● Pruebas funcionales de caja negra
– Basadas en modelos y propiedades
● Aserciones, enunciados
● Máquinas de estados finitos

45. Técnicas de prueba
● Pruebas funcionales de caja blanca
– Cobertura de instrucciones
● Seleccionar casos de prueba para que se
ejecute cada sentencia en el código al
menos una vez
– Cobertura de decisiones (ramas)
● En el caso de las sentencias de decisión, la
cobertura de instrucción puede hacer que
se ejecute la toma de la decisión, pero no
todas sus posibles ramas

46. Técnicas de prueba
● Pruebas funcionales de caja blanca
– Cobertura de condiciones
● Seleccionar casos de prueba para que la
toma de una decisión sea ejercitada
explorando todas las posibilidades de
la(s) condición(es) asociada(s)
– Análisis de flujo de datos
● Búsqueda de variables sin utilizar,
referenciadas sin inicializar, sin
dereferenciar...
– Análisis de flujo de control

47. Técnicas de prueba
● Pruebas funcionales de caja blanca:
– Mutación de código
– Inserción de fallos
● Pruebas estructurales de caja blanca:
– Revisión de código

48. Técnicas de prueba
● Pruebas no funcionales de caja blanca
– Análisis del tiempo de ejecución
y el uso de recursos
● Explora la presencia de bugs
monitorizando estos dos parámetros
● Muy valioso para optimización

49. Técnicas de prueba
● Pruebas no funcionales de caja negra
– Configuración (instalación)
– Estrés (seguridad, fiabilidad)
● Qué carga aguanta el software sin fallar
● Qué avisos da antes de fallar
● Qué pasa cuando soporta alta carga largo
rato
● Cuánto tarda en recuperarse
● Qué asistencia es necesaria para la
recuperación
– Usabilidad

51. Métricas de prueba
● Métricas de proceso
– Bugs en desarrollo vs. en producción (fault
slip-through), edad media de bugs/bugs
abiertos, tiempo de respuesta a 30 días,
densidad de bugs...
● Métricas de robustez
– Tiempo medio de fallo
● Métricas de usabilidad
– Facilidad de uso (tiempo experto/tiempo
usuario), ratio de trabajo/productividad,...

52. III.¿Cómo hago pruebas al
software?

53. ¿Cómo hago pruebas al
software?
● Las pruebas deben derivarse de una
línea base (especificación)
– Determina qué es un error
● No necesita ser completa, pero debe
contener suficiente información útil
● Debe ser estable pero flexible, sus
cambios deben controlarse
– Debe interpretarse unívocamente
– Ser visible y legible para los
stakeholders

54. Tipos de errores
● Cambios y correcciones son la primera
causa de los bugs
– Porque se actualiza el código y no las
especificaciones
● Inconsistencias
● Falta de trazabilidad
● Efectos secundarios imprevistos
– Porque no se revisa o prueba suficiente

55. Tipos de errores
● Hay 3 principales motivos para cambiar el
software:
– Corregir bugs
– Añadir funcionalidades
– Adaptarse a cambios en el entorno

56. Tipos de errores
● Errores de especificación
● Errores funcionales
– Previstos pero no suficientemente
controlados
– Que deberían haberse previsto
– Que no podrían haberse previsto
● Errores no funcionales

57. ¿Por dónde empiezo a hacer
pruebas?
● Monitorización del progreso de prueba:
– ¿Cuánta cobertura necesito?
– ¿Cuántos casos de prueba necesito para
alcanzarla?
– ¿Cuántos casos de prueba tengo?
– ¿Cuántos casos de prueba he ejecutado?
– ¿Cuántos bugs he encontrado?
– ¿He encontrado tantos bugs como
esperaba?

58. ¿Cuándo paro de hacer
pruebas?
● Las funcionalidades son estables
– Ha caído el ratio de detección de errores
– Ya no aparecen bugs de cierta gravedad
– Code turmoil es satisfactorio
● Se han ejecutado todas las pruebas
– Se ha ejercitado todo el
código/funcionalidades/escenarios
– El número y severidad de los bugs
encontrados está en un nivel
satisfatorio

59. Calidad de las pruebas
● Métricas e indicios internos:
– Bugs detectados en pruebas vs.
detectados en producción
– Bugs vs. cambios
– Bugs por iteración, bugs por parche,
parches por release
● ¿Se reducen los de mayor
gravedad/prioridad respecto al total?
– Bugs abiertos vs. cerrados
– Pruebas ejecutadas/abandonadas

60. Calidad de las pruebas
● Métricas e indicios externos:
– Nuevos proyectos no avanzan porque
hay que dedicar personal a
mantenimiento
– Evolución de los retrasos en entrega
– Evolución de horas extras próximas a las
fechas de entrega
– Evolución de LOC/bug en cada release,
en cada producto

61. Gestión de las pruebas
● Para cada proyecto software, debe
definirse una estrategia de prueba
– Visión global de la tarea
– Dirección, prioridades
– Documento de estrategia:
● Situación hoy + top 10 problemas +
posibles soluciones, cómo abordarlos
– Revión cada 6 meses o cuando haya
cambios significativos en el proyecto o
el entorno

62. Gestión de las pruebas
● Para cada release, debe redactarse y
ejecutarse un plan de pruebas
– Centrado en los posibles problemas de
cada release
● Nuevas features, interacción con features
ya existentes (backwards-compatibility)...
– Documento de plan de pruebas
● Actividades necesarias para llevar a cabo
unas pruebas eficaces + herramientas y
entorno de pruebas + planificación

63. Gestión de las pruebas
● Para cada unidad, debe mantenerse un
documento de monitorización de
pruebas:
– Casos de prueba esperados y reales
– Cobertura de funcionalidades
– Prioridad de funcionalidades
– Bugs esperados y encontrados
– Bugs por funcionalidad

64. Gestión de las pruebas
● Especificación de diseño de pruebas
– Qué se prueba, técnica, entorno, criterios
de aceptación/rechazo.
● Especificación de casos de prueba
– Objetivo, especificación, entradas/salidas,
dependencias, nº de bugs esperados
● Especificación del proceso de prueba
– Release/configuración, pasos para
ejecución/medición, procedimiento en
caso de error, criterios de inicio/parada

65. Gestión de las pruebas
d criterios
Especificación de diseño de pruebas
●
a
id
Qué se prueba, técnica, entorno,
–
l
a de prueba
de aceptación/rechazo.
Especificación de C casos
e
●
– d nº de bugs esperados
Objetivo, especificación, entradas/salidas,
n
la
dependencias,
●
P
Especificación del proceso de prueba
– Release/configuración, pasos para
ejecución/medición, procedimiento en
caso de error, criterios de inicio/parada

66. “Software exhibits weak-link behaviour:
failures in even unimportant parts of the
code can have important repercussions
elsewhere”
“Bugs remain in software after testing
because testers and developers have the
same view of the way the software will be
used by users”

67. Sputnik, 1957

68. “There are things you can specify and
things you can test for, and there are
things you'd never ever think of guarding
against”.
“If you can't plan or model it, what makes
you think you can do it?”

70. Taller de pruebas software

71. El espectro de las pruebas
Casos de prueba con Generación de
generación de datos secuencias de prueba
Pruebas individuales Propiedades generales
Ejemplos concretos Especificación completa