Pruebas en el Ciclo de Vida 1 Principios2 Ciclo de Vida 4 Pruebas Tecicas Dinamicas 3 Pruebas Estaticas 5 Administracion6 Herramientas Software Testing ISTQB / ISEB Foundation Exam Practice Capitulo 2

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Prueba de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Modelo-V: niveles de prueba Pruebas de integracion En Pequeño Pruebas de integracion En Pequeño Pruebas de integracion en grande Pruebas de integracion en grande Pruebas Del Sistema Pruebas Del Sistema Pruebas de Componentes Pruebas de Componentes Pruebas de Aceptacion Pruebas de Aceptacion Codigo Especificaciones De Diseño Especificaciones De Diseño Especificaciones del Sistema Especificaciones del Proyecto Especificaciones del Proyecto Requerimientos del Negocio

Modelo-V: diseño de las pruebas finales Pruebas de integracion En Pequeño Pruebas de integracion En Pequeño Pruebas de integracion en grande Pruebas de integracion en grande Pruebas Del Sistema Pruebas Del Sistema Pruebas de Componentes Pruebas de Componentes Pruebas de Aceptacion Pruebas de Aceptacion Codigo Especificaciones De Diseño Especificaciones De Diseño Especificaciones del Sistema Especificaciones del Proyecto Especificaciones del Proyecto Requerimientos del Negocio Tests “Nosotros no tenemos tiempo para diseñar? Las primeras pruebas” Pruebas de Diseño?

Modelo-V: diseño de la prueba temprana Pruebas de integracion En Pequeño Pruebas de integracion En Pequeño Pruebas de integracion en grande Pruebas de integracion en grande Pruebas Del Sistema Pruebas Del Sistema Pruebas de Componentes Pruebas de Componentes Pruebas de Aceptacion Pruebas de Aceptacion Codigo Especificaciones De Diseño Especificaciones De Diseño Especificaciones del Sistema Especificaciones del Proyecto Especificaciones del Proyecto Requerimientos del Negocio Tests Pruebas de Diseño Pruebas de Ejecucion

Diseño de la prueba anticipada n El diseño prueba detecta fallas. n Las fallas encontradas de forma temprana son más baratos para resolver. n Los fallos más significativos se encuentran por primera vez n Prevenir fallas, noes construir n El esfuerzo adicional, en re-diseño del calendario de pruebas. n El cambio de los requerimientos causadas por el diseño de la prueba Diseño de la prueba temprana ayuda a la calidad de construcción, detiene la multiplicación de los fallos Diseño de la prueba temprana ayuda a la calidad de construcción, detiene la multiplicación de los fallos

Informe de Experiencias: Fase 1 Fase 1: Plan 2 meses devtest 150 faults 1 primer mes. 50 faults El usuario no esta contento Calidad Muchas horas extras en el desarrollo Actual "tiene que ir resolviendo" pero no funcionaba

Informe de Experiencia: Fase 2 Source: Simon Barlow & Alan Veitch, Scottish Widows, Feb 96 Phase 2: Plan 2 mo6 wks devtest 50 faults 1st mo. 0 faults happy users! Quality smooth, not much for dev to do Actual acc test: full week (vs half day) on time Phase 1: Plan 2 mo devtest 150 faults 1st mo. 50 faults users not happy Quality fraught, lots of dev overtime Actual "has to go in" but didn't work Fase 2: Plan 2 meses 6 semanas devtest 50 faults 1 primer mes. 0 faults Usuario Feliz! Calidad suave, no hay mucho para hacer desarrollo Actual acc test: toda la semana (vs medio dia) A tiempo

VV&T n Verificacion el proceso de evaluación de un sistema o componente para determinar si los productos de la fase de desarrollo dado cumple los requisitos impuestos al inicio de esa fase [BS ] el proceso de evaluación de un sistema o componente para determinar si los productos de la fase de desarrollo dado cumple los requisitos impuestos al inicio de esa fase [BS ] n n Validacion La determinación de la exactitud de los productos de desarrollo de software con respecto a las necesidades de los usuarios y los requisitos [BS ] La determinación de la exactitud de los productos de desarrollo de software con respecto a las necesidades de los usuarios y los requisitos [BS ] n n Pruebas el proceso de ejecutar software para comprobar si se cumplen los requisitos especificados y para detectar fallos el proceso de ejecutar software para comprobar si se cumplen los requisitos especificados y para detectar fallos

