Pruebas de sistemas (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: PRUEBAS DE SISTEMA, ENTORNO DE PRUEBAS, NIVEL DE PRUEBA, DESARROLLO GUIADO POR PRUEBAS , PRUEBAS DE ACEPTACIÓN DE USUARIO.

Pruebas de sistemas

Base de pruebas:

1. Especificación de requisitos del sistema y software.
2. Caso de uso.
3. Especificaciones funcionales.
4. Informes de análisis de riesgos.

Objetos de prueba típicos:

1. Manuales de sistema, usuario y funcionamiento.
2. Configuración del sistema.
3. Datos de la configuración.

Las pruebas de sistema se refieren al comportamiento de todo un sistema/producto. El alcance de las pruebas debe estar claramente indicado en el Plan ;Maestro y/o en el Plan de Pruebas de Nivel para cada nivel de prueba.

En las pruebas de sistema, el entorno de pruebas debe coincidir en la máxima medida posible con el objetivo final o con el último de producción a fin de minimizar el riesgo de no identificar fallos específicos del entorno durante las pruebas.

• Las pruebas de sistema deben estudiar los requisitos funcionales y no funcionales del sistema y las características de calidad de los datos. 

• Los probadores también deben enfrentarse a requisitos incompletos o no documentados.

• Las pruebas de sistema de los requisitos funcionales empiezan utilizando las técnicas basadas en la especificación (técnicas de caja negra) más apropiadas para el aspecto del sistema a probar. As´pi por ejemplo, puede crearse una tabla de decisión para las combinaciones de los efectos descritos en las normas de negocio. 

• A continuación pueden utilizarse técnicas basadas en la estructura (técnicas de caja blanca) para evaluar la exhaustividad de las pruebas por lo que respecta a un elemento estructural, como por ejemplo una estructura de menú o la navegación de una página web.

• A menudo las pruebas de sistema las realiza un equipo de pruebas independiente.

Pruebas de integración (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: INTEGRACIÓN, PRUEBAS DE INTEGRACIÓN.


Pruebas de Integración

Base de pruebas.

1. Diseño de software y sistema.
2. Arquitectura.
3. Flujos de trabajo.
4. Casos de uso.

Objetos de prueba típicos:

1. Implementación de base de datos de subsistemas.
2. Infraestructura.
3. Interfaces.

Configuración del sistema

1. Datos de configuración.

Las pruebas de integración se ocupan para probar las interfaces de los componentes, las iteracciones con distintas partes de un mismo sistema, como el sistema operativo, el sistema de archivos y el hardware, y las interfaces entre varios sistemas.

Puede haber más de un nivel de pruebas de integración y pueden llevarse a cabo en objetos de prueba de distintos tamaño, según se indica a continuación:

1. Las pruebas de integración de componentes se ocupan de probar las iteracciones entre los componentes del software y se realizan a continuación de las pruebas de componente.
2.  Las pruebas de integración de sistema se ocupan de probar las iteracciones entre los distintos sistemas o entre el hardware y el software, y puede realizarse a continuación de las pruebas de sistema. En este caso, la organización de desarrollo puede controlar sólo una parte de la interfaz, lo que puede considerarse un riesgo. Los procesos de negocio implementados como flujos de trabajo pueden afectar a una serie de sistemas. os problemas de plataforma transversales pueden ser importantes.

Cuanto más amplio sea el alcance de la integración, más difícil será asilar los fallos de un componente o sistema específico , lo que puede provocar un mayor riesgo y un tiempo adicional de diagnóstico.

Las estrategias de integración sistemáticas pueden basarse en la arquitectura de sistema (tales como de arriba hacia abajo y de abajo hacia arriba), tareas funcionales, secuencias de procesamiento de transacciones o cualquier otro aspecto del sistema o de los componentes.

Con vistas a facilitar el aislamiento de faltas y realizar una detección temprana de los defectos, normalmente la integración será incremental  en lugar de tipo "big-bang".

Las pruebas de características específicas no funcionales (como el rendimiento) pueden incluirse tanto en las pruebas de integración como en las pruebas funcionales.

En cada fase de integración, los probadores deben concentrarse exclusivamente en la propia integración. Así están integrando el módulo A con el módulo B, deben concentrarse en probar la comunicación entre módulos, no la funcionalidad del módulo individual, ya que eso ya se hizo durante las pruebas de componente. Para ello pueden utilizarse tanto el enfoque funcional como el enfoque estructural.

Idealmente, los probadores deben entender la arquitectura y modificar la planificación de la integración en consecuencia. Si las pruebas de integración se planifican antes de construir los componentes o sistemas, dichos componentes pueden construirse en el orden necesario para que las pruebas sean lo más eficientes posible.

Pregunta de examen

9 Which of the following is the main purpose of the integration strategy for integration
testing in the small?
a) to ensure that all of the small modules are tested adequately
b) to ensure that the system interfaces to other systems and networks
c) to specify which modules to combine when and how many at once -->OK
d) to ensure that the integration testing can be performed by a small team
e) to specify how the software should be divided into modules

