Practico

181 views
156 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
181
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Practico

  1. 1. Introducción ¿Por qué son necesarias las pruebas de software? 25/07/2013 Marcelo Flores Sonia Medina Yajaira Vargas
  2. 2. ¿Por qué las pruebas de software son necesarias? Defectos Pruebas en el ciclo de vida del Software Calidad Causa del problema Agenda
  3. 3. Software  Sistemas Computacionales, procedimientos y posibles documentos y datos asociados al funcionamiento de un sistema de computadora.
  4. 4. Un error en un componente o en el sistema, que causa que falle una función requerida. Bug, bicho, error, problema, falla… Defecto
  5. 5.  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!
  6. 6. ¿Qué es lo que hace un Software tester?
  7. 7. ¿Qué hace un software tester?
  8. 8. Calidad…calidad… calidad…
  9. 9. Control de calidad y pruebas
  10. 10. ¿Errores en Software?
  11. 11. Costo: 18.5 millones de dólares ¿Errores en Software?
  12. 12. ¿Errores en Software?
  13. 13. ¿Errores en Software? ¿ ?
  14. 14. ¿Errores en Software?
  15. 15. Diferentes tipos de Testing
  16. 16. Desarrollo de aplicaciones para probar aplicaciones Automatización y Pruebas de Verificación de Prototipos
  17. 17. Las Pruebas dependen del contexto Principio
  18. 18. 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
  19. 19. 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
  20. 20. Causas y Consecuencias Defectos
  21. 21. Error de Usuario Error de Diseño Error de Implementación Error por ambientes Uso Malicioso Causas de efecto
  22. 22. 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
  23. 23. Definición de Requerimientos Diseño Implementación ¿cuando se introduce el defectos?
  24. 24. Costo de los defectos
  25. 25. Clasifique los Errores presentados en el documentos de la Práctica 2… Practica 2
  26. 26. 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
  27. 27.  Pruebas
  28. 28. 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
  29. 29. 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
  30. 30. Pruebas y Calidad
  31. 31. Las pruebas ayudan a medir la calidad del software, en términos de: Defectos encontrados Pruebas ejecutadas Cobertura Pruebas
  32. 32. Las pruebas se deben enfocar en: Requerimientos funcionales Requerimientos no funcionales Pruebas
  33. 33. 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
  34. 34. El grado en el que el sistema o componente cumple con los requerimientos o las expectativas del cliente o usuario final. [IEEE 610] Calidad
  35. 35. Considera la siguiente aplicación: Practica 4
  36. 36. 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
  37. 37. Validación: • Las especificaciones son correctas? Verificación: • ¿Se cumplen las especificaciones? calidad
  38. 38. Se puede medir examinando los atributos del sistema: Tiempo de respuesta Tiempo entre fallas calidad
  39. 39. Se puede medir examinando los atributos del sistema: • Tiempo de respuesta • Tiempo entre fallas Calidad
  40. 40. Puede tener aspectos subjetivos: Facilidad de uso Calidad
  41. 41. Se basa en buenos procesos de desarrollo y cumplimiento de requerimientos: ◦Utilizamos procesos formales ◦Utilizamos los resultados de las pruebas Calidad
  42. 42. Considera el retorno de Inversión: El proyecto puede tener un presupuesto limitado Definir tiempos para no sobrepasar el presupuesto Calidad
  43. 43. Sentimiento de confianza ◦Soporte ◦Sistema Novedoso ◦Sistema Oportuno Calidad
  44. 44. Ejemplo
  45. 45. Encontrar la causa del problema
  46. 46. Problema Encontrar Causa Darle una solución Procedimientos para aislar el problema Encontrar la causa de un problema
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. ¿Cuántas pruebas son suficientes?
  52. 52. “Es imposible realizar pruebas exhaustivas a un sistema” . Principio
  53. 53. Inicialmente tendemos a querer probar todo ¿Es esto posible? Consideremos: Opciones validas Opciones invalidas Variedad de ambientes Tiempos/recursos ¿ Cuantas pruebas son suficientes?
  54. 54. Necesitamos elegir las pruebas que sean suficientes para: Proyecto Cliente Sistema Informático Considerando riesgos ¿ Cuantas pruebas son suficientes?
  55. 55. Las pruebas elegidas deben darnos información suficiente para tomas decisiones. ¿ Cuantas pruebas son suficientes?
  56. 56. 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
  57. 57. ¿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
  58. 58. ¿Preguntas?

×