Verificacion, Validacion y Prueba Verificacion Validacion Prueba Cualquier elemento Cualquier elemento

modelo de ejercicio-V

El Modelo-V - Ejercicio DS FD Construir Components Construir Units TD Construir System Codigo Construir Ensamblaje VD System Test Integration Test Revise FD Revise TD TUT FUT Revise DS Revise VD Assembly Test Excepciones: Conversión de prueba FOS: DN / GLDN

¿Cómo probar esta especificación? n Un programa de computadora juega al ajedrez con un usuario. Se muestra el tablero y las piezas que aparecen en pantalla. Los movimientos se hicieron arrastrando piezas.

“La prueba es cara” n ¿Comparado con que? n Cual es el costo de no probar, o de las fallas que no se consiguieron en las pruebas? -Costo para arreglar fallos aumenta cuanto más tarde la falla se encuentra. -Software de mala calidad cuesta más usarlo. los usuarios toman más tiempo para entender lo que debe hacer. los usuarios toman más tiempo para entender lo que debe hacer. los usuarios cometen más errores en su uso los usuarios cometen más errores en su uso Sufren moralmente Sufren moralmente => productividad baja => productividad baja n ¿Sabes lo que cuesta su organización?

¿Qué fallos del software cuestan? n Alguna vez ha destruido accidentalmente un PC? -lo tiró fuera de su escritorio? -sirvió café en la unidad de disco duro? -lo dejó caer por una ventana del segundo piso? n ¿Cómo te sentirías? n ¿Cuánto le costaría?

Costo hipotético - 1 (Costo del salario cargado: Bs. 50/hr) Costo de fallo Desarrollo Usuario Bs.700 Bs.50 - detect ( 0.5 hr)Bs.25 - report ( 0.5 hr)Bs.25 - receive & process (1 hr)Bs.50 - assign & bkgnd (4 hrs)Bs depurar ( 0.5 hr)Bs.25 - test fallos fijos ( 0.5 hr)Bs.25 - Pruebas regresion(8 hrs)Bs.400

Costo hipotético - 2 Costo de falla Desarrollo Usuario Bienen Bs.700Bs.50 - actualizar doc'n, CM (2 hrs) Bs actualizar code library (1 hr) Bs.50 - inform users (1 hr) Bs.50 - admin(10% = 2 hrs) Bs.100 Total (20 hrs) Bs.1000

Costo hipotético - 3 Costo de falla Desarrollo Usuario bienen Bs.1000 Bs.50 (Se supone que sólo afecta a 5 usuarios) - work x 2, 1 semanaBs fix data (1 dia)Bs pay for fix (3 dias maint)Bs regr test & sign off (2 dias) Bs update doc'n / inform (1 day)Bs double check + 12% 5 semanasBs admin (+7.5%)Bs.800 Totals Bs.1000 Bs.12000

El costo de la fijación de las fallas ReqUseDesTest

¿Qué tan caro es para usted? n Saque sus propias cuentas -Calcule el costo de las pruebas Tiempo hombre, maquinas, herramientas Tiempo hombre, maquinas, herramientas -Calcule el costo fijo de los errores encontrados en las pruebas. -calcular el costo para arreglar los fallos pasados ​​ por alto por las pruebas n n Estime si no hay data disponible -sus cifras serán las mejores de su empresa tiene! (10 minutos)

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Prueba de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

(Antes de planear para un conjunto de pruebas) n establecer la estrategia organizativa de prueba n identificar a las personas involucradas (patrocinadores, los probadores, control de calidad, desarrollo, soporte, et al.) n analizar los requisitos o especificaciones funcionales (base de pruebas) n establecer la organización de la prueba y la infraestructura n definición de los entregables de pruebas y presentación de informes de estructura See: Structured Testing, an introduction to TMap®, Pol & van Veenendaal, 1998

Alto nivel de planificación de las pruebas n ¿Cuál es el propósito de un plan de prueba de alto nivel? -¿A quién se lo comunicará ? -¿Por qué es una buena idea tener un plan de este tipo? n ¿Qué información debe estar en un plan de prueba de alto nivel? -¿Cuál es el nivel de contenido de un plan de pruebas? -¿Alguna vez has olvidado algo importante? -Lo que no está incluido en un plan de pruebas?

