GESTIÓN DE PRUEBAS EN DESARROLLO SOFTWARE25 de octubre de 2011 – Facultade de Informática
Agenda I. ¿Qué software necesita pruebas?II.¿Qué pruebas necesita mi software?III.¿Cómo hago pruebas a mi software?       ...
I. ¿Qué software necesita         pruebas?
¿Qué sabemos de las pruebas         software?              ●   ¿Para qué sirven?              ●   ¿Cómo se hacen?         ...
¿Qué es un bug?El software...●   NO hace algo que debería●   Hace algo que NO debería●   Hace algo que NO dice su especifi...
¿Qué es un bug?El software...●   NO hace algo que debería●   Hace algo que NO debería●   Hace algo que NO dice su especifi...
¿Qué los causa?●   Especificación       –   Porque no se escribe, no se detalla,            cambia constantemente o no se ...
¿Cuánto cuestan?●   “El 50% del coste del proyecto”●   “Al menos 1/3 y probablemente más de    1/2 del coste del proyecto”...
¿Cuánto cuestan?●   ¡Más cuanto más tarde se detectan!       –   Cuesta 010 € cambiar una especificación       –   Cuesta ...
¿Cuánto cuestan?●   ¡Más cuanto más tarde se detectan!       –   Cuesta 010 € cambiar una especificación       –   Cuesta ...
Mariner I, 1962
Intel Pentium FDIV, 1994
El rey león, 1994/95
Ariane 5, 1996
Mars Climate Orbiter, 1999
“Efecto 2000”
En el peor de los casos...
Therac-25, 1985/87
MIM-104 Patriot, 1991
London Ambulance Service, 2000-hoy
Toyota Prius, 2010
Definitivamente, no hacer pruebas          resulta más caro
Definitivamente, no hacer pruebas            resulta más caro… y además el coste de mantenimiento         cae drásticament...
Definitivamente, no hacer pruebas            resulta más caro… y además el coste de mantenimiento         cae drásticament...
¿Para qué valen las pruebas?●   Las pruebas exitosas son las que    encuentran errores●   Las pruebas no pueden demostrar ...
¿Para qué valen las pruebas?●   Las pruebas pueden mostrar la    presencia de errores●   Las pruebas pueden mostrar que lo...
¿Para qué valen las pruebas?●   No se puede probar un programa    por completo●   No siempre se pueden arreglar todos    l...
¿Para qué vale           la gestión de pruebas?●   Debemos ser capaces de responder    claramente y con cierta confianza a...
¿Para qué vale           la gestión de pruebas?●   Las pruebas deben estar bien    integradas con el ciclo de desarrollo y...
II.¿Qué pruebas necesita mi         software?
Historia●   Prehistoria (<1956): depuración       –   Objetivo: que el software se ejecute●   Edad Antigua (1957-1978): de...
Historia●   Edad Moderna (1983-1987): evaluación       –   Objetivo: detectar errores en el diseño o en            la espe...
¿Qué sabemos de las pruebas         software?  Verificación         Validación¿Desarrollamos el   ¿Desarrollamos el     so...
¿Qué sabemos de las pruebas         software?  Verificación         Validación¿Desarrollamos el   ¿Desarrollamos el     so...
¿Qué sabemos de las pruebas             software?●   Niveles de prueba       –   Pruebas de unidad       –   Pruebas de in...
¿Qué sabemos de las pruebas             software?●   Técnicas de prueba       –   Dinámicas vs. Estáticas vs. Simbólicas  ...
¿Qué sabemos de las pruebas             software?●   Técnicas de prueba:       –   Funcionales              ●   Se ocupan ...
Técnicas de prueba●   Pruebas funcionales de caja negra       –   Particiones equivalentes              ●   Se examina el ...
Técnicas de prueba●   Pruebas funcionales de caja negra       –   Valores-frontera              ●   Complementa la técnica...
Técnicas de prueba●   Pruebas funcionales de caja negra       –   Mapas de transiciones              ●   Para unidades con...
Técnicas de prueba●   Pruebas funcionales de caja negra       –   Árboles causa-efecto + tablas de            decisión    ...
Técnicas de prueba●   Pruebas funcionales de caja negra       –   Basadas en modelos y propiedades              ●   Aserci...
Técnicas de prueba●   Pruebas funcionales de caja blanca       –   Cobertura de instrucciones              ●   Seleccionar...
Técnicas de prueba●   Pruebas funcionales de caja blanca       –   Cobertura de condiciones              ●   Seleccionar c...
Técnicas de prueba●   Pruebas funcionales de caja blanca:       –   Mutación de código       –   Inserción de fallos●   Pr...
Técnicas de prueba●   Pruebas no funcionales de caja blanca       –   Análisis del tiempo de ejecución               y el ...
Técnicas de prueba●   Pruebas no funcionales de caja negra       –   Configuración (instalación)       –   Estrés (segurid...
Métricas de prueba●   Métricas de proceso       –   Bugs en desarrollo vs. en producción (fault            slip-through), ...
III.¿Cómo hago pruebas al        software?
¿Cómo hago pruebas al            software?●   Las pruebas deben derivarse de una    línea base (especificación)       –   ...
Tipos de errores●   Cambios y correcciones son la primera    causa de los bugs       –   Porque se actualiza el código y n...
Tipos de errores●   Hay 3 principales motivos para cambiar el    software:       –   Corregir bugs       –   Añadir funcio...
Tipos de errores●   Errores de especificación●   Errores funcionales       –   Previstos pero no suficientemente          ...
¿Por dónde empiezo a hacer             pruebas?●   Monitorización del progreso de prueba:       –   ¿Cuánta cobertura nece...
¿Cuándo paro de hacer             pruebas?●   Las funcionalidades son estables       –   Ha caído el ratio de detección de...
Calidad de las pruebas●   Métricas e indicios internos:       –   Bugs detectados en pruebas vs.            detectados en ...
Calidad de las pruebas●   Métricas e indicios externos:       –   Nuevos proyectos no avanzan porque            hay que de...
Gestión de las pruebas●   Para cada proyecto software, debe    definirse una estrategia de prueba       –   Visión global ...
Gestión de las pruebas●   Para cada release, debe redactarse y    ejecutarse un plan de pruebas       –   Centrado en los ...
Gestión de las pruebas●   Para cada unidad, debe mantenerse un    documento de monitorización de    pruebas:       –   Cas...
Gestión de las pruebas●   Especificación de diseño de pruebas       –   Qué se prueba, técnica, entorno, criterios        ...
Gestión de las pruebas                                      d criterios    Especificación de diseño de pruebas●           ...
“Software exhibits weak-link behaviour: failures in even unimportant parts of the  code can have important repercussions  ...
Sputnik, 1957
“There are things you can specify and  things you can test for, and there arethings youd never ever think of guarding     ...
Taller de pruebas software
El espectro de las pruebas   Casos de prueba con   Generación de   generación de datos   secuencias de pruebaPruebas indiv...
Gestión de pruebas en desarrollo software
Gestión de pruebas en desarrollo software
Gestión de pruebas en desarrollo software
Gestión de pruebas en desarrollo software
Upcoming SlideShare
Loading in...5
×

Gestión de pruebas en desarrollo software

5,759

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,759
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
165
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Gestión de pruebas en desarrollo software

  1. 1. GESTIÓN DE PRUEBAS EN DESARROLLO SOFTWARE25 de octubre de 2011 – Facultade de Informática
  2. 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. 3. I. ¿Qué software necesita pruebas?
  4. 4. ¿Qué sabemos de las pruebas software? ● ¿Para qué sirven? ● ¿Cómo se hacen? ● ¿Cuándo se hacen? ● ¿Quién las hace?
  5. 5. ¿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
  6. 6. ¿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.
  7. 7. ¿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
  8. 8. ¿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”
  9. 9. ¿Cuánto cuestan?● ¡Más cuanto más tarde se detectan! – Cuesta 010 € 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
  10. 10. ¿Cuánto cuestan?● ¡Más cuanto más tarde se detectan! – Cuesta 010 € 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.
  11. 11. Mariner I, 1962
  12. 12. Intel Pentium FDIV, 1994
  13. 13. El rey león, 1994/95
  14. 14. Ariane 5, 1996
  15. 15. Mars Climate Orbiter, 1999
  16. 16. “Efecto 2000”
  17. 17. En el peor de los casos...
  18. 18. Therac-25, 1985/87
  19. 19. MIM-104 Patriot, 1991
  20. 20. London Ambulance Service, 2000-hoy
  21. 21. Toyota Prius, 2010
  22. 22. Definitivamente, no hacer pruebas resulta más caro
  23. 23. Definitivamente, no hacer pruebas resulta más caro… y además el coste de mantenimiento cae drásticamente cuando se prueba
  24. 24. Definitivamente, no hacer pruebas resulta más caro… y además el coste de mantenimiento cae drásticamente cuando se prueba bien
  25. 25. ¿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
  26. 26. ¿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
  27. 27. ¿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
  28. 28. ¿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é
  29. 29. ¿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
  30. 30. II.¿Qué pruebas necesita mi software?
  31. 31. 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
  32. 32. 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
  33. 33. ¿Qué sabemos de las pruebas software? Verificación Validación¿Desarrollamos el ¿Desarrollamos el software software correcto? correctamente?
  34. 34. ¿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 laespecificación) necesidad del usuario)
  35. 35. ¿Qué sabemos de las pruebas software?● Niveles de prueba – Pruebas de unidad – Pruebas de integración – Pruebas de sistema – Pruebas de aceptación
  36. 36. ¿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
  37. 37. ¿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
  38. 38. 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
  39. 39. 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)
  40. 40. 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,...
  41. 41. 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
  42. 42. Técnicas de prueba● Pruebas funcionales de caja negra – Basadas en modelos y propiedades ● Aserciones, enunciados ● Máquinas de estados finitos
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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,...
  49. 49. III.¿Cómo hago pruebas al software?
  50. 50. ¿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
  51. 51. 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
  52. 52. Tipos de errores● Hay 3 principales motivos para cambiar el software: – Corregir bugs – Añadir funcionalidades – Adaptarse a cambios en el entorno
  53. 53. 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
  54. 54. ¿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?
  55. 55. ¿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
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. “Software exhibits weak-link behaviour: failures in even unimportant parts of the code can have important repercussions elsewhere” “Bugs remain in software after testingbecause testers and developers have the same view of the way the software will be used by users”
  64. 64. Sputnik, 1957
  65. 65. “There are things you can specify and things you can test for, and there arethings youd never ever think of guarding against”.“If you cant plan or model it, what makes you think you can do it?”
  66. 66. Taller de pruebas software
  67. 67. El espectro de las pruebas Casos de prueba con Generación de generación de datos secuencias de pruebaPruebas individuales Propiedades generalesEjemplos concretos Especificación completa
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×