Fase1

Agenda
Fundamentos de pruebas.
Pruebas a través del ciclo de vida del software.
Técnicas estáticas
Diseño de pruebas técnicas.
Gestión de pruebas
Herramientas de apoyo para las pruebas.

Porque es necesario probar?
Las pruebas son necesarias porque todos cometemos errores.
Debemos asumir que nuestro trabajo contiene errores.
Algunos errores provienen de suposiciones y puntos muertos.
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.
Los seres humanos cometemos errores todo el tiempo : “es lo que mejor sabemos hacer¡”

Qué es una prueba?
“Cuando nosotros estamos probando algo, estamos comprobando si todo está bien.”
Proceso que nos ayuda a encontrar defectos, proporcionar confianza e información y prevenir defectos: ‘revisar si el software es correcto’.
Ciclo de actividades de toda la vida del SW
Proceso
Estático y Dinámico
Evaluaciòn
Planeamiento: Preparaciòn

Qué es una prueba?
Proceso
Revisión de Documentos
“Cuando nosotros estamos probando algo, estamos comprobando si todo está bien.”
Pruebas
Análisis Preliminar
Análisis Funcional
Análisis Técnico
Ratificación
Construcción
Certificación
Pase a Producción

Principios y Fundamentos del Proceso de pruebas
P.1: La Prueba puede mostrar lapresencia de defectos, pero no puede probar que no hay defectos.
P. 2: Prueba exhaustiva. Probar todo es imposible, excepto para casos simples.
P. 3: Prueba temprana. Las actividades de prueba deben comenzar tan pronto como sea posible.
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.
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.
P. 6: El contexto de Pruebas. La prueba se realiza de manera diferente en diferentes contextos dependientes.
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.

La Psicología de las pruebas
“Crear el software requiere una perspectiva diferente que probar el software.”
CONSTRUCCION - ROL COMPROBADOR
Creando algo estamos trabajando positivamente para resolver problemas en el diseño y para realizar un producto que cumpla con alguna necesidad.
CERTIFICACION - ROL CRITICO
Cuando probamos o revisamos un producto, estamos buscando defectos en el producto y por lo tanto somos críticos hacia él.

Pruebas por la persona que ha escrito el tema bajo prueba;
Como reaccionarán el analista de requerimientos, el diseñador, el desarrollador, el gerente de proyectos y el cliente?
Creativos Responsables: A la defensiva y percibir como una crítica personal contra el producto y contra el autor.
Gerente de Proyecto: Molestias por riesgos latentes que detengan el proyecto.
Cliente: Perdida de confianza en el producto por defectos de origen.
Pruebas por otras personas dentro del mismo equipo, como otro programador;
Pruebas por otra persona de un grupo diferente de la organización, un independiente;
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.

Pautas para el informe de defectos y errores:
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.
- No lo disfrute: Nosotros tampoco somos perfectos.
- Cualquier error probablemente se debe al grupo más que a una sola persona.
- Sea críticamente constructivo.
Explicar que al saber de un defecto, pueden trabajar en él o repararlo de manera que el sistema entregado sea mejor para el cliente.
- Explicar que les gusta y que funciona (del proyecto), así como lo que no funciona.
- Asignar prioridades a cada defecto.
- Reconozca méritos así como críticas.
- Muestre los riesgos descubiertos y los beneficios de la revisión o prueba.

Pautas para el informe de defectos y errores:
Comience con una colaboración en vez que con una batalla.
- Sea educado y servicial, colabore con sus colegas.
- Trate de ser empático: porque reacciona como lo hace?.
- Confirme el entendimiento por cuenta de cuenta de la contraparte.
- Explicar las ventajas que la prueba o la revisión branda al autor.
- Ofrezca que también su trabajo sea revisado.

Modelos de desarrollo de software
Cascada:
Tiene una cronología natural donde las tareas son ejecutadas de una manera secuencial.
Iniciamos por un estudio de viabilidad
Sigue el flujo con la implementación de la aplicación en su ambiente,
Diseño a través del desarrollo y Construcción
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.

Modelos de desarrollo de software
Método en “V”
Producción de desarrolladores y los analistas de negocios, son base de las pruebas en uno o mas niveles.
Actividades de pruebas (verificación y validación) son integradas en cada fase del ciclo de vida.
Niveles de Modelo “V”:
Pruebas Unitarias: busca defectos y verifica el funcionamiento de componentes.
Pruebas de Integración: interfases entre componentes, en diferentes partes de un sistema, operaciones del sistema, archivos, equipo físico.
Pruebas Integrales: comportamiento de todo el sistema definido como alcance del desarrollo del proyecto. Comprobación contra los requisitos especificados.
Pruebas de Aceptación Funcional: pruebas respecto a necesidades de los usuarios.

Niveles y Tipos de prueba
Pruebas Unitarias

También conocidos como unidad, modulo o pruebas de programación.
Verifica funcionamiento del software: módulos, programas, objetos, clases, etc.
Probados separadamente.
Simulación de interfaces entre los componentes del software mediante uso de “DUMMIES”.
Comprueba: funcionalidad, manejo de memoria, performance, estructura, modelos.

Pruebas de Integración

Componentes: Prueban las interacciones entre los componentes del software.
Sistema: Prueba las interacciones entre los diferentes sistemas.
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.

Pruebas Integrales

Componentes: Prueban las interacciones entre los componentes del software.
Sistema: Prueba las interacciones entre los diferentes sistemas.
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.