Pruebas a través del ciclo de vida

1. Es el mas utilizado
2. Desarrollo y pruebas son 2 ramas iguales
3. Las actividades del proceso de pruebas tienen lugar a los largo del ciclo de vida del software
4. Rama de desarrollo
   1. Definicion de requisitos
   2. Diseño funcional del sistema
   3. Diseño técnico del sistema
   4. Especificación de los componentes
   5. Programación
5. Rama de pruebas
   1. Pruebas de componente
   2. Pruebas de integración
   3. Pruebas de sistema
   4. Pruebas de aceptación
6. Verificación: (Desarrollo) Comprobación de la conformidad con los requisitos establecidos ISO 9000
7. Validación (Pruebas): Comprobación de la idoneidad para el uso esperado ISO 9000, Comprobar si los requisitos y definiciones han sido implementados correctamente

1. Extensión del modelo en V
2. Ciertas actividades del aseguramiento de la calidad se desarrollan en paralelo con el proceso de desarrollo
3. Desarrollo: Planificar. Pruebas Depuración y corrección de errores

1. Las actividades de requisitos diseño, desarrollo y pruebas se segmentan en pasos reducidos y se ejecutan en forma continua
2. Se debe alcanzar el consentimiento con el cliente tras cada iteración
3. Modelo prototipado: Desarrollo rapido de una representación del sistema
4. Desarrollo rapido de aplicaciones: Se implementa utilizando una funcionalidad previamente construida simulando la funcionalidad que sera desarrollada
5. RUP: De IBM, Modelo orientado a objetos, lenguaje de modelado UML
6. Programación extrema (XP): El desarrollo y las pruebas tiene lugar sin una especificación de requisitos formal
7. SCRUM: Se entrega un producto en corto tiempo que sea funcional
8. Caracteristicas
   1. Cada iteración contribuye con una característica adicional
   2. Cada iteración puede ser probada por separado
   3. Las pruebas de regresión y automatización son de gran relevancia
   4. La verificación y validación se pueden realizar por separadop

1. Cada actividad debe ser probada
2. Cada nivel de pruebas debería ser probado de forma especifica
3. El proceso de pruebas comienza mucho antes de la ejecución de las pruebas

1. Pruebas de modulo, de clase y de unidad
2. Son denominadas pruebas de desarrollador
3. Bases de pruebas: Requisitos de componente, diseño detallado, código
4. Objetos de prueba: Componentes, clases, unidades, módulos, conversión de datos, migración de programas
5. Alcance: Solo se prueban componentes individuales, cada componente es probado de forma independiente
6. Los casos de prueba podrán ser obtenidos a partir de especificaciones de componentes, diseño de software y modelo de datos
7. Se realizan pruebas funcionales y no funcionales de un sistema
8. Arnés de pruebas:
   1. DRIVER: Simulan datos de entrada, utilizan herramientas de programación
   2. STUB: Reemplaza o simula un componente que aun no se encuentra disponible
9. Uso de depuradores, debuggers, marcos de prueba unitaria, se necesita conocimiento de código fuente

1. Comprueban funciones externas tras las pruebas de componente
2. Comprueban la interacción entre elemento de software, entre distintos sistemas
3. La integración de subsistemas también es parte del proceso de integración
4. Pueden ser ejecutados por desarrolladores y probadores
5. Alcance: Asume que los componentes ya han sido probados, comprueba la interacción mutua entre componentes, comprueba las interfaces com el entorno del sistema, los controladores de pruebas pueden ser reutilizados en estas pruebas, se usan herramientas de control ára apoyar las actividades de prueba
6. Los casos de pruebas pueden ser obtenidos por: Especificación de interfaces, diseño de la arquitectura, modelo de datos
7. Enfoque: Detectar defectos en las interfaces, comprueban la correcta interacción entre componentes, al reemplazar arneses por componentes reales se pueden generar nuevos defectos
8. Estrategias:
   1. Ascendente
   2. Descendente
   3. Big - Bang
   4. Integración ad-hoc: Los componentes serán probados inmediatamente despues de haber sido finalizada su construcción y se hayan finalizado las pruebas de componente, es una estrategia que puede ser usada en cualquier etapa del proyecto y normalmente se aplica combinada con otras

1. Bases de pruebas: Especificación de requisitos de software (Casos de uso, especificación funcional, informe de análisis de riesgo, manuales de sistema, configuración del sistema)
2. Lo que el usuario pidio es lo que se esta entregando
3. El alcance esta definido en el plan maestro
4. La calidad de software es observada desde el punto de vista del usuario
5. Requisitos funcionales y no funcionales (ISO 9126)
6. Los casos de pruebas pueden ser obtenidos a partir de: Especificaciones funcionales, casos de uso, procesos de negocio y evaluación de riesgos
7. Alcance: Integrado desde el punto de vista del usuario, debe coincidir con el entorno real, NO SE REALIZAN PRUEBAS EN ENTORNO REAL
8. Requisitos funcionales: Comprobar que la funcionalidad implementada presenta las caracteristicas requeridas (Adecuación, Exactitud, Interoperabilidad, Cumplimiento de funcionalidad, seguridad)
9. Requisitos funcionales: Pruebas basadas en procesos de negocio, en casos de uso y en requisitos (construcción de bloques)
10. Requisitos no funcionales: La conformidad con requisitos no funcionales es dificil de lograr
11. Requisitos no funcionales con respecto a usabilidad, eficiencia y portabilidad

1. Bases de prueba: Requisitos de usuario, requisitos de sistema, casos de uso, procesos de negocio, análisis de riesgos
2. Objetos de pruebas: Procesos de negocio en sistemas completamente integrados, procesos de operaciones y mantenimiento, formularios y informes
3. Aceptación contractual, aceptación de regulación
4. Normalmente el cliente selecciona algunos casos de prueba
5. Las pruebas se realizan usando el entorno del cliente
6. Aceptación operativa: Requiere que el software sea adecuado para su uso en produccion, son realizadas por el administrador del sistema del cliente, la infraestructura soporta la aplicación que voy a instalar
7. Pruebas alpha y beta: es necesaria versión preliminar y estable del software, pruebas realizadas en productos comerciales, reducen el costo de las pruebas de aceptación, se utilizan distintos entornos, involucran alto número de usuarios
8. alpha: se realizan en las dependencias del desarrollador, beta: dependencias del cliente

1. Objetivo: Probar la función, haga lo que tenga que hacer, que los resultados obtenidos sean iguales a los esperados
2. Se pueden llevar a cabo en todos los niveles de prueba

Anmerkungen:

• Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

1. Objetivo: De que forma se llevan a cabo las funciones del software
2. A menudo las caracteristicas no funcionales son vagas, incompletas o inexistentes
3. Se pueden llevar a cabo en todos los niveles
4. Algunos ejemplos: de carga, rendimiento, estres, volumen,robustez, usabilidad, caracteristicas de seguridad (safety)

1. Objetivo: Cobertura, análisis de la estructura de un objeto de prueba (enfoque de caja blanca), la finalidad es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba
2. Nivel de componente e integración

1. Objetivo: Probar el objeto despues de los cambios
2. Las pruebas deben ser repetidas (retest), y las pruebas de áreas adyacentes (regresión)
3. Pueden ser realizadas en todos los niveles de pruebas
4. Un alto grado de modularidad permite unas pruebas de regresión reducidas mas apropiadas
5. Selección de casos de prueba de regresión: Casos de prioridad alta, probar la funcionalidad estandar, saltarse casos y variaciones especiales, probar la configuración utilizada con mayor frecuencia, probar subsistemas o zonas seleccionadas del objeto de pruebva