Técnicas de diseño de pruebas

Técnicas de diseño de pruebas

1. El proceso de desarrollo de pruebas

   • El nivel de formalidad dependerá del contexto de las pruebas, incluyendo la madurez de las pruebas y de los procesos de desarrollo, las limitaciones de tiempo, los requisitos de seguridad o normativos y las personas implicadas
   • Durante el análisis de pruebas, se analiza la documentación base de pruebas para determinar qué se debe probar, es decir, para identificar las condiciones de prueba. Por condición de prueba se entiende un elemento o evento que debería ser verificado por uno o más casos de prueba (por ejemplo, una función, transacción, característica de calidad o elemento estructural).
   • Durante el diseño de pruebas, se crean y especifican los casos de prueba y los datos de prueba. Un caso de prueba consta de una serie de valores de entrada, precondiciones de ejecución, resultados esperados y condiciones de ejecución definidos para cubrir uno o varios objetivos de prueba o condiciones de prueba específicos. La norma IEEE STD 829-1998 (Standard for test documentation) describe el contenido de las especificaciones de diseño de pruebas (incluyendo condiciones de prueba) y las especificaciones de casos de prueba.
   • Durante la implementación de pruebas se desarrolla, implementan, priorizan y organizan los casos de prueba en la especificación de procedimiento de prueba (IEEE STD 829-1998). El procedimiento de prueba especifica la secuencia de acciones necesarias para ejecutar una prueba. Si las pruebas se ejecutan utilizando una herramienta de ejecución de pruebas, la secuencia de acciones se especifica en un guion de prueba (que es un procedimiento de prueba automatizado).

2. Categorías de técnicas de diseño de pruebas

   • El objetivo de una técnica de diseño de prueba es identificar condiciones de prueba, casos de prueba y datos de prueba. Tradicionalmente se distingue entre técnicas de pruebas de caja negra o de caja blanca.
   • Características de las técnicas de diseño de prueba basadas en la especificación (caja negra) son:
     • La especificación del problema a solucionar, el software o sus componentes se especifican a partir de modelos, tanto formales como informales.
     • Los casos de prueba pueden obtenerse sistemáticamente a partir de estos modelos
   • Características de las técnicas de diseño de prueba basadas en la estructura (Caja Blanca)son:
     • Información sobre cómo el software es construido, es utilizada para obtener los casos de prueba (por ejemplo, código e información de diseño detallada)
     • Puede medirse el alcance de la cobertura del software para los casos de prueba existentes, y puede obtenerse otros casos de prueba de manera sistemática para aumentar la cobertura.
   • Características de las técnicas de diseño de prueba basadas en la experiencia son:
     • Se emplea el conocimiento y la experiencia de las personas para obtener los casos de prueba
     • El conocimiento de los probadores, desarrolladores, usuarios y demás implicados sobre el software, su uso y su entorno constituye una fuente de información
     • El conocimiento sobre los defectos probables y su distribución constituye otra fuente de información

3. Técnicas basadas en la especificación o técnicas de caja negra

   • Partición de equivalencia
     • La partición de equivalencia puede utilizarse para lograr objetivos de cobertura de entrada y salida. Puede utilizarse con entradas manuales, entradas vía interfaces a un sistema, o parámetros de interfaz en las pruebas de integración.
   • Análisis de valores frontera
     • Esta técnica a menudo se considera como una extensión de la partición de equivalencia u otras técnicas de diseño de prueba de caja negra. Puede utilizarse en clases de equivalencia para valores que los usuarios introducen en pantalla y también en rangos de tiempo (tales como tiempo agotado o requisitos de velocidad de transacciones) o rangos de tabla (por ejemplo, el tamaño de la tabla es 256*256).
   • Pruebas de tabla de decisión
     • Las tablas de decisión constituyen una buena manera de reflejar los requisitos del sistema que contienen condiciones lógicas, y de documentar el diseño del sistema interno. Pueden utilizarse para registrar normas de negocio complejas que el sistema debe aplicar. Al crear las tablas de decisión, se analiza la especificación y se identifican las condiciones y acciones del sistema. Por lo general, las condiciones y acciones de entrada se exponen de manera que deben ser verdaderas o falsas (Booleano). La tabla de decisión incluye las condiciones de activación, a menudo combinaciones de verdadero y falso para todas las condiciones de entrada, y las acciones resultantes para cada combinación de condiciones.
   • Pruebas de transición de estado
     • Un sistema puede mostrar respuestas diferentes en función de sus condiciones actuales o su historial previo (su estado). En este caso, ese aspecto del sistema puede mostrarse con un diagrama de transición de estado. Esto permite al probador ver el software en términos de sus estados, transiciones entre estados, entradas o eventos que activan los cambios de estado (transiciones) y acciones que pueden derivarse de dichas transiciones. Los estados del sistema o del objeto sujeto a prueba son independientes, identificables y finitos en número.
   • Pruebas de caso de uso
     • Los casos de uso describen los “flujos de proceso” mediante un sistema basado en su uso real más probable, de manera que los casos de prueba obtenidos de los casos de uso resultan muy útiles a la hora de descubrir defectos en los flujos de proceso durante el uso real del sistema. Los casos de uso son de gran utilidad para diseñar pruebas de aceptación con la participación del cliente/usuario. Asimismo, ayudan a descubrir eventuales defectos de integración, provocados por la interacción y la interferencia de distintos componentes, que las pruebas de componente a nivel individual no pueden detectar. El diseño de los casos de prueba a partir de casos de uso puede combinarse con otras técnicas de pruebas basadas en la especificación.

