Plan de estudios ISTQB: Nivel Fundamentosdinamizaconsulting.com/istqb/T3-Pruebas a traves... · 3.1...

Plan de estudios ISTQB: Nivel Fundamentos

Temario

1. INTRODUCCIÓN

2. FUNDAMENTOS DE PRUEBAS

3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL SOFTWARE

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 SOFTWARE

3.1 Modelos de Desarrollo Software

3.2 Niveles de Pruebas

3.3 Tipos de Pruebas

PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL SOFTWARE

IMPORTANTE:

El proceso de pruebas no es proceso aislado

Las actividades de pruebas están asociadas a actividades de desarrollo de 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




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.




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.




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.




Fases (IV):

Implementación

Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).



Modelo en cascada

Modelo de desarrollo secuencial (Modelo V)

Modelo de desarrollo iterativo-incremental

Pruebas en un modelo de ciclo de vida



Modelo en cascada



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.



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.



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.




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.




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.




Se basa en cuatro niveles de pruebas:

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación




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




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.




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.




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.




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.




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




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




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




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




Los niveles de prueba pueden combinarse o reorganizarse en función de la naturaleza o de la arquitectura del sistema



Distinguimos entre los siguientes modelos de pruebas:



Pruebas de sistema





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.




Bases:

Requisitos de componentes

Diseño de detalle

Código

Objetos de prueba:

Componentes

Programas

Conversión de datos/programas de migración




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




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)




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




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




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



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



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



Pruebas de sistema

Es frecuente en proyectos de mediana y gran envergadura, que las pruebas de sistema sean acometidas por equipos de pruebas independientes




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




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




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



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



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




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

Pueden no estar documentados




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




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




Incluyen

Pruebas de rendimiento

Pruebas de carga y de estrés

Pruebas de usabilidad

Pruebas de mantenibilidad

Pruebas de portabilidad

Pruebas de fiabilidad



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




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




El alcance depende del riesgo

Incluyen

Pruebas funcionales

Pruebas no funcionales

Pruebas estructurales




Son las pruebas destinadas a probar:

Modificaciones de mejora planificadas

Modificaciones correctivas y de emergencia

Modificaciones de entorno




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




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


Plan de estudios ISTQB: Nivel Fundamentosdinamizaconsulting.com/istqb/T3-Pruebas a traves... · 3.1...

Documents

Transcript of Plan de estudios ISTQB: Nivel Fundamentosdinamizaconsulting.com/istqb/T3-Pruebas a traves... · 3.1...