fase1

Agenda1. Fundamentos de

pruebas.

2. Pruebas a través del

ciclo de vida del

software.

3. Técnicas estáticas

4. Diseño de pruebas

técnicas.

5. Gestión de pruebas

6. Herramientas de apoyo

para las pruebas.

Porque es necesario probar?

Qué es una prueba?

Principios y Fundamentos del Proceso de pruebas

La Psicología de las pruebas

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

Modelos de desarrollo de software

Niveles y Tipos de prueba

Pruebas de mantenimiento

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

Revisiones y el proceso de pruebas

Proceso de revisión

Herramientas de análisis

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

Identificación de las condiciones de prueba y diseño de casos de prueba

Categorías de diseño de pruebas técnicas

Técnica basadas en especificación o caja-negra; en estructura o caja-blanca; en la experiencia

Eligiendo una prueba técnica

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

Organización de las pruebas

Plan de pruebas, estimaciones y estrategias

Seguimiento y control del avance de las pruebas

Manejo de la configuración

Riesgos y pruebas

Manejo de incidentes

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

Tipos de herramientas de prueba

Utilización efectiva de herramientas : Riesgos y beneficios potenciales

Introduciendo una herramienta en la organización

1. Fundamentos de

pruebas.


ciclo de vida del

software.



técnicas.



para las pruebas.

Agenda

1. Fundamentos de pruebas. Porque es necesario probar?

i. Debemos asumir que nuestro trabajo contiene errores.

ii. Algunos errores provienen de suposiciones y puntos muertos.

iii. 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.

iv. Los seres humanos cometemos errores todo el tiempo : “es lo

que mejor sabemos hacer¡”

Las pruebas son necesarias porque todos cometemos errores.

Qué es una prueba?1. Fundamentos de pruebas.

“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’.

ProcesoCiclo de actividades de

toda la vida del SW

Estático y Dinámico

Planeamiento: Preparaciòn

Evaluaciòn

Qué es una prueba?1. Fundamentos de pruebas.

“Cuando nosotros estamos probando algo, estamos comprobando si todo está bien.”

Análisis

Preliminar

Análisis

Funcional

Análisis

Técnico

Pase a

Producción

Construcción Certificación

Revisión de Documentos

Pruebas

Ratificación

Principios y Fundamentos del Proceso de pruebas

1. Fundamentos de pruebas.

P.1: La Prueba puede mostrar la presencia 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.

1. Fundamentos de pruebas. La Psicología de las pruebas

“Crear el software requiere una perspectiva diferente que probar el software.”

Creando algo estamos trabajando positivamente para resolver problemas en el diseño y para realizar un producto que cumpla con alguna necesidad.

Cuando probamos o revisamos un producto, estamos buscando defectos en el producto y por lo tanto somos críticos hacia él.

CONSTRUCCION - ROL COMPROBADOR

CERTIFICACION - ROL CRITICO

Pruebas por la persona que ha escrito el tema bajo prueba;

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;


Como reaccionarán el analista de requerimientos, el diseñador, el desarrollador, el gerente de proyectos y el cliente?Creativos Responsables: A la defensiva ypercibir como una crítica personal contrael producto y contra el autor.Gerente de Proyecto: Molestias porriesgos latentes que detengan elproyecto.Cliente: Perdida de confianza en elproducto por defectos de origen.

Puesto que la prueba puede ser vista como una actividad destructiva,necesitamos tener cuidado al informar los defectos y las fallas tanobjetivamente y tan educadamente como sea posible.


Pautas para el informe de defectos y errores:

1. 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.

2. 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:

3. 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 software2. Pruebas a través del ciclo

de vida del software.

A. Cascada:i. Tiene una cronología natural donde las tareas son ejecutadas de una manera

secuencial.

ii. Iniciamos por un estudio de viabilidad

iii. Sigue el flujo con la implementación de la aplicación en su ambiente,

iv. Diseño a través del desarrollo y Construcción

v. 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 software2. Pruebas a través del ciclo


B. 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”:i. Pruebas Unitarias: busca defectos y verifica el funcionamiento de componentes.ii. Pruebas de Integración: interfases entre componentes, en diferentes partes de

un sistema, operaciones del sistema, archivos, equipo físico.iii. Pruebas Integrales: comportamiento de todo el sistema definido como alcance

del desarrollo del proyecto. Comprobación contra los requisitos especificados.iv. Pruebas de Aceptación Funcional: pruebas respecto a necesidades de los

usuarios.

2. Pruebas a través del ciclo


a) Pruebas Unitarias También conocidos como unidad, moduloo pruebas de programación. Verifica funcionamiento del software:módulos, programas, objetos, clases, etc. Probados separadamente. Simulación de interfaces entre loscomponentes del software mediante usode “DUMMIES”. Comprueba: funcionalidad, manejo dememoria, performance, estructura,modelos.

Niveles y Tipos de prueba


de vida del software.Niveles y Tipos de prueba

b) Pruebas de Integración Componentes: Prueban las interacciones entre los componentes delsoftware. Sistema: Prueba las interacciones entre los diferentes sistemas. Prueba Bing-Bang: Todos los componentes/sistemas estén integradossimultáneamente. Todo está terminado antes de que la prueba deintegración comience. En general consume tiempo y es difícil rastrear lacausa de las fallas.


de vida del software.Niveles y Tipos de prueba

c) Pruebas Integrales Componentes: Prueban las interacciones entre los componentes delsoftware. Sistema: Prueba las interacciones entre los diferentes sistemas. Prueba Bing-Bang: Todos los componentes/sistemas estén integradossimultáneamente. Todo está terminado antes de que la prueba deintegración comience. En general consume tiempo y es difícil rastrear lacausa de las fallas.

fase1

Technology