Plan de Pruebas 1 n 1 Identifique el Plan de Pruebas n 2 Introduccion -elementos de software y características para ser probados -referencias a la autorización del proyecto, plan del proyecto, el plan de control de calidad, plan de CM, las políticas pertinentes y las normas n n 3 Test items -elementos de prueba, incluyendo nivel de versión / revisión -Como trasmitir (net, disc, CD, etc.) -Documentacion de las ref. de software Source: ANSI/IEEE Std , Test Do.umentation

Plan de Pruebas 2 n 4 Características a ser probadas -identificar especificación de prueba de diseño / técnicas n 5 Caracteristicas que no van hacer probadas -motivos de la exclusión

Plan de Pruebas 3 n 6 Enfoque -actividades, técnicas y herramientas -suficientemente detallada para estimar -especificar el grado de exhaustividad (cobertura, por ejemplo) y otros criterios de finalización (fallos, por ejemplo) -identificar las limitaciones (medio ambiente, el personal, los plazos) n n 7 Artículo Pasa / Falla Criterios n 8 Criterios de suspensión y reanudación -para la totalidad o partes de las actividades de prueba -qué actividades se deben repetir en la reanudación.

Plan de Pruebas 4 n 9 Entregables de Pruebas -Plan de Pruebas -Prueba de especificación de diseño -Especificacion de Casos de Prueba -Especificacion de procedimiento de Prueba -Prueba de informes Tema transmisión -Test logs -Reporte de insidencias de Prueba -Reporte de Sumario de Pruebas

Plan de Pruebas 5 n 10 Tareas de Prueba -incluyendo entre dependencias de tareas y habilidades especiales n n 11 Medio Ambiente -fisico, hardware, software, herramientas -el modo de uso, seguridad, espacio de oficina n n 12 Responsabilidades -para gestionar, diseñar, preparar, ejecutar, dar testimonio, chequeo, resolver problemas, que proporciona un entorno, proporcionando el software para probar.

Plan de Pruebas 6 n 13 Dotación de personal y las necesidades de formación n 14 Programar -hitos de prueba en horario de proyecto -artículo hitos a transmitir -hitos de prueba adicionales (medio ambiente listo) -qué recursos son necesarios y cuando n n 15 Riesgos y Contingencias -Plan de contingencias para cada riesgo identificado n 16 Aprobaciones -nombres y cuando fue aprobado

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Prueba de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Prueba de Componentes n nivel más bajo n prueba de forma aislada n mirada más a fondo en detalle -manejo de errores -interfaces n generalmente se realiza por el programador n también conocido como unidad, pruebas módulo de programa,

Estrategia de Prueba de Componentes 1 n especificarán las técnicas de diseño de pruebas y razones -de la Sección 3 de la norma * n especificar los criterios para la realización de pruebas y razón de ser -de la Sección 4 de la norma * n documentar el grado de independencia para el diseño de pruebas -Autor del componente, otra persona, de otra sección, de organización diferente, no humana *Source: BS , Software Component Testing Standard

Estrategia de Prueba de Componentes 2 n componente de integración y medio ambiente -aislamiento, de arriba abajo, de abajo arriba, o de la mezcla -hardware y software n documento de proceso de pruebas y actividades -incluidas las entradas y salidas de cada actividad n actividades afectadas se repiten después de las correcciones de fallas o cambios n El componente del proyecto del Plan de Pruebas -dependencias entre las pruebas de componentes

Jerarquia de la Documentacion de la Prueba de Componente Estrategia de prueba de Componentes Project Component Test Plan Component Test Specification Component Test Plan Component Test Report Source: BS , Software Component Testing Standard, Annex A

Proceso de prueba de Componente Checking for Component Test Completion Component Test Planning Component Test Specification Component Test Execution Component Test Recording INICIOEND

