El documento explica por qué las pruebas de software son necesarias. Menciona que los errores son comunes y pueden ser costosos, por lo que es importante revisar el trabajo de otros. También describe cómo los defectos pueden introducirse en cualquier etapa del ciclo de vida del software y cómo las pruebas ayudan a medir y mejorar la calidad al identificar fallas.

1. Introducción
¿Por qué son necesarias las pruebas de software?
25/07/2013
Marcelo Flores
Sonia Medina
Yajaira Vargas

2. ¿Por qué las pruebas de software son necesarias?
Defectos
Pruebas en el ciclo de vida del Software
Calidad
Causa del problema
Agenda

4. Software
 Sistemas
Computacionales, procedimientos y
posibles documentos y datos asociados
al funcionamiento de un sistema de
computadora.

5. Un error en un componente o en el sistema, que
causa que falle una función requerida.
Bug, bicho, error, problema, falla…
Defecto

7.  Cometemos Errores
• Algunos no son importantes
• Algunos son costosos y peligrosos
 Asumir cosas erróneas
• Puntos ciegos
• Errores repetitivos
Por qué las pruebas
de software son tan
necesarias?
Idealmente, un tercero
debe revisar nuestro
trabajo
¿Un error puede
causar problemas?
¡Considerar el
contexto!

8. ¿Qué es lo que hace un Software tester?

9. ¿Qué hace un software tester?

10. Calidad…calidad…
calidad…

11. Control de calidad y pruebas

12. ¿Errores en Software?

13. Costo: 18.5 millones de dólares
¿Errores en Software?

14. ¿Errores en Software?

15. ¿Errores en Software?
¿ ?

16. ¿Errores en Software?

18. Diferentes tipos de Testing

19. Desarrollo de aplicaciones para probar
aplicaciones
Automatización y Pruebas de
Verificación de Prototipos

22. Las Pruebas dependen del contexto
Principio

23. No todos los Sistemas Informáticos tienen el mismo
nivel de riesgo.
No todos los problemas tienen en mismo
impacto.
La pruebas depende del
contexto

24. Liste las 5 pruebas mas importantes que debería
ejecutar, para cada uno de los siguientes sistemas:
• Facebook
• El sistema de transacciones de un Banco
• El sistema de facturación de SAGUAPAC
Ordene según la importancia de cada prueba, la mas
importante debe ser la prueba 1, la menos
importante, la prueba 5.
Practica 1

25. Causas y Consecuencias
Defectos

26. Error de Usuario
Error de Diseño
Error de Implementación
Error por ambientes
Uso Malicioso
Causas de efecto

27. El sistema no hace algo que debe hacer
El sistema hace algo que no debe hacer
Algunos defectos latentes pueden no causar fallas.
Causas de defectos

28. Definición de
Requerimientos
Diseño
Implementación
¿cuando se introduce el defectos?

29. Costo de los defectos

30. Clasifique los Errores presentados en el
documentos de la Práctica 2…
Practica 2

31. Identifique posibles defectos de diseño, de
implementación, y de definición de
requerimientos, para alguno de los siguientes
sistemas:
Sistema de un Cajero Automático
Pagina de compras online TUMOMO.com
Ventas online de tickets para Cine Center
El sistema de notificación de vuelos de SABSA
Practica 3

32.  Pruebas

33. Se puede introducir defectos en todo
el Ciclo.
Pruebas Intensas durante el desarrollo
y mantenimiento buscando defectos
Pruebas en el ciclo de vida
del software

34. La ejecución de pruebas, mejora la calidad del
sistema, al identificar/reducir fallas.
Se utilizan distintos métodos y pruebas:
Pruebas por el autor
Auditorias/pruebas por terceros
Requerimientos Contractuales/legales
Estándares de la industria
Pruebas en el ciclo de vida
del software

35. Pruebas y Calidad

36. Las pruebas ayudan a medir la calidad del software, en
términos de:
Defectos encontrados
Pruebas ejecutadas
Cobertura
Pruebas

