Plan de estudios ISTQB: Nivel Fundamentos
Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE PRUEBAS 7. HERRAMIENTAS DE PRUEBAS
Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE PRUEBAS 7. HERRAMIENTAS DE PRUEBAS
Temario 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 3.1 Modelos de Desarrollo Software 3.2 Niveles de Pruebas 3.3 Tipos de Pruebas
IMPORTANTE: El proceso de pruebas no es proceso aislado Las actividades de pruebas están asociadas a actividades de desarrollo de software
3.1 Modelos de Desarrollo Software Ciclo de vida del software: El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. Requiere validar el desarrollo de la aplicación Garantizar que el software cumpla los requisitos para la aplicación Verificar los procedimientos
3.1 Modelos de Desarrollo Software Ciclo de vida del software: Fases: Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global. Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. Diseño general: requisitos generales de la arquitectura de la aplicación.
3.1 Modelos de Desarrollo Software Ciclo de vida del software: Fases (II): Diseño en detalle: definición precisa de cada subconjunto de la aplicación. Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
3.1 Modelos de Desarrollo Software Ciclo de vida del software: Fases (III): Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada. Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales. Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
3.1 Modelos de Desarrollo Software Ciclo de vida del software: Fases (IV): Implementación Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
3.1 Modelos de Desarrollo Software Modelo en cascada Modelo de desarrollo secuencial (Modelo V) Modelo de desarrollo iterativo-incremental Pruebas en un modelo de ciclo de vida
3.1 Modelos de Desarrollo Software Modelo en cascada
3.1 Modelos de Desarrollo Software Modelo en cascada Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente Ejemplos: Utilizado en los sistemas gubernamentales de gran tamaño, en especial en el Departamento de Defensa de los Estados Unidos (DOD). Es utilizado en la NASA.
3.1 Modelos de Desarrollo Software Modelo en cascada Ventajas: De partida se cuenta con los requerimientos muy completos y consistentes. Disminuye el efecto bola de nieve al reducir el mantenimiento considerando que se tienen unas especificaciones completas y correctas.
3.1 Modelos de Desarrollo Software Modelo en cascada Desventajas El tiempo que se invierte en crear el prototipo incluyendo un costo adicional de la inversión debido a que supone es la creación de un desechable.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V)
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) La corriente de especificación (parte izquierda, Project definition) consiste en: Conceptos de operaciones: que debe hacer el sistema a grandes rasgos. Requisitos del sistema y arquitectura del mismo. Diseño detallado.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) La corriente de pruebas (parte derecha, Project test and integration) consiste en: Integración de las distintas partes, prueba y verificación de las mismas. Verificación y validación del sistema en conjunto. Mantenimiento del sistema.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) Se basa en cuatro niveles de pruebas: Pruebas de componente Pruebas de integración Pruebas de sistema Pruebas de aceptación
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) En la práctica, un modelo secuencial puede tener más, menos o diferentes niveles de desarrollo y pruebas en función del proyecto y de producto de software. Los productos de trabajo de software que se elaboran en la fase de desarrollo a menudo conforman la base de las pruebas en uno o más niveles de pruebas
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) Objetivos: Minimización de los riesgos del proyecto: Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques estandarizados, describe los resultados correspondientes y funciones de responsabilidad. Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) Objetivos (II): Mejora y Garantía de Calidad Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se puede comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) Objetivos (III): Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.
3.1 Modelos de Desarrollo Software Modelo de desarrollo secuencial (Modelo V) Objetivos (IV): Mejora de la comunicación La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor y desarrollador.
3.1 Modelos de Desarrollo Software Modelo de desarrollo iterativo-incremental
3.1 Modelos de Desarrollo Software Modelo de desarrollo iterativo-incremental
3.1 Modelos de Desarrollo Software Modelo de desarrollo iterativo-incremental Se basa en establecer requisitos, diseñar, establecer y probar un sistema realizando ciclos de desarrollo más cortos El sistema resultante producido por iteración puede ser probado en distintos niveles de prueba durante cada iteración
3.1 Modelos de Desarrollo Software Modelo de desarrollo iterativo-incremental Un incremento, sumado a otros previamente desarrollados, constituye un sistema parcial creciente, que también debe ser probado Después de la primera, las pruebas de regresión adquieren importancia con cada iteración Los procesos de verificación y validación pueden llevarse a cabo para cada incremento
3.1 Modelos de Desarrollo Software Modelo de desarrollo iterativo-incremental Se suele utilizar en proyectos en los que los requerimientos no están claros por parte del usuario En aplicaciones medianas o grandes, en las que no es necesario que todo esté operativo desde el principio Ejemplo: Cuando una empresa quiere migrar sus aplicaciones a otra arquitectura, y desea hacerlo de forma escalonada
3.1 Modelos de Desarrollo Software Pruebas en un modelo de ciclo de vida Características de las pruebas: Actividad de prueba por cada actividad de desarrollo Cada nivel de prueba tiene sus objetivos de prueba Análisis y diseño de pruebas durante la actividad de desarrollo correspondiente Probadores implicados lo antes posible
3.1 Modelos de Desarrollo Software Pruebas en un modelo de ciclo de vida Los niveles de prueba pueden combinarse o reorganizarse en función de la naturaleza o de la arquitectura del sistema
3.2 Niveles de Pruebas Distinguimos entre los siguientes modelos de pruebas: Pruebas de componente Pruebas de integración Pruebas de sistema Pruebas de aceptación
3.2 Niveles de Pruebas Pruebas de componente Las pruebas de componente (también llamadas de unidad o módulo) tienen como objetivo localizar defectos y comprobar el funcionamiento de módulos de software, programas, objetos, clases, etc Pueden realizarse de manera independiente del resto del sistema, en función del contexto del ciclo de vida de desarrollo y del sistema.
3.2 Niveles de Pruebas Pruebas de componente Bases: Requisitos de componentes Diseño de detalle Código Objetos de prueba: Componentes Programas Conversión de datos/programas de migración
3.2 Niveles de Pruebas Pruebas de componente Pueden incluir pruebas de funcionalidad y características no funcionales específicas o pruebas de robustez Se llevan a cabo mediante el acceso al código objeto de las pruebas y con un soporte de entorno de desarrollo Se elaboran los casos de prueba antes de codificarlos
3.2 Niveles de Pruebas Pruebas de integración Las pruebas de integración se ocupan de probar las interfaces entre los componentes, las interacciones con distintas partes de un mismo sistema (como el sistema operativo, sistema de archivos, el hardware o las interacciones con otros sistemas)
3.2 Niveles de Pruebas Pruebas de integración Bases: Diseño de software, arquitectura y sistema Flujos de trabajo Casos de uso Objetos de prueba: Interfaces Infraestructura Implementación de bases de datos de subsistemas
3.2 Niveles de Pruebas Pruebas de integración Puede haber más de un nivel de pruebas de integración, en función del tamaño de los objetos de las pruebas: Pruebas de integración de componentes Pruebas de integración de sistemas
3.2 Niveles de Pruebas Pruebas de integración Cuanto más amplios sea el alcance de la integración, más difícil será aislar los fallos de una componente o sistema específico Normalmente la integración será incremental En cada fase de integración, los probadores deben centrarse en la propia integración Los probadores deben entender la arquitectura y modificar la planificación de la integración si procede
3.2 Niveles de Pruebas Pruebas de sistema Las pruebas de sistemas se refieren al comportamiento de todo un sistema/producto El entorno de pruebas debe coincidir en la máxima medida al entorno de producción final Deben estudiar requisitos funcionales y no funcionales Los probadores estarán capacitados para enfrentarse a requisitos incompletos o mal documentados
3.2 Niveles de Pruebas Pruebas de sistema Bases: Especificaciones de requisitos de sistema y software Casos de uso y especificaciones funcionales Informes de análisis y riesgos Objetos de prueba: Manuales: de sistema, de usuario y de funcionamiento Configuración del sistema
3.2 Niveles de Pruebas Pruebas de sistema Es frecuente en proyectos de mediana y gran envergadura, que las pruebas de sistema sean acometidas por equipos de pruebas independientes
3.2 Niveles de Pruebas Pruebas de aceptación Las pruebas de aceptación tienen como objetivo principal generar confianza en el sistema, partes del sistema o características específicas no funcionales del sistema Responsabilidad compartida con clientes y usuarios El objetivo principal no es la localización de defectos
3.2 Niveles de Pruebas Pruebas de aceptación Bases: Requisitos de usuario y sistema Casos de uso y procesos de negocio Informes de análisis de riesgos Objetos de prueba: Procesos: de negocio, operativos y de mantenimiento Procedimientos de usuario Formularios e informes
3.2 Niveles de Pruebas Pruebas de aceptación No constituyen necesariamente el último nivel de prueba Pueden darse en distintos momentos del ciclo de vida Pueden adoptar entre otras, las siguientes formas: Pruebas de aceptación de usuario Pruebas operativas de aceptación Pruebas de aceptación contractual y normativa Pruebas alfa y beta
3.3 Tipos de Pruebas Un tipo de prueba se centra en un objetivo de prueba en particular, que puede ser: Una función a realizar por el software Una característica de calidad no funcional La estructura o arquitectura del software o sistema
3.3 Tipos de Pruebas Pruebas de funciones (funcionales) Pruebas de características no funcionales del software (no funcionales) Pruebas de estructura/arquitectura del software (estructurales) Pruebas asociadas a cambios (repetición y regresión) Pruebas de mantenimiento
Pueden no estar documentados PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 3.3 Tipos de Pruebas Pruebas de funciones (funcionales) Las funciones son todo lo que hace el sistema, subsistema o componente Caja negra Las funciones pueden describirse en: Especificación de requisitos Casos de uso Especificación funcional
3.3 Tipos de Pruebas Pruebas de funciones (funcionales) Se basan en funciones y prestaciones, y en su interoperatividad con otros sistemas Pueden llevarse a cabo en todos niveles de pruebas Tienen en cuenta el comportamiento externo del software Ejemplo: Pruebas de seguridad
3.3 Tipos de Pruebas Pruebas de características no funcionales del software (no funcionales) Hace referencia a las pruebas necesarias para medir las características de los sistemas y software, que pueden cuantificarse, tales como tiempos de respuesta en caso de pruebas de rendimiento Se refieren a como funciona el sistema Pueden ejecutarse a todos los niveles de prueba
3.3 Tipos de Pruebas Pruebas de características no funcionales del software (no funcionales) Incluyen Pruebas de rendimiento Pruebas de carga y de estrés Pruebas de usabilidad Pruebas de mantenibilidad Pruebas de portabilidad Pruebas de fiabilidad
3.3 Tipos de Pruebas Pruebas de estructura/arquitectura del software (estructurales) Se realiza sobre las funciones internas de un módulo Caja blanca Son las más adecuadas para medir la exhaustividad de las pruebas Pueden realizarse en todos los niveles de pruebas
3.3 Tipos de Pruebas Pruebas asociadas a cambios (repetición y regresión) Una vez detectado y corregido el defecto, el software debe volver a probarse para confirmar que el defecto ha sido corregido con éxito Después de que desarrollo realice la depuración Son la prueba reiterada de un programa ya probado Deben ser repetibles Pueden realizarse en todos los niveles de prueba
3.3 Tipos de Pruebas Pruebas asociadas a cambios (repetición y regresión) El alcance depende del riesgo Incluyen Pruebas funcionales Pruebas no funcionales Pruebas estructurales
3.3 Tipos de Pruebas Pruebas de mantenimiento Son las pruebas destinadas a probar: Modificaciones de mejora planificadas Modificaciones correctivas y de emergencia Modificaciones de entorno
3.3 Tipos de Pruebas Pruebas de mantenimiento La planificación anticipada de versiones es crucial para el éxito de estas pruebas Dos subtipos: Versiones planificadas Arreglos urgentes En caso de migración, incluirán pruebas en el nuevo entorno
3.3 Tipos de Pruebas Pruebas de mantenimiento Incluyen pruebas de regresión ampliadas a partes del sistema que no han sido modificadas Pueden realizarse en todos niveles de prueba Pueden realizarse en todos o en cualquier tipo de prueba Análisis de impacto
Ejercicios Modelos de desarrollo del software: nombrar y definir características Nombrar y comparar los distintos niveles de pruebas Nombrar y comparar los distintos tipos de pruebas