9 ¿Cuál de los siguientes afirmaciones es el objetivo principal de la estrategia de integración para la integración prueba en la pequeña ?.

a) garantizar que todos los pequeños módulos son probados adecuadamente
b ) asegurarse de que las interfaces del sistema con otros sistemas y redes
c ) para especificar qué módulos para combinar cuándo y cuántas a la vez-->OK
d ) para asegurar que la prueba de integración se puede realizar por un pequeño equipo
prueba en la pequeña ?
e) para especificar cómo el software debe ser dividido en módulos

23 Which of the following statements about the component testing standard is false:
a) black box design techniques all have an associated measurement technique-->OK
b) white box design techniques all have an associated measurement technique
c) cyclomatic complexity is not a test measurement technique
d) black box measurement techniques all have an associated test design technique
e) white box measurement techniques all have an associated test design technique


23 ¿Cuál de las siguientes afirmaciones sobre pruebas de componentes, es falso 
a) técnicas de diseño de la caja negra todos tienen asociado una técnica de medición.-->OK
b) técnicas de diseño de caja blanca todos tienen asociado una técnica de medición.
c) la complejidad ciclomática no es una técnica de medición de prueba
d ) las técnicas de medición de caja negra,  todos tienen una técnica de diseño.

e) Técnicas de medición de la caja blanca todos tienen una técnica de diseño de pruebas asociado