Proceso de prueba de Componente Component Test Planning Component Test Specification Component Test Execution Component Test Recording Checking for Component Test Completion BEGIN END Planificacion de la Prueba de Componentes - Cómo la estrategia de prueba y plan de proyecto de prueba aplicables a el componente bajo prueba - Las excepciones a la estrategia - Todo el software del componente va a interactuar con (por ejemplo talones y los controladores

Proceso de prueba de Componente Component Test Planning Component Test Specification Component Test Execution Component Test Recording Checking for Component Test Completion BEGIN END Pruebas de especificacion del componente - Los casos de prueba se diseñan mediante el diseño de casos de prueba técnicas especificadas en los plan de prueba (Sección 3) - Casos de Prueba: objetivo estado inicial del componente entrada resultado esperado - casos de prueba deben ser repetible

Proceso de prueba de Componente Component Test Planning Component Test Specification Component Test Execution Component Test Recording Checking for Component Test Completion BEGIN END Ejecucion de la Prueba de Componentes - cada caso de prueba se ejecuta - La norma no especifica si ejecuta manualmente o utilizando una prueba de ejecución herramienta

Proceso de prueba de Componente Component Test Planning Component Test Specification Component Test Execution Component Test Recording Checking for Component Test Completion BEGIN END Registro de la Prueba de Componentes - identidades y versiones de componente, prueba de especificación - resultado real grabada y en comparación con el resultado esperado - discrepancias registrado - repetir las actividades de prueba para establecer eliminación de la discrepancia (fix falla en la prueba o verificar) - Niveles récord de cobertura alcanzado para los criterios de terminación de prueba se especifica en el plan de pruebas Suficiente para mostrar prueba actividades llevadas a cabo

Proceso de prueba de Componente Component Test Planning Component Test Specification Component Test Execution Component Test Recording Checking for Component Test Completion BEGIN END Chequeo de la finalizacion de la Prueba de Componentes - revisar los registros de prueba contra ensayo especificado terminación criterios -si no se cumplen, repita la prueba de actividades - Puede que tenga que repetir la prueba especificaciones para el diseño de la prueba casos para cumplir finalización criterios (por ejemplo, caja blanca)

Técnicas de diseño de pruebas n “Caja Negra” -partición de equivalencia -Análisis del valor límite -Estado de pruebas transición -Causa-efecto gráfica -Sintaxis de Prueba -Pruebas aleatorias n Cómo especificar otras técnicas n “Caja Blanca” - Declaración pruebas - Branch / Decision testing - Prueba del Flujo de Datos - Branch condition testing - Branch condition combination testing - Modified condition decision testing - LCSAJ testing (Migracion) = Yes = No También una medición técnica?

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Prueba de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Las pruebas de integración? En la pequeña n más de un componente (probado) n La comunicación entre los componentes n lo que el conjunto puede realizar que no es posible individualmente n aspectos no funcionales, si es posible n estrategia de integración: big-bang vs incremental (top-down, bottom-up, funcional) n hecho por los diseñadores, analistas, o probadores independientes

Integración Big-Bang n En teoria: -si ya hemos probado los componentes ¿por qué no combinar todos ellos a la vez? ¿No sería esto ahorrar tiempo? -(basada en la suposición falsa de ningún fallo) n n En la Practica: -toma más tiempo para localizar y corregir fallos -volver a probar después de las correcciones más extensa -El resultado final? tarda más tiempo

Integración incremental n Línea de base 0: componente probado n Línea de base 1: dos componentes probados n Línea de base 2: tres componentes probados, etc. n Ventajas : -Localizar y solucionar la falla mas facil. -Hacer recuperación de desastres / problemas. -Las interfaces deben ser probados en pruebas de componentes, pero.. -Adicionando lines bases de pruebas.

n Lineas Bases: -Linea base 0: componente a -Linea base 1: a + b -Linea base 2: a + b + c -Linea base 3: a + b + c + d -etc. n Necesidad de llamar a los componentes de niveles inferiores no integrados n Stubs: simular componentes faltantes Integracion Top-Down a bc defg hijklm no a bc d efg hij

Stubs n Stub (Baan: sesiones dummy) Reemplaza un componente llamado para la prueba de integración n Manténgalo Simple -imprimir / mostrar el nombre (Me han llamado) -responder al módulo de llamada (valor único) -Respuesta computarizada (variedad de valores) -solicitar respuesta de probador -Búsqueda de Lista de respuestas -proporcionar retardo de tiempo

Pros & cons del enfoque top-down n Ventajas: -La estructura de control crítico se prueba primero y la mayoría de las veces tambien. -puede demostrar el sistema de forma temprana (mostrar menús de trabajo) n Desventajas: -Necesidades de stubs -Hasta el último detalle -puede ser difícil de "ver" el resultado detallado (pero debería haber sido probado en la prueba de los componentes) -puede parecer más acabado de lo que es

a bc efg klm d i no hj n Lineas Bases: -lineabase 0: componente n -lineabase 1: n + i -lineabase 2: n + i + o -lineabase 3: n + i + o + d -etc. n Necesidades de drivers para llamar las lineas base de configuración n También necesita stubs para algunas líneas de base Integración Bottom-up bd i no hj

Drivers n Driver (Baan: sesiones dummy): arnés de prueba : Andamios n Son de propósito general o especialmente escrita (herramientas comerciales) -Invocan lineas bases -Envian cualquier línea base de datos de espera -Reciven cualquier producto de linea base (impreso) n cada línea base tiene diferentes requisitos del software de prueba de conducción

Pros & cons del enfoque bottom-up n Ventajas: -niveles más bajos son probados primero y más a fondo (pero deberá haber sido probado en pruebas de unidades) -bueno para probar las interfaces con el entorno externo (hardware, red) -visibilidad de los detalles n Desventajas: -Ningún sistema de trabajo hasta última línea base -Necesita tanto drivers y stubs -Mayor control de problemas encontrados al final

n Baselines: -lineabase 0: componente a -lineabase 1: a + b -lineabase 2: a + b + d -lineabase 3: a + b + d + i -etc. n Necesita stubs n No necesita drivers (si top-down) Capacidad mínima de integración (también llamado funcional) fg klm a b d i c e no hj a b d i c e no hj

Pros & cons de la Capacidad mínima n Ventajas: -El nivel de control es probado primero y más a menudo -La visibilidad de detalle -El verdadero sistema de trabajo se ve más temprano de forma parcial n Desventajas -necesita stubs

klmihj bc a fgde no Integración de Thread (también llamados funcionales) n orden de procesamiento de algún evento determina el orden de integración n interrupción, transacción de usuario n capacidad mínima en el tiempo n ventajas: -Primero procesamiento críticos -alerta temprana de problemas de rendimiento n n desventajas: -puede necesitar complejos drivers y stubs bcklmihjfgde

Pautas de integración n minimizar soporte software necesario n integrar una sola vez cada componente n cada referencia debe producir un resultado fácilmente verificable n integrar una pequeña cantidad de componentes a la vez - -uno a la vez componentes críticos o propensos a fallas - -combinar componentes relacionados simples

Planificación de la integración n La integración debe planificarse en la fase de diseño arquitectónico n el orden de integración luego determina el orden de construcción - -componentes terminados a tiempo para su referencia - -El desarrollo de componentes y pruebas de integración pueden hacerse en paralelo - ahorra tiempo

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Prueba de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Prueba del sistema n último paso de la integración n funcional -requisitos funcionales y pruebas basadas en los requisitos -negocio basado en el proceso pruebas n n No funcional -tan importante como requisitos funcionales -a menudo mal especificado -Pueden ser probados n A menudo realizado por el grupo de pruebas independiente

Prueba del sistema funcional n Requerimiento Funcional -un requisito que especifica una función que un sistema o componente del sistema debe realizar (ANSI/IEEE Std , ingeniería de Software terminología) n n Especificación Funcional -El documento que describe en detalle las características del producto con respecto a su capacidad prevista (BS 4778 parte 2, BS )

Pruebas basadas en los requerimientos n Utiliza la especificación de requisitos como la base para la identificación de pruebas -La tabla de contenido de la especificación de requisitos proporciona un inventario inicial de la prueba de condiciones de prueba -para cada sección / apartado / tema / área funcional, Análisis de riesgo para identificar más importante / crítica Análisis de riesgo para identificar más importante / crítica decidir cómo profundamente probar cada área funcional decidir cómo profundamente probar cada área funcional

Negocio basado en el proceso pruebas n Perfiles de usuario esperado -¿lo que se utilizarán más a menudo? -¿Qué es crítico para el negocio? n Esenarios del Negocio -operaciones típicas (desde el nacimiento hasta la muerte) n Casos de uso -casos preparados basados en situaciones reales

Sistema de Pruebas no funcional n diferentes tipos de pruebas del sistema no funcional: -usabilidad- configuración/ instalación -seguridad- fiabilidad / cualidades -documentación- respaldo / recuperación -Almacenamiento - performance, carga, tensión -volumen

Pruebas de rendimiento n Pruebas de sincronización -tiempos de respuesta y servicio -tiempos de respaldo de base de datos n n Capacidad y Volumen Pruebas - cantidad máxima o tasa de procesamiento  número de registros en el sistema  degradación agraciada n n Las pruebas de resistencia(24-hr operando?) -robustez del sistema -Localización de memoria

Pruebas de Multi-Usuario n Pruebas de Concurrencia -Numeros pequeños, grandes beneficios -detect record locking problems n Pruebas de Carga -la medición del comportamiento del sistema bajo carga multiusuario realista n Pruebas de Estres -ir más allá de los límites del sistema - saber lo que sucederá -especial importancia para el comercio electrónico Source: Sue Atkins, Magic Performance Management

¿Quién debe diseñar / realizar estas pruebas? Pruebas de Usabilidad n ¿mensajes a medida y significativos para los usuarios (reales)? n ¿interfaz coherente y consistente? n ¿suficiente redundancia de información crítica? n dentro de la "dotación humana?" (7±2 opciones) n ¿retroalimentación (espera mensajes)? n ¿claras asignaciones (cómo escapar)?

Pruebas de Seguridad n passwords n Cifrado n Permiso en los dispositivos de hardware n Niveles de acseso a la información n Autorización n Canales encubiertos n Seguridad Fisica

Configuración e instalación n Pruebas de Configuración -diverso ambiente de hardware o software -configuración del sistema -actualizar rutas - puede entrar en conflicto n Pruebas de Instalación -distribución (CD, red, etc.). y las sincronizaciones -aspectos físicos: campos electromagnéticos, calor, humedad, movimiento, sustancias químicas, fuentes de alimentación -desinstalar (quitar instalación)

Fiabilidad / cualidades n Fiabilidad -¿"el sistema será confiable-" cómo comprobarlo? -2 fallas al año más de diez años -Tiempo medio entre fallos (MTBF) -modelos de crecimiento de la confiabilidad n n Otras Cualidades -mantenibilidad, portabilidad, adaptabilidad, etc..

Respaldo y recuperación n Respaldos -Funciones de computadora -Procedimientos manuales (donde se almacenan las cintas) n Recuperación -Pruebas reales de Respaldos -procedimientos manuales desconocidos -deben ser ensayados regularmente -La documentación debe ser detallada, clara y exhaustiva

Documentación de Pruebas n Revisión de la documentación -Compruebe la precisión contra otros documentos -ganar consenso sobre el contenido -Existe documentación, en formato adecuado n Documentación de Pruebas -¿es útil? ¿funciona? -Manual de usuarios -documentación de mantenimiento

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Pruebas de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptacion Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Integración de pruebas en grande n Prueba el sistema terminado trabajando en conjunto con otros sistemas, por ejemplo -LAN / WAN, middleware de comunicaciones -otros sistemas internos (facturación, stock, personal, lote durante la noche, oficinas, otros países) -sistemas externos (bolsa de valores, noticias, proveedores) -intranet, internet / www -Paquetes de 3 ª Personas -intercambio electrónico de datos (EDI)

Enfoque n Identificación de riesgos -Qué áreas faltantes o mal funcionamiento sería más críticos - probarlas primero n “Divide y vencerás” -probar primero el exterior (en la interfaz de su sistema, por ejemplo prueba un paquete por cuenta propia) -Compruebe las conexiones de uno a la vez primero (tu sistema y otro) -combinar de forma incremental - más seguro que el "big bang" (no incremental)

Consideraciones de planificación n Recursos -identificar los recursos que se necesitarán (por ejemplo, redes) n Cooperación -cooperación de plan con otras organizaciones (por ejemplo proveedores, técnicos equipo de apoyo) n Plan de desarrollo -plan de pruebas de integración (en grande) podría influir en el plan de desarrollo (por ejemplo software de conversión debía desde el principio de intercambio de formatos de datos)

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Pruebas de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptación Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Pruebas de aceptación de usuario n Etapa final de validación -cliente (usuario) debe realizar o participar de cerca -cliente puede realizar cualquier prueba que lo desean, generalmente se basa en sus procesos de negocio -usuario final de cierre de sesión Enfoque -mezcla de las pruebas con guión y sin guión -Concepto de "Modelo de oficina" se usa a veces

Por que el cliente / usuario Participan n Los usuarios saben : -Lo que realmente ocurre en situaciones de negocios -La complejidad de las relaciones comerciales -¿Cómo los usuarios haría su trabajo usando el sistema? -variantes para tareas estándar (por ejemplo específico de país) -ejemplos de casos reales -¿Cómo identificar soluciones sensatas? Beneficio: comprensión detallada del nuevo sistema

Pruebas de aceptación de usuario 20% de la función en un 80% del código 80% de la función En un 20% de código Las pruebas de sistemas esta Distribuidas en esta linea Las pruebas de aceptación están distribuido sobre esta línea

Pruebas de aceptación del contrato n Contrato para el suministro de un sistema de software -Lo acordado en la etapa de definición del contrato -criterios de aceptación definidos y acordados -no se han mantenido al día con los cambios n Pruebas de aceptación del contrato, está en contra del contrato y los cambios documentados acordados -no lo que los usuarios desearían haber pedido! -Este sistema, no deseo otro sistema

Pruebas Alfa y Beta: similitudes n Pruebas por [potenciales] clientes o representantes de su mercado -no es adecuado para el software a medida n Cuando el software es estable n Utilizan el producto en forma realista en su entorno operativo n Devolver comentarios sobre el producto -fallas encontradas -el producto satisface sus expectativas -mejora / sugerencias de mejora

Pruebas Alfa y Beta: diferencias n Pruebas Alpha -pruebas operativas simuladas o reales de un sitio en casa, y no de otra manera involucrado con los desarrolladores de software (es decir, los desarrolladores del sitio) n n Pruebas Beta -pruebas de funcionamiento en un sitio que no estén involucrados con los desarrolladores de software (es decir, el sitio testers ', su ubicación propia)

Lema de prueba de aceptación Si no tienes paciencia para probar el sistema El sistema seguramente pondrá a prueba su paciencia Si no tienes paciencia para probar el sistema El sistema seguramente pondrá a prueba su paciencia

Contenidos Modelos para las pruebas, la economía de las pruebas Alto nivel de planificación de las pruebas Pruebas de Componentes Las pruebas de integración en pequeño Las pruebas del sistema (no funcional y funcional) Las pruebas de integración en grande Pruebas de Aceptación Pruebas de Mantenimiento Ciclo de Vida ISTQB / ISEB Foundation Exam Practice

Pruebas de Mantenimiento n Pruebas para preservar la calidad : -secuencia diferente pruebas de desarrollo ejecutan bottom-up pruebas de desarrollo ejecutan bottom-up pruebas de mantenimiento ejecutan top-down pruebas de mantenimiento ejecutan top-down datos de prueba diferentes (en perfil) datos de prueba diferentes (en perfil) -pruebas de amplitud para establecer confianza general -pruebas de profundidad para investigar cambios y áreas críticas -predominante pruebas de regresión

Que probar en pruebas de mantenimiento n Probar cualquier código nuevo o modificado n Análisis de impacto -que este cambio tendría un impacto sobre? -lo importante es una falla en el área impactada? -prueba de lo que ha sido afectada, pero cuánto? zonas afectadas más importantes? zonas afectadas más importantes? áreas más proclives a ser afectadas? áreas más proclives a ser afectadas? todo el sistema? todo el sistema? n La respuesta: "Depende"

Especificaciones pobres o que falta n Considerar lo que debe hacer el sistema -hablar con los usuarios n Documentar sus suposiciones -asegurarse de que otras personas tienen la oportunidad de revisarlos n Mejorar la situación actual -documentar lo que sabe y averiguar n Seguimiento costoso al trabajar con las especificaciones pobres -hacer caso de negocios para mejores especificaciones

¿Qué debe hacer el sistema? n Alternativas -el sistema funciona ahora debe ser correcto (excepto el cambio específico) - utilizar sistema existente como base para pruebas de regresión -buscar en manuales o guías (si existen) -pregunta a los expertos - los usuarios actuales n Sin una especificación, no pueden probar realmente, sólo explorar. Puede validar pero no verificar.

Resumen: Puntos claves Modelo V muestra niveles de prueba, diseño de pruebas tempranas Planificación de la prueba de alto nivel Prueba de componentes, utilizando el estándar Integración de pruebas en el pequeño: estrategias Sistema de prueba (no funcional y funcional) Integración de pruebas en el gran Pruebas de aceptación: responsabilidad del usuario Pruebas de Mantenimiento para preservar la calidad Lifecycle ISTQB / ISEB Foundation Exam Practice