Download - Gestión de pruebas en desarrollo software
![Page 1: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/1.jpg)
GESTIÓN DE PRUEBAS
EN DESARROLLO SOFTWARE
25 de octubre de 2011 – Facultade de Informática
![Page 2: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/2.jpg)
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
![Page 3: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/3.jpg)
I. ¿Qué software necesita pruebas?
![Page 4: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/4.jpg)
¿Qué sabemos de las pruebas software?
● ¿Para qué sirven?● ¿Cómo se hacen?● ¿Cuándo se hacen?● ¿Quién las hace?
![Page 5: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/5.jpg)
![Page 6: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/6.jpg)
![Page 7: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/7.jpg)
¿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
![Page 8: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/8.jpg)
¿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.
![Page 9: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/9.jpg)
¿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
![Page 10: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/10.jpg)
¿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”
![Page 11: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/11.jpg)
¿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
![Page 12: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/12.jpg)
¿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.
![Page 13: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/13.jpg)
Mariner I, 1962
![Page 14: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/14.jpg)
Intel Pentium FDIV, 1994
![Page 15: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/15.jpg)
El rey león, 1994/95
![Page 16: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/16.jpg)
Ariane 5, 1996
![Page 17: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/17.jpg)
Mars Climate Orbiter, 1999
![Page 18: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/18.jpg)
“Efecto 2000”
![Page 19: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/19.jpg)
En el peor de los casos...
![Page 20: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/20.jpg)
Therac-25, 1985/87
![Page 21: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/21.jpg)
MIM-104 Patriot, 1991
![Page 22: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/22.jpg)
London Ambulance Service, 2000-hoy
![Page 23: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/23.jpg)
Toyota Prius, 2010
![Page 24: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/24.jpg)
Definitivamente, no hacer pruebas resulta más caro
![Page 25: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/25.jpg)
Definitivamente, no hacer pruebas resulta más caro
… y además el coste de mantenimiento cae drásticamente
cuando se prueba
![Page 26: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/26.jpg)
Definitivamente, no hacer pruebas resulta más caro
… y además el coste de mantenimiento cae drásticamente
cuando se prueba bien
![Page 27: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/27.jpg)
¿Para qué valen las pruebas?
● Las pruebas exitosas son las que encuentran errores
● Las pruebas no pueden demostrar que el software no tienefallos
● Las pruebas no puedendemostrar que elsoftware se ajusta a suespecificación
![Page 28: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/28.jpg)
¿Para qué valen las pruebas?
● Las pruebas pueden mostrar lapresencia 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
![Page 29: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/29.jpg)
¿Para qué valen las pruebas?
● No se puede probar un programapor 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
![Page 30: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/30.jpg)
¿Para qué valela 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é
![Page 31: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/31.jpg)
¿Para qué valela 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
![Page 32: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/32.jpg)
II.¿Qué pruebas necesita mi software?
![Page 33: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/33.jpg)
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
![Page 34: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/34.jpg)
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
![Page 35: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/35.jpg)
¿Qué sabemos de las pruebas software?
Verificación
¿Desarrollamos el software
correctamente?
Validación
¿Desarrollamos el software correcto?
![Page 36: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/36.jpg)
¿Qué sabemos de las pruebas software?
Verificación
¿Desarrollamos el software
correctamente?
(de acuerdo a su especificación)
Validación
¿Desarrollamos el software correcto?
(de acuerdo a la necesidad del
usuario)
![Page 37: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/37.jpg)
¿Qué sabemos de las pruebas software?
● Niveles de prueba– Pruebas de unidad– Pruebas de integración– Pruebas de sistema– Pruebas de aceptación
![Page 38: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/38.jpg)
¿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
![Page 39: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/39.jpg)
¿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
![Page 40: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/40.jpg)
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 errorescomo el resto
![Page 41: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/41.jpg)
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)
![Page 42: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/42.jpg)
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,...
![Page 43: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/43.jpg)
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
![Page 44: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/44.jpg)
Técnicas de prueba
● Pruebas funcionales de caja negra– Basadas en modelos y propiedades
● Aserciones, enunciados● Máquinas de estados finitos
![Page 45: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/45.jpg)
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
![Page 46: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/46.jpg)
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
![Page 47: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/47.jpg)
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
![Page 48: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/48.jpg)
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
![Page 49: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/49.jpg)
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
![Page 50: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/50.jpg)
![Page 51: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/51.jpg)
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,...
![Page 52: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/52.jpg)
III.¿Cómo hago pruebas al software?
![Page 53: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/53.jpg)
¿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
![Page 54: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/54.jpg)
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
![Page 55: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/55.jpg)
Tipos de errores
● Hay 3 principales motivos para cambiar el software:
– Corregir bugs– Añadir funcionalidades– Adaptarse a cambios en el entorno
![Page 56: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/56.jpg)
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
![Page 57: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/57.jpg)
¿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?
![Page 58: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/58.jpg)
¿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 nivelsatisfatorio
![Page 59: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/59.jpg)
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
![Page 60: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/60.jpg)
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
![Page 61: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/61.jpg)
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
![Page 62: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/62.jpg)
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
![Page 63: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/63.jpg)
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
![Page 64: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/64.jpg)
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
![Page 65: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/65.jpg)
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
Plan de Calidad
![Page 66: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/66.jpg)
“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”
![Page 67: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/67.jpg)
Sputnik, 1957
![Page 68: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/68.jpg)
“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?”
![Page 69: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/69.jpg)
![Page 70: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/70.jpg)
Taller de pruebas software
![Page 71: Gestión de pruebas en desarrollo software](https://reader034.vdocuments.mx/reader034/viewer/2022051323/54b436444a79598e638b4628/html5/thumbnails/71.jpg)
El espectro de las pruebas
Pruebas individualesEjemplos concretos
Propiedades generalesEspecificación completa
Casos de prueba congeneración de datos
Generación desecuencias de prueba