Pruebas de Componente (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: PRUEBAS DE COMPONENTE, CONTROLADOR, PRUEBAS DE CAMPO, REQUISITO FUNCIONAL, INTEGRACIÓN, REQUISITO NO FUNCIONAL, PRUEBAS DE ROBUSTEZ, "STUB", PRUEBAS DE SISTEMA, ENTORNO DE PRUEBAS , NIVEL DE PRUEBA, DESARROLLO GUIADO POR PRUEBAS.

Pruebas de Componentes.

Base de Pruebas:

1. Requisitos de componentes.
2. Diseño de detalle.
3. Código.

Objetos de prueba típicos:

1. Componentes.
2. Programas.
3. Conversión de datos/programas de migración.
4. Módulos de bases de datos.

Las pruebas de componente conocidas también como pruebas de unidad, módulo o programa, tiene por objeto localizar defectos y comprobar el funcionamiento de módulos de software, programas, objetos, clases, etc., que pueden probarse por separado. 

Pueden realizarse de manera independiente del resto del sistema, en función del contexto del ciclo de vida de desarrollo y del sistema. Para ello pueden utilizarse "stubs", controladores y simuladores.

Las pruebas de componente pueden incluir pruebas de funcionalidad y características no funcionales específicas , tales como el comportamiento de recursos (por ejemplo , la búsqueda de filtraciones de memoria) o pruebas de robustez, además de pruebas estructurales (por ejemplo, cobertura de decisión). Los casos de prueba se derivan de productos de trabajo, tales como las especificaciones de componente, el diseño del software o el modelo de datos.

En general, las pruebas de componentes se llevan a cabo mediante el acceso al código objeto de las pruebas y con el soporte de un entorno de desarrollo, como por ejemplo un marco de pruebas de unidad o una herramienta de depuración. En la práctica, las pruebas de componente generalmente cuentan con la participación del programador que escribió el código. En general, los defectos se corrigen en el momento en que se detectan, sin gestionarlos formalmente.

Un enfoque a seguir en las pruebas de componentes es elaborar y automatizar los casos de prueba antes de codificarlos. Esto se denomina un primer enfoque de pruebas o un desarrollo guiado por pruebas, Este enfoque es altamente iterativo y está basado en la realización de ciclos de desarrollo de casos de prueba, para después construir e integrar pequeñas partes del código, y en la ejecución de las pruebas de componente corrigiendo cualquier problema e ir iterando hasta que se superen.

Niveles de prueba (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: PRUEBAS ALFA, PRUEBAS BETA, PRUEBAS DE COMPONENTE, CONTROLADOR, PRUEBAS DE CAMPO, REQUISITO FUNCIONAL, INTEGRACIÓN, REQUISITO NO FUNCIONAL, PRUEBAS DE ROBUSTEZ, "STUB", PRUEBAS DE SISTEMA, ENTORNO DE PRUEBAS , NIVEL DE PRUEBA, DESARROLLO GUIADO POR PRUEBAS, PRUEBAS DE ACEPTACIÓN DE USUARIO.

Antecedentes.

Por cada nivel de prueba, pueden identificarse los siguientes aspectos:

1. Los objetivos genéricos, 
2. Los productos de trabajo a que se hace referencia para derivar los casos de prueba (es decir, la base de pruebas),
3. El objeto de la prueba (es decir, lo que se está probando),
4. Los defectos y fallos típicos a detectar, 
5. Los requisitos de arnés de pruebas y soporte de herramientas, y los enfoques específicos y responsabilidades.

En la fase de planificación de pruebas deberá tenerse en cuenta los datos de configuración del sistema , si dichos datos forman parte del sistema.

Pruebas en un Modelo de Ciclo de Vida (K2 - entender, explicar , razonar)

Objetivos:

1. Explicar la relación existente entre desarrollo, actividades de pruebas y productos de trabajo en el ciclo de vida del desarrollo, poniendo ejemplos utilizando tipos de proyectos y productos (K2).
2. Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto (K1).
3. Retener las características de buenas pruebas aplicables a cualquier modelo de ciclo de vida (K1)

Términos usados en este artículo: MODELO DE CICLO DE VIDA, BUENAS PRÁCTICAS, PRUEBAS.

Antecedentes.

En cualquier modelo de ciclo de vida que se ha seleccionado, se dan varias características de buenas pruebas:

• Para cada actividad de desarrollo existe una actividad de prueba correspondiente.
• Cada nivel de prueba tiene objetivos de pruebas específicos para dicho nivel.
• Los procesos de análisis y diseño de las pruebas para un nivel de prueba dado deben iniciarse durante la actividad de desarrollo correspondiente.
• Los probadores deben iniciar su participación en la revisión de los documentos en cuanto haya borradores disponibles en el ciclo de vida de desarrollo.

Los niveles de prueba pueden combinarse o reorganizarse en función de la naturaleza del proyecto o de la arquitectura del sistema. Así por ejemplo, para la integración de un producto de software comercial de distribución masiva (COST) en un sistema, el comprador puede realizar las pruebas de integración a nivel del sistema (por ejemplo, integración de la infraestructura y demás sistemas o despliegue del sistema) y las pruebas de aceptación (funcionales y/o no funcionales, y pruebas de usuario y/o operativas).

Resumamos los modelos de ciclo de vida.

Ahora bien, resumamos los modelos de ciclo de vida para darnos cuenta que tipo de pruebas son eficaces para las buenas prácticas.

Modelo de Cascada

1. Es un modelo orientado en las actividades.
2. Prescribe una ejecución secuencial de un subconjunto de los procesos de desarrollo y de administración.
3. Es el modelo más antiguo, propuesto por Witnston Royce en 1970.

Cuáles son sus fortalezas?

1. Fácil entendimiento e implementación.
2. Ampliamente utilizado y conocido (en teoría).
3. Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar.
4. Identifica entregables e hitos.
5. Orientado a documentos.
6. Funciona bien en productos maduros y equipos débiles.

Cuáles son sus debilidades?

1. No aprovecha la iteración, no el desarrollo exploratorio.
2. Espera requerimientos definidos completamente al inicio del proyecto -->IREAL.
3. Dificulta la administración del riesgo.
4. El software es entregado tarde en el proyecto. Esto hace que se detecten errores graves muy tarde.
5. Hacer cambios es difícil y costoso. 

Modelo en V

1. Busca hacer la actividad de pruebas más efectiva y productiva.
2. Los planes (y casos de prueba) se van elaborando a medida que se avanza en el desarrollo del proyecto.

Modelo en Espiral

1. Modelo centrado en las actividades.
2. Basado en las mismas actividades del modelo de cascada.
3. Introduce: manejo de riesgos y creación de prototipos.
4. Las actividades son organizadas en ciclos.
5. Un ciclo corresponde a la construcción de un producto intermedio.
6. Las actividades de cada ciclo son: 

• Determinar objetivos, 
• Especificar las restricciones, 
• Generar alternativas,
•  Identificar riesgos,Resolver riesgos, 
• Desarrollar y verificar próximo nivel del producto, 
• Desarrollar el plan del ciclo

Modelo Unified Process

1. Consiste en varios ciclos.
2. Al final de cada uno, un producto es entregado al cliente.
3. Cada ciclo consiste de cuatro fases: Inception, Elaboration, Construction y Transition.
4. Cada fase puede tener varias iteraciones.
5. Una iteración construye un conjunto de casos de uso relacionados o mitiga algún riesgo de los identificados.

Modelo Team Software Process TSP

1. Establecer un marco común para desarrollar modelos de ciclo de vida.
2. Proceso: conjunto de actividades para alcanzar un propósito.
3. 17 rocesos define el estándar organizados en grupos de procesos.
4. Cada proceso está compuesto de actividades.

Modelos de desarrollo de software - Iterativo Incremental (K2 - entender, explicar , razonar)

Objetivos:

1. Explicar la relación existente entre desarrollo, actividades de pruebas y productos de trabajo en el ciclo de vida del desarrollo, poniendo ejemplos utilizando tipos de proyectos y productos (K2).
2. Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto (K1).
3. Retener las características de buenas pruebas aplicables a cualquier modelo de ciclo de vida (K1)

Términos usados en este artículo: ITERACIÓN, INCREMENTAL, RAD, RUP, PROCESO, ESPIRAL.

Antecedentes.

El desarrollo iterativo-incremental es el proceso de establecer requisitos, diseñar, establecer y probar un sistema, realizando como una serie de ciclos de desarrollo mas cortos. Algunos ejemplos son : Prototipos , Desarrollos Rápido de Aplicaciones (RAD), Proceso Unificado Racional (RUP) y modelos de desarrollo ágil. 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 porbado. Después de la primera , las pruebas de regresión van adquiriendo importancia en todas las iteraciones. Los procesos de verificación y validación pueden llevarse a cabo para cada incremento.

Iteración de procesos.

Los cambios son inevitables en todos los proyectos de software grandes. Los requerimientos del sistema cambian cuando el negocio que procura el sistema responde a las presiones externas. Las prioridades de gestión cambian. Cunado se dispone de nuevas tecnologías, cambian los diseños y las implementación. Esto significa que el  proceso se repite regularmente conforme el sistema se rehace en respuesta a peticiones de cambios.

Existen dos modelos de procesos que han sido diseñados explícita mente para apoyar la iteración de procesos.

• Entrega incremental. La especificación , el diseño y la implementación del software se dividen en una serie de incrementos, los cuales se desarrollan por turnos;

• Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia afuera, empezando con un esbozo inicial y terminando con el desarrollo final del mismo.

La esencia de los procesos iterativos es que la especificación se desarrolla junto con el software. Sin embargo, esto crea conflictos con el modelo de obtención de muchas organizaciones donde la especificación completa del sistema es parte del contrato de desarrollo del mismo. En el enfoque incremental , no existe una especificación completa del sistema hasta que el incremento final se especifica. Esto requiere un nuevo tipo de contrato, que a los clientes grandes como las agencias del gobierno les puede ser difícil de incorporar.

Modelos de desarrollo de software - Verificación vs. Validación (K2 - entender, explicar , razonar)

Objetivos:

1. Comprender las diferencias entre verificación y validación del software. (K2).
2. Introducirse en las inspeccion de programas como un método para descubrir defectos en los programas.(K2).
3. Comprender qué es el análisis estático automatizado y cómo se utiliza en verificación y validación.(K2).

Términos usados en este artículo: VERIFICACIÓN, VALIDACIÓN, PLANIFICACIÓN, INSPECCIÓN, ESTÁTICO, MÉTODOS.

Antecedente.

Durante y después del proceso de implementación , el programa que se está desarrollando debe ser comprobado para asegurar que satisface su especificación y funcionalidad esperada por las personas que pagan por el software. La verificación y la Validación (V&V) es el nombre dado a estos procesos de análisis y pruebas. La verificación y la validación tienen lugar en cada estapa de proceso del software. V & V comienza con revisiones de los requerimientos y continúa con revisiones del diseño e inspecciones de código hasta la prueba del producto.

La verificación y la validación no son lo mismo, aunque a menudo se confunden. Boehm (Boehm 1979) expresó de forma sucinta la diferencia entre ellas:

• "Validación: ¿Estamos construyendo el producto correcto?"
• "Verificación:¿Estamos construyendo el producto correctamente?"

Según ISO 9000 la diferencias de describen como:

• "Validación: Comprobación de la idoneidad para el uso esperado" ¿Hemos construido el sistema de software correcto?
• "Verificación: Comprobación de la conformidad con los requicitios establecidos ¿Se ha procedido correctamente en la construcción del sistema?"

Estas definiciones nos dicen que el papel de la verificación implica comprobar que el software está de acuerdo con su especificación. Debería comprobarse que satisface sus requerimientos funcionales y no funcionales.

La validación, sin embargo, es un proceso más general. Su objetivo es asegurar que el sistema de software satisface las expectativas del cliente. Va más allá de la comprobación de que el sistema de software satisface  su especificación para demostrar que el software hace lo que el cliente espera que haga. Por qué? porque a veces las especificaciones del sistema de software no siempre reflejan los deseos o necesidades reales de los usuarios y los propietarios del sistema

El objetivo último del proceso de verificación y validación es establecer la seguridad de que el sistema de software está "HECHO PARA UN PROPÓSITO". Esto significa que el sistema debe ser lo suficientemente bueno para su uso pretendido.

Niveles de confianza según las expectativas de los usuarios y el entorno del mercado actual. 

1. Función del software. El nivel de confianza requerido depende de los crítico que sea el software para una organización, por ejemplo, el nivel de confianza crítico es mucho más alto que el requerido para un prototipo de un sistema de software que ha sido desarrollado para demostrar algunas ideas nuevas.
2. Expectativas del usuario. Una reflexión lamentable sobre la industria del software es que muchos usuarios tienen pocas expectativas sobre y no se sorprenden cuando éste falla durante su uso. Están dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son mayores que sus desventajas. Sin embargo, la tolerancia de los usuarios a los fallos de los sistemas está decreciendo desde los años 90. actualmente es menos aceptable entregar sistemas no fiables, por lo que laa compañías de software deben invertir más esfuerzo para verificar y validar. 
3. Entorno del mercado. Cuando un sistema se comercializa , los vendedores del sistema deben tener en cuenta los programas competidores, el precio que sus clientes están dispuesto a pagar por el sistema y la agenda requerida para entregar dicho sistema. Cuando una compañía tiene pocos competidores, puede decidir entregar un programa antes de que haya sido completamente probado y depurado, debido a que quiere ser el primero en el mercado. Cuando los clientes no están dispuestos a pagar precios altos pro el software, pueden estar dispuestos a tolerar más defectos en él. todos estos factores pueden considerarse cuando se decide cuánto esfuerzo debería invertirse en el proceso de V & V.

Aproximaciones complementarias para el análisis y comprobación de los sistemas.

1.    Las inspecciones de software analizan y comprueban las representaciones del sistema tales como el documento de requerimientos, los diagramas de diseño y el código fuentes del programa. Las inspecciones pueden ser complementadas con algún tipo de análisis automático del código fuente de un sistema o de los documentos asociados. Las inspecciones de software y los análisis automáticos son técnicas de V & V estáticas, ya que no se necesita ejecutar el software en una computadora.
2. Las pruebas del software implican ejecutar una implementación del software con datos de prueba. Se examinan las salidas del software y su entorno operacional para comprobar que funciona y como se requiere. Las pruebas son una técnica dinámica de verificación y validación.

En la presente imagen se muestra que las inspecciones del software y las pruebas son actividades complementarias en el proceso del software. Las flechas indican que las etapas en el proceso en las que pueden utilizarse dichas técnicas. Por lo tanto, se pueden utilizar las inspecciones del software en todas las etapas del proceso de desarrollo. Comenzando por los requerimientos, puede inspeccionarse cualquier representación legible del software.

Tipos de Pruebas 

Existen dos tipos distintos de pruebas que pueden utilizarse en diferentes etapas del proceso del software:

1. Las pruebas de validación: intenta demostrar que le software es el que el cliente quiere - que satisface sus requerimientos.
2. Las pruebas de defectos; intentan revelar defectos en el sistema en lugar de simular su uso operacional. Su objetivo es hallar inconsistencia entre un programa y su especificación.