37. Las pruebas se deben enfocar
en:
Requerimientos
funcionales
Requerimientos no
funcionales
Pruebas

38. Pruebas pobres, descubrirán pocos o ningún defecto.
Pruebas bien diseñadas nos ayudarán a encontrar defectos
certeza de la calidad y buen funcionamiento del sistema.
Pruebas

39. El grado en el que el sistema o componente cumple
con los requerimientos o las expectativas del cliente o
usuario final.
[IEEE 610]
Calidad

40. Considera la siguiente aplicación:
Practica 4

41. Identificar las características mas importantes de la
aplicación
Definir pruebas de aspectos funcionales y no
funcionales, que aseguren la calidad del software
Practica 4

42. Validación:
• Las especificaciones son correctas?
Verificación:
• ¿Se cumplen las especificaciones?
calidad

43. Se puede medir examinando los atributos del sistema:
Tiempo de respuesta
Tiempo entre fallas
calidad

44. Se puede medir examinando los atributos del sistema:
• Tiempo de respuesta
• Tiempo entre fallas
Calidad

45. Puede tener aspectos subjetivos:
Facilidad de uso
Calidad

46. Se basa en buenos procesos de desarrollo
y cumplimiento de requerimientos:
◦Utilizamos procesos formales
◦Utilizamos los resultados de las pruebas
Calidad

47. Considera el retorno de Inversión:
El proyecto puede tener un presupuesto limitado
Definir tiempos para no sobrepasar el presupuesto
Calidad

48. Sentimiento de confianza
◦Soporte
◦Sistema Novedoso
◦Sistema Oportuno
Calidad

49. Ejemplo

50. Encontrar la causa del
problema

51. Problema Encontrar Causa Darle una
solución
Procedimientos para aislar el problema
Encontrar la causa de un problema

52. El reparar un defecto puede revelar nuevos defectos
La reparación de un defecto no siempre es correcta
Algunos Defectos no se reparan hasta la siguiente
versión
Reparando defectos

53. Aislar la causa de un problema es importante en el
proceso de aseguramiento de calidad.
Podemos usar ese conocimiento para evitar defectos
similares.
Mejoramos nuestros procesos.
Encontrar la causa de un problema

54. Analice el Archivo Calcular.xlsx, tiene un macro que
suma valores, verifique la aplicación y si encuentra un
defecto, encuentre la causa, y descríbala.
Practica 5

55. Ejecute el Macro del archivo LimiteDatos.xlsx.
Intente añadir una columna para el número 0.
Excel el da un mensaje
¿Cuál es el problema?
¿Es un defecto?
Practica 6

56. ¿Cuántas pruebas
son
suficientes?

57. “Es imposible realizar pruebas exhaustivas a un
sistema” .
Principio

58. Inicialmente tendemos a querer probar todo
¿Es esto posible?
Consideremos:
Opciones validas
Opciones invalidas
Variedad de ambientes
Tiempos/recursos
¿ Cuantas pruebas son suficientes?

59. Necesitamos elegir las pruebas que sean
suficientes para:
Proyecto
Cliente
Sistema Informático
Considerando riesgos
¿ Cuantas pruebas son suficientes?

60. Las pruebas elegidas deben darnos información
suficiente para tomas decisiones.
¿ Cuantas pruebas son suficientes?

61. Tenemos un Web site de publicidad, debemos ejecutar las
pruebas al sitio antes de ponerlo a producción, y tenemos
2 semanas para terminar las pruebas.
Cuentan con 2 Ingenieros de Control de Calidad.
Existen 6 navegadores que pueden ser utilizados por los
potenciales clientes.
• Chrome, IE, Firefox, Opera, Safari, QTWeb
Practica 7

62. ¿Como podemos ejecutar las pruebas para terminar a
tiempo?, ¿existen riesgos que podemos
asumir?, Describa el plan y los riesgos que podemos
asumir para cumplir con la fecha límite.
Practica 7

63. ¿Preguntas?