4. Técnicas basadas en la estructura o técnicas de caja blanca

   • Las pruebas basadas en la estructura o pruebas de caja blanca se basan en una estructura identificada del software o del sistema, según se demuestra en los siguientes ejemplos:
     • Nivel de componente: la estructura de un componente de software, es decir, sentencias, decisiones, ramas o incluso caminos distintos
     • Nivel de integración: la estructura puede ser un árbol de llamadas (un diagrama en el que módulos llaman a otros módulos)
     • Nivel de sistema: la estructura puede ser una estructura de menús, procesos de negocio o una estructura de página web
   • Pruebas de sentencia y cobertura
     • En las pruebas de componente, la cobertura de sentencias es la evaluación del porcentaje de sentencias ejecutables que han sido practicadas por un juego de casos de prueba. La técnica de pruebas de sentencia obtiene casos de prueba para ejecutar sentencias específicas, normalmente con vistas a aumentar la cobertura de sentencias
     • La cobertura de sentencias viene determinada por el número de sentencias ejecutables cubiertas (diseñadas o ejecutadas) por casos de prueba dividido entre el número de todas las sentencias ejecutables en el código sujeto a prueba.
   • Pruebas de decisión y cobertura
     • La técnica de prueba de decisión obtiene los casos de prueba para ejecutar resultados de decisiones específicos. Las ramas provienen de puntos de decisión en el código y muestran la transferencia de control entre diferentes partes del código.
     • Las pruebas de decisión constituyen una forma de pruebas de flujo de control ya que siguen un flujo específico de control a través de los puntos de decisión. La cobertura de decisiones es más fuerte que la cobertura de sentencias; un 100% de cobertura de decisiones garantiza un 100% de cobertura de sentencias, pero no al contrario
   • Otras técnicas basadas en la estructura
     • Existen niveles más fuertes de cobertura estructural además de la cobertura de decisiones, como por ejemplo la cobertura de condiciones y la cobertura de condición múltiples. El concepto de cobertura también puede aplicarse a otros niveles de prueba. Así por ejemplo, en el nivel de integración, el porcentaje de módulos, componentes o clases practicados por un juego de casos de prueba podría expresarse como cobertura de módulo, de componente o de clase. El uso de herramientas constituye un soporte útil para las pruebas estructurales del código.

5. Técnicas basadas en la experiencia

   • Las pruebas basadas en la experiencia son aquellas en las que las pruebas se obtienen de la habilidad e intuición del probador y de su experiencia con aplicaciones y tecnologías similares.
     • En las pruebas exploratorias concurren el diseño de pruebas, la ejecución de pruebas, el registro en la bitácora de la prueba y el aprendizaje, en base a un contrato de pruebas que contempla los objetivos de las pruebas, y se llevan a cabo dentro de los períodos de tiempo establecidos. Se trata de un enfoque especialmente útil en los casos en los que las especificaciones son escasas o inadecuadas y existe una importante presión temporal, o para aumentar o complementar otras pruebas más formales.

6. Selección de la técnica de prueba

   • La selección de la técnica de prueba a utilizar depende de una serie de factores entre los que se incluyen el tipo de sistema, los estándares normativos, los requisitos contractuales o de cliente, el nivel de riesgo, el tipo de riesgo, el objetivo de prueba, la documentación disponible, el conocimiento de los probadores, el tiempo y el presupuesto, el ciclo de vida de desarrollo, los modelos de caso de uso y la experiencia previa en los tipos de defectos detectados.
     • Para crear casos de prueba, los probadores generalmente aplican una combinación de técnicas de pruebas, entre las que se incluyen técnicas guiadas por procesos, reglas y datos, con vistas a garantizar la adecuada cobertura del objeto sujeto a prueba.