Fase1

856 views
805 views

Published on

Published in: Technology, Business
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

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

No notes for slide

Fase1

  1. 1. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  2. 2. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  3. 3. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  4. 4. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  5. 5. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  6. 6. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  7. 7. Agenda<br />Fundamentos de pruebas.<br />Pruebas a través del ciclo de vida del software.<br />Técnicas estáticas<br />Diseño de pruebas técnicas.<br />Gestión de pruebas<br />Herramientas de apoyo para las pruebas.<br />
  8. 8. Porque es necesario probar?<br />Fundamentos de pruebas.<br />Las pruebas son necesarias porque todos cometemos errores.<br />Debemos asumir que nuestro trabajo contiene errores.<br />Algunos errores provienen de suposiciones y puntos muertos. <br />Necesitamos saber si un error particular es probable que cause problemas. Algunos de estos errores no tienen importancia pero alguno de ellos son costosos y peligrosos.<br />Los seres humanos cometemos errores todo el tiempo : “es lo que mejor sabemos hacer¡”<br />
  9. 9. Qué es una prueba?<br />Fundamentos de pruebas.<br />“Cuando nosotros estamos probando algo, estamos comprobando si todo está bien.”<br />Proceso que nos ayuda a encontrar defectos, proporcionar confianza e información y prevenir defectos: ‘revisar si el software es correcto’.<br />Ciclo de actividades de toda la vida del SW<br />Proceso<br />Estático y Dinámico<br />Evaluaciòn<br />Planeamiento: Preparaciòn<br />
  10. 10. Qué es una prueba?<br />Proceso<br />Revisión de Documentos<br />Fundamentos de pruebas.<br />“Cuando nosotros estamos probando algo, estamos comprobando si todo está bien.”<br />Pruebas<br />Análisis Preliminar<br />Análisis Funcional<br />Análisis Técnico<br />Ratificación<br />Construcción<br />Certificación<br />Pase a Producción<br />
  11. 11. Principios y Fundamentos del Proceso de pruebas<br />Fundamentos de pruebas.<br />P.1: La Prueba puede mostrar lapresencia de defectos, pero no puede probar que no hay defectos.<br />P. 2: Prueba exhaustiva. Probar todo es imposible, excepto para casos simples. <br />P. 3: Prueba temprana. Las actividades de prueba deben comenzar tan pronto como sea posible.<br />P. 4: Aglomeración de defectos. Una pequeña cantidad de módulos contiene la mayoría de los defectos descubiertos durante la prueba antes del lanzamiento.<br />P. 5: La Paradoja del Pesticida. Si se repiten las mismas pruebas una y otra vez, el mismo conjunto de casos de prueba ya no encontrará ningún defecto nuevo. <br />P. 6: El contexto de Pruebas. La prueba se realiza de manera diferente en diferentes contextos dependientes.<br />P. 7: Ausencia de errores. Encontrar y resolver defectos no es útil si el sistema creado no es utilizable y no cumple las necesidades y las expectativas del cliente.<br />
  12. 12. Fundamentos de pruebas.<br />La Psicología de las pruebas<br />“Crear el software requiere una perspectiva diferente que probar el software.”<br />CONSTRUCCION - ROL COMPROBADOR<br />Creando algo estamos trabajando positivamente para resolver problemas en el diseño y para realizar un producto que cumpla con alguna necesidad. <br />CERTIFICACION - ROL CRITICO<br />Cuando probamos o revisamos un producto, estamos buscando defectos en el producto y por lo tanto somos críticos hacia él.<br />
  13. 13. Fundamentos de pruebas.<br />La Psicología de las pruebas<br />Pruebas por la persona que ha escrito el tema bajo prueba;<br />Como reaccionarán el analista de requerimientos, el diseñador, el desarrollador, el gerente de proyectos y el cliente?<br />Creativos Responsables: A la defensiva y percibir como una crítica personal contra el producto y contra el autor. <br />Gerente de Proyecto: Molestias por riesgos latentes que detengan el proyecto. <br />Cliente: Perdida de confianza en el producto por defectos de origen. <br />Pruebas por otras personas dentro del mismo equipo, como otro programador;<br />Pruebas por otra persona de un grupo diferente de la organización, un independiente;<br />Puesto que la prueba puede ser vista como una actividad destructiva, necesitamos tener cuidado al informar los defectos y las fallas tan objetivamente y tan educadamente como sea posible.<br />
  14. 14. Fundamentos de pruebas.<br />La Psicología de las pruebas<br />Pautas para el informe de defectos y errores:<br />Comunicar los resultados respecto al producto de una manera neutral, enfocada en los hechos sin personalizar el error. Escribir informes del incidente de manera objetiva y revisar los resultados.<br />- No lo disfrute: Nosotros tampoco somos perfectos.<br />- Cualquier error probablemente se debe al grupo más que a una sola persona.<br />- Sea críticamente constructivo.<br />Explicar que al saber de un defecto, pueden trabajar en él o repararlo de manera que el sistema entregado sea mejor para el cliente.<br />- Explicar que les gusta y que funciona (del proyecto), así como lo que no funciona.<br />- Asignar prioridades a cada defecto.<br />- Reconozca méritos así como críticas.<br />- Muestre los riesgos descubiertos y los beneficios de la revisión o prueba.<br />
  15. 15. Fundamentos de pruebas.<br />La Psicología de las pruebas<br />Pautas para el informe de defectos y errores:<br />Comience con una colaboración en vez que con una batalla. <br />- Sea educado y servicial, colabore con sus colegas. <br />- Trate de ser empático: porque reacciona como lo hace?.<br />- Confirme el entendimiento por cuenta de cuenta de la contraparte.<br />- Explicar las ventajas que la prueba o la revisión branda al autor.<br />- Ofrezca que también su trabajo sea revisado.<br />
  16. 16. Modelos de desarrollo de software<br />Pruebas a través del ciclo de vida del software.<br />Cascada:<br />Tiene una cronología natural donde las tareas son ejecutadas de una manera secuencial. <br />Iniciamos por un estudio de viabilidad <br />Sigue el flujo con la implementación de la aplicación en su ambiente, <br />Diseño a través del desarrollo y Construcción<br />Pruebas: ocurren hacia el final del ciclo de vida del proyecto con el fin de detectar defectos cerca de la fecha de implementación o puesta en marcha. <br />
  17. 17. Modelos de desarrollo de software<br />Pruebas a través del ciclo de vida del software.<br />Método en “V”<br />Producción de desarrolladores y los analistas de negocios, son base de las pruebas en uno o mas niveles.<br />Actividades de pruebas (verificación y validación) son integradas en cada fase del ciclo de vida.<br />Niveles de Modelo “V”:<br />Pruebas Unitarias: busca defectos y verifica el funcionamiento de componentes.<br />Pruebas de Integración: interfases entre componentes, en diferentes partes de un sistema, operaciones del sistema, archivos, equipo físico.<br />Pruebas Integrales: comportamiento de todo el sistema definido como alcance del desarrollo del proyecto. Comprobación contra los requisitos especificados.<br />Pruebas de Aceptación Funcional: pruebas respecto a necesidades de los usuarios.<br />
  18. 18. Niveles y Tipos de prueba<br />Pruebas a través del ciclo de vida del software.<br />Pruebas Unitarias<br /><ul><li>También conocidos como unidad, modulo o pruebas de programación.
  19. 19. Verifica funcionamiento del software: módulos, programas, objetos, clases, etc.
  20. 20. Probados separadamente.
  21. 21. Simulación de interfaces entre los componentes del software mediante uso de “DUMMIES”.
  22. 22. Comprueba: funcionalidad, manejo de memoria, performance, estructura, modelos.</li></li></ul><li>Niveles y Tipos de prueba<br />Pruebas a través del ciclo de vida del software.<br />Pruebas de Integración<br /><ul><li>Componentes: Prueban las interacciones entre los componentes del software.
  23. 23. Sistema: Prueba las interacciones entre los diferentes sistemas.
  24. 24. Prueba Bing-Bang: Todos los componentes/sistemas estén integrados simultáneamente. Todo está terminado antes de que la prueba de integración comience. En general consume tiempo y es difícil rastrear la causa de las fallas.</li></li></ul><li>Niveles y Tipos de prueba<br />Pruebas a través del ciclo de vida del software.<br />Pruebas Integrales<br /><ul><li>Componentes: Prueban las interacciones entre los componentes del software.
  25. 25. Sistema: Prueba las interacciones entre los diferentes sistemas.
  26. 26. Prueba Bing-Bang: Todos los componentes/sistemas estén integrados simultáneamente. Todo está terminado antes de que la prueba de integración comience. En general consume tiempo y es difícil rastrear la causa de las fallas.</li></li></ul><li>

×