Directriz: Plan de prueba
Un plan de prueba debe cubrir requisitos, riesgos, prioridad, estrategia y criterios de terminación. En esta directriz se describe detalladamente el objetivo de un plan de prueba y su contenido.
Relaciones
Elementos relacionados
Descripción principal

Visión general

El objetivo del plan de prueba es comunicar la intención de las tareas de prueba. Es crítico que este documento se cree tan pronto como sea posible. La generación de este artefacto en una de las primeras iteraciones de la fase de elaboración no sería demasiado pronto. Puede ser deseable desarrollar el plan de prueba iterativamente, añadiendo secciones a medida que la información esté disponible.

Hay que tener cuidado de comunicar claramente el ámbito de la prueba, los requisitos de la prueba, las estrategias de la prueba y los recursos necesarios. Esta información identifica el objetivo y los límites del esfuerzo de prueba, qué se probará, cómo se probará y qué recursos son necesarios para la prueba. Indicar claramente esta información acelerará la revisión, comentarios y aprobación del esfuerzo de prueba.

Al inicio del proyecto, se debería crear un plan de prueba que identifique las pruebas globales previstas para el proyecto, denominado "Plan de prueba maestro". A medida que se planea cada iteración, se crea un "Plan de prueba de iteración" más preciso (o varios planes de prueba, organizados por tipo de prueba), que contiene sólo los datos (requisitos de prueba, estrategias de prueba, recursos, etc.) que pertenecen a la iteración. De forma alternativa, esta información se puede incluir en el Plan de iteración, si no complica demasiado la gestión o el uso del plan de iteración. 

A continuación se muestran algunas directrices para identificar y comunicar mejor los requisitos de prueba, los riesgos de la prueba, las prioridades y las estrategias de prueba.

Identificación de requisitos para la prueba

Los requisitos para la prueba identifican qué se probará. Son el destino específico de una prueba. Existen unas cuantas normas generales a aplicar cuando se deriven requisitos para la prueba:

  • El requisito para la prueba debe ser un comportamiento observable y medible. Si el requisito para la prueba no se puede observar ni medir, no se puede valorar para determinar si se ha satisfecho el requisito.
  • No existe una relación de uno a uno entre cada caso de uso o requisito suplementario de un sistema y un requisito de prueba. Los casos de uso a menudo tendrán más de un requisito que se debe probar, mientras que algunos requisitos suplementarios derivarán uno o más requisitos para probar y otros no derivarán ninguno (como los requisitos de marketing o de embalaje).

Los requisitos de prueba se pueden derivar de cualquier origen, incluyendo casos de uso, modelos de caso de uso, especificaciones suplementarias, requisitos de diseño, clases de negocio, entrevistas con usuarios y el documento de arquitectura de software. Todos estos deben revisarse para recopilar la información que se utiliza para identificar los requisitos para la prueba.

Requisitos para pruebas funcionales

Los requisitos funcionales de la prueba, como su nombre indica, se derivan de las descripciones de los comportamientos funcionales del destino de la prueba. Como mínimo, cada caso de uso debe derivar un requisito para la prueba. Una lista más detallada de requisitos para prueba incluiría como mínimo un requisito de prueba para cada flujo de sucesos del caso de uso.

Requisitos para pruebas de rendimiento

Los requisitos de rendimiento para la prueba se derivan de los comportamientos de rendimiento especificados del destino de la prueba. Habitualmente, el rendimiento se indica como medida de tiempo de respuesta y/o utilización de recursos, tal como se mide debajo de diferentes condiciones, que incluyen

  • diferentes cargas de trabajo y/o condiciones de sistema
  • diferentes casos de uso
  • diferentes configuraciones

Los requisitos de rendimiento se describen en las especificaciones suplementarias. Revise estos materiales, , dedicando una atención especial a las sentencias que incluyen lo siguiente:

  • sentencias de tiempo, como tiempo de respuesta o perfiles de tiempo
  • sentencias que indiquen qué número de sucesos o casos de uso ocurren en un periodo de tiempo indicado
  • sentencias que comparan el comportamiento de uno elemento con otro
  • sentencias que comparan el comportamiento de la aplicación en una configuración con el de otra
  • fiabilidad operativa (tiempo medio de anomalía o MTTF) durante un periodo de tiempo
  • configuraciones o restricciones

Debe derivar como mínimo un requisito para probar para cada sentencia en la especificación que refleja información como la que se lista arriba.

Requisitos de las pruebas de fiabilidad

Los requisitos de fiabilidad para las pruebas se derivan de varias fuentes, habitualmente descritas en especificaciones suplementarias, directrices de interfaz de usuario, directrices de diseño y directrices de programación.

Revise estos productos de trabajo y dedique una atención especial a las sentencias que incluyen lo siguiente:

  • sentencias de fiabilidad o resistencia a anomalías, errores de tiempo de ejecución (como fugas de memoria)
  • sentencias que indican la integridad del código y de la estructura (cumplimiento del lenguaje y la sintaxis)
  • sentencias referentes a la utilización de recursos

Debe derivar como mínimo un requisito para la prueba a partir de cada sentencia de los productos de trabajo que refleja información como la que se lista arriba.

Unas pruebas satisfactorias requieren que el esfuerzo de prueba equilibre satisfactoriamente los factores como las restricciones de recursos y los riesgos. Para cumplir esto, el esfuerzo de prueba debe tener prioridad para que el caso de uso más importante, significativo o el más arriesgado o los componentes se prueben primero. Para dar prioridad al esfuerzo de prueba, una valoración de riesgo y un perfil operativo se efectúan y se utilizan como base para establecer la prioridad de la prueba.

En las secciones siguientes se describe cómo determinar la prioridad de las pruebas.

Valorar el riesgo y establecer las prioridades de prueba

Identificar los requisitos para las pruebas es sólo una parte de la identificación que se probará. Dar prioridad a lo que se probará y en qué orden también debería realizarse. Este paso se efectúa por diferentes motivos, que incluyen los siguientes:

  • asegúrese de que los esfuerzos de prueba se centran en los requisitos más apropiados para la prueba
  • garantizar que los requisitos más críticos, significativos o arriesgados para la prueba se solucionen cuanto antes
  • asegúrese de que se prueban las dependencias como secuencia o datos

Existen tres pasos para valorar el riesgo y establecer las prioridades de la prueba:

A continuación se proporcionan las directrices para cada uno de estos tres pasos:

Valorar el riesgo

El establecimiento de la prioridad de la prueba empieza con la valoración del riesgo. Los casos de uso o componentes que implican el mayor riesgo debido a errores o que tienen una alta probabilidad de error deben estar entre los primeros casos de uso probados.

Empiece por la identificación y la descripción de los indicadores de magnitud de riesgo que se utilizarán, como por ejemplo:

  • H - alto riesgo, no tolerable. Exposición externa grave. La empresa sufrirá grandes pérdidas financieras, de fiabilidad o una pérdida de reputación irrecuperable.
  • M - riesgo medio, tolerable pero no deseable. Exposición externa mínima, la empresa puede sufrir económicamente, pero existe una fiabilidad limitada o pérdida de reputación.
  • L - bajo riesgo, tolerable. Exposición reducida o no externa, la empresa tiene pocas pérdidas o no tiene pérdidas económicas o de fiabilidad. La reputación de la empresa no se ve afectada.

Después de identificar los indicadores de magnitud de riesgo, lista cada caso de uso o componente en el destino de la prueba. Para cada caso de uso o componente de la lista, identifique un indicador de magnitud de riesgo y justifique (en una sentencia breve) el valor que ha seleccionado.

Existen tres perspectivas que se pueden utilizar para valorar el riesgo:

  • Efecto - el impacto o consecuencia de casos de uso especificados (requisitos, etc.) errores
  • Causa - empieza con un resultado indeseable provocado por el error de un caso de uso y examina las causas posibles
  • Probabilidad - la probabilidad de error de un caso de uso.

Seleccione una perspectiva, identifique un indicador de magnitud de riesgo y justifique la selección. No es necesario identificar un indicador para cada perspectiva de riesgo. Sin embargo, se sugiere que, si se ha identificado un indicador bajo, intente evaluar el elemento desde una perspectiva de riesgo diferente para garantizar que el elemento es realmente de bajo riesgo.

A continuación se muestran más detalles de la valoración de riesgo desde estas tres perspectivas.

Efecto

Para valorar el riesgo por Efecto, identifique una condición, suceso o acción e intente determinar su impacto. Haga una pregunta:

"¿Qué pasaría si ___________?"

Por ejemplo:

  • "¿Qué ocurriría si mientras instalo el nuevo software, el sistema se queda sin espacio en disco?"
  • "¿Qué ocurriría si la conexión a Internet se pierde durante una transacción de consulta?"
  • "¿Qué ocurriría si la conexión a Internet se pierde durante una transacción de compra?"
  • "¿Qué ocurriría si el usuario entra un valor inesperado?"

A continuación se muestra una matriz de justificación de estos elementos:

Descripción Factor de mitigación de riesgo Justificación
Espacio en disco insuficiente durante la instalación H Instalar el software proporciona al usuario la primera impresión del producto. Cualquier resultado no deseado, como los que se listan a continuación, degradaría el sistema del usuario, el software instalado, y comunicaría una impresión negativa al usuario:
  • el software está parcialmente instalado (algunos archivos, algunas entradas de registro, que dejan el software instalado en una condición inestable
  • la instalación se detiene dejando en sistema en estado inestable
se ha perdido la conexión a Internet durante la consulta L No hay daños resultantes de la pérdida de la conexión en los datos o la base de datos. Se reconoce que una conexión perdida puede comunicar una impresión negativa al usuario.
se ha perdido la conexión a Internet durante la compra H Cualquier conexión o transacción perdida que provoquen los resultados que se listan a continuación son inaceptables, ya que aumentan los costes y reducen los beneficios:
  • base de datos dañada
  • orden parcial
  • datos o orden perdido
  • múltiples órdenes (replicados)
Valor entrado inesperado H Cualquier transacción que provoque los resultados que se listan a continuación es inaceptable:
  • base de datos dañada
  • datos incorrectos

Causa

Valorar el riesgo por Causa es lo contrario de valorarlo por Efecto. Empiece indicando un suceso o condición no deseable, e identifique el conjunto de sucesos que habrían permitido que la condición existiera. Pregunte algo parecido a:

"¿Podría suceder que ___________?

Por ejemplo:

  • "¿Cómo podrían estar en el sistema sólo algunos archivos y no todas las entradas de registro que se hacen?"
  • "¿Cómo podría no reflejarse adecuadamente una transacción en la base de datos central?
  • "¿Cómo podría la sentencia de ciclo de facturación reflejar sólo algunos registros de la base de datos que cumplen los criterios deseados?"

A continuación se muestra una matriz de justificación de estos elementos:

Descripción Factor de mitigación de riesgo Justificación
Archivos que faltan / de aplicación y entradas de registro H Hace que la aplicación (y, potencialmente, el sistema) sea inutilizable. La instalación es la primera vista de la aplicación por parte de los usuarios. Si la instalación falla, por cualquier motivo, el usuario ve el software desfavorablemente.

Las posibles causas de esta condición incluyen:

  • el proceso de instalación no ha instalado todos los archivos ni ha actualizado el registro correctamente
  • el proceso de instalación se ha detenido por la intervención de un usuario (cancelar o salir)
  • el proceso de instalación se ha detenido por la intervención del software / hardware (espacio en disco insuficiente, configuración no soportada, etc.)
  • el proceso de instalación se ha detenido por condiciones desconocidas
  • los archivos /entradas de registro del usuario suprimidos

De estas causas, sólo la última no se puede detectar y gestionar en el proceso de instalación.

orden parcial H Los pedidos parciales no se pueden completar, lo que resulta en la pérdida de ingresos y de clientes.

Las posibles causas incluyen:

  • Conexión a Internet perdida debido a la acción del usuario (desconectar módem, apagar PC, etc.)
  • conexión a Internet perdida debido a IP
  • conexión a Internet perdida debido a la acción de un empleado (desconectar módem, apagar la alimentación de los servidores, etc.)
Datos / base de datos dañados H Los datos dañados no se tolerarán por ningún motivo.

Las posibles causas incluyen:

  • La transacción que escribe en la base de datos no se ha completado / cometido por la intervención del usuario
  • La transacción que escribe en la base de datos no se ha completado / cometido por la pérdida de la conexión a Internet
  • El usuario ha entrado datos no válidos en la transacción
  • Métodos / programas de utilidad de acceso a la base de datos
  • La base de datos no se ha rellenado correctamente (cuando se creaban las instancias iniciales)
Pedidos replicados H Los pedidos replicados aumentan los gastos generales consumidos por la empresa y reducen los beneficios a través de los costes asociados con el envío, gestión y reabastecimiento.

Las posibles causas incluyen:

  • La transacción que escribe el pedido en la base de datos replicada debido a la intervención del usuario, el usuario entra dos veces el pedido - sin confirmación de entrada
  • La transacción que escribe el pedido en la base de datos replicada sin la intervención del usuario, (proceso de recuperación de la conexión a Internet perdida, restauración de la base de datos)
Datos inapropiados para un pedido H Todos los pedidos que no se pueden completar o que provocan gastos adicionales no son aceptables.

Las posibles causas incluyen:

  • La transacción del pedido no se ha completado / cometido por la intervención del usuario
  • La transacción del pedido no se ha completado / cometido por la pérdida de la conexión a Internet
  • El usuario ha entrado datos no válidos
Número incorrecto de registros reflejado en la sentencia H Las decisiones empresariales y las cuentas recibibles dependen de la precisión de estos informes.

Las posibles causas incluyen:

  • Criterios de búsqueda /selección incorrectos
  • Sentencias SQL incorrectas
  • Datos dañados en la base de datos
  • Datos incorrectos en la base de datos

Probabilidad

Valorar el riesgo por Probabilidad es determinar la probabilidad de que un caso de uso (o un componente que implemente un caso de uso) falle. La probabilidad suele basarse en los factores externos como:

  • Índices de error
  • Índice de cambio
  • Complejidad
  • Origen / Originador

Debe tenerse en cuenta que, al utilizar esta perspectiva de riesgo, los indicadores de magnitud de riesgo están relacionados con la probabilidad de un error, no con el efecto o el impacto que tiene en la organización tal como se utilizaba para valorar el riesgo por Efecto y Causa.

Las correlaciones entre estos factores y la probabilidad de un error existen, tal como se identifican a continuación:

Factor externo Probabilidad
Tasa de descubrimiento de errores
La probabilidad de anomalía aumenta a medida que aumentan los índices de descubrimiento de anomalías. Los defectos tienden a congregarse y, por lo tanto, el índice de descubrimiento de los defectos (densidad) aumenta en un caso de uso o componente, la probabilidad de encontrar otro defecto también aumenta. Los índices de descubrimiento y de densidad de los releases anteriores también deben considerarse al valorar el riesgo utilizando este factor, ya que los índices de descubrimiento elevados anteriores y las densidades indican una alta probabilidad de anomalías adicionales.
Índice de cambio La probabilidad de anomalía aumenta a medida que aumenta el índice de cambio en el caso de uso o en el componente. Por lo tanto, a medida que aumenta el número de cambios, también aumenta la probabilidad de que se haya introducido un defecto. Cada vez que se realiza un cambio en el código, existe el riego de "inyectar" otro defecto.
Complejidad La probabilidad de anomalía aumenta a medida que aumenta la complejidad del caso de uso o del componente.
Origen / Originador El conocimiento y experiencia de dónde y quién ha originado el código puede aumentar o reducir la probabilidad de una anomalía.
La utilización de componentes de terceros habitualmente reduce la probabilidad de anomalía. Sin embargo, esto sólo es cierto si el componente de terceros se ha certificado (cumple sus requisitos, a través de pruebas formales o experiencia).
La probabilidad de error suele disminuir con el aumento del conocimiento y las habilidades del implementador. No obstante, factores tales como la utilización de nuevas herramientas, tecnologías o actuar en múltiples roles puede aumentar la probabilidad de una anomalía incluso con los mejores miembros del equipo.



Por ejemplo:

  • Instalación del nuevo software
  • "Históricamente hemos encontrado muchos defectos en los componentes que se utilizan para implementar los casos de uso 1, 10 y 12, y nuestros clientes nos han solicitado muchos cambios en los casos de uso 14 y 19".

A continuación se muestra una matriz de justificación de estos elementos:

Descripción Factor de mitigación de riesgo Justificación
Instalación de nuevo software H Estamos escribiendo nuestro propio programa de utilidad de instalación.

Representa el uso de la aplicación inutilizable. La instalación es la primera vista de la aplicación por parte de los usuarios. Si la instalación falla, por cualquier motivo, el usuario ve el software desfavorablemente.

Instalación de nuevo software L Estamos utilizando un programa de utilidad de instalación comercialmente satisfactorio.

Mientras que la instalación anómala hace que la aplicación sea inutilizable, el programa de utilidad de instalación seleccionado es de un proveedor que ha alcanzado el número uno del mercado con su producto y se comercializa desde hace más de cuatro años. Nuestra evaluación indica que el producto cumple nuestras necesidades y que los clientes están satisfechos con su producto, el proveedor y el nivel de servicio y de soporte.

Índices de descubrimiento de anomalías elevado / densidades de defectos en los casos de uso 1, 10, 12. H Debido a los elevados índices de descubrimiento de anomalías anteriores y de densidad de defectos, los casos de uso 1, 10 y 12 se consideran de alto riesgo.
Solicitudes de cambio en los casos de uso 14 y 19. H Un elevado número de cambios a estos casos de uso aumenta la probabilidad de inyectar defectos en el código.

Determinar el perfil operativo

El paso siguiente en la valoración del riesgo y el establecimiento de la prioridad de prueba es determinar el perfil operativo del destino de la prueba.

Empiece por la identificación y la descripción de los indicadores de magnitud de perfil operativo que se utilizarán, como por ejemplo:

  • H - se utiliza con mucha frecuencia, muchas veces por periodo o por muchos actores o casos de uso.
  • M - se utiliza con bastante frecuencia, varias veces por periodo o por varios actores o casos de uso.
  • L - se utiliza con poca frecuencia o por pocos actores o casos de uso.

El indicador del perfil operativo que seleccione debe basarse en la frecuencia de ejecución de un caso de uso o componente, incluyendo:

  • el número de veces que UN actor (o caso de uso) ejecuta el caso de uso (o componente) en un periodo determinado de tiempo
  • el número de ACTORES (o casos de uso) que ejecutan el caso de uso (o componente)

Habitualmente, cuanto más se utilice un caso de uso o componente, más elevado será el indicador de perfil operativo.

Después de identificar los indicadores de magnitud de perfil operativo, liste cada caso de uso o componente en el destino de la prueba. Determine un indicador de perfil operativo para cada elemento de la lista e indique una justificación para el valor del indicador. La información del documento de análisis de carga de trabajo (Consulte el apartado Producto de trabajo: Documento de análisis de carga de trabajo) se puede utilizar para esta valoración.

Ejemplos:

  • Instalación de nuevo software
  • Solicitud de elementos desde el catálogo en línea
  • Clientes que consultan sobre su pedido en línea después de efectuar el pedido
  • Diálogo de selección de elementos
Descripción Factor del perfil operativo Justificación
Instalación de nuevo software H Efectuado una vez (habitualmente), pero por muchos usuarios. Sin instalación, sin embargo, la aplicación no es utilizable.
Solicitud de elementos desde el catálogo H Este es el caso de uso más habitual ejecutado por los usuarios.
Clientes que consultan sobre pedidos L Pocos clientes consultan sobre sus pedidos después de haberlos efectuado
Diálogo de selección de elementos H Este diálogo los utilizan los clientes para enviar pedidos y los asistentes de inventario para reabastecer las existencias.

Establecer la prioridad de prueba

El último paso en la valoración del riesgo y el establecimiento de la prioridad de prueba es establecer la prioridad de prueba.

Empiece por la identificación y la descripción de los indicadores de magnitud de prioridad de prueba que se utilizarán, como por ejemplo:

  • H - se debe probar
  • M - se debe probar, se probará sólo después de que se prueben todos los elementos H
  • L - se puede probar, pero no hasta que todos los elementos H y M se hayan probado

Después de identificar los indicadores de magnitud de prioridad de prueba que se utilizarán, liste cada caso de uso o componente en el destino de la prueba. Determine un indicador de prioridad de prueba para cada elemento de la lista e indique su justificación. A continuación se muestran algunas directrices para determinar un indicador de prioridad de prueba.

Tenga en cuenta lo siguiente cuando determine los indicadores de prioridad de prueba para cada elemento:

  • el valor indicador de magnitud de riesgo que ha identificado anteriormente
  • el valor de magnitud de perfil operativo que ha identificado anteriormente
  • las descripciones de actor (¿los actores tienen experiencia?, ¿se toleran soluciones provisionales?, etc.)
  • obligaciones contractuales (¿será aceptable el destino de la prueba si el caso de uso o componente no se entrega?)

Las estrategias para establecer una prioridad de prueba incluyen:

  • Utilice el valor de factor valorado más alto (riesgo, perfil operativo, etc.) para cada elemento como prioridad global.
  • Identifique un factor valorado (riesgo, perfil operativo, otros) como el más significativo y utilice el valor de este factor como la prioridad.
  • Utilice una combinación de factores valorados para identificar la prioridad.
  • Utilice un esquema de ponderación donde los factores individuales se ponderan, y sus valores y la prioridad calculada basadas en la ponderación.

Ejemplos:

  • Instalación de nuevo software
  • Solicitud de elementos desde el catálogo en línea
  • Clientes que consultan sobre su pedido en línea después de efectuar el pedido
  • Diálogo de selección de elementos

La prioridad cuando el valor valorado más elevado se utiliza para determinar la prioridad:

Elemento Riesgo Perfil operativo Actor Contrato Prioridad
Instalación de nuevo software H H L H H
Solicitud de elementos desde el catálogo H H H H H
Consultas de los clientes L L L L L
Diálogo de selección de elementos L H L L H

La prioridad cuando el valor valorado más elevado para un factor (Riesgo) se utiliza para determinar la prioridad:

Elemento Riesgo Perfil operativo Actor Contrato Prioridad
Instalación de nuevo software H H L H H
Solicitud de elementos desde el catálogo H H H H H
Consultas de los clientes L L L L L
Diálogo de selección de elementos L H L L L

Prioridad cuando un valor de ponderación se utiliza para calcular la prioridad:

(Nota: en la matriz siguiente, H = 5, M = 3 y L = 1. Un valor ponderado total superior a 30 es de elemento de prueba de alta prioridad, valores entre 20 y 30 inclusive, son de prioridad media y valores inferiores a 20 son de baja prioridad).

Elemento Riesgo (x 3) Perfil operativo (x 2) Actor (x 1) Contrato (x 3) Valor ponderado Prioridad
Instalación de nuevo software 5 (15) 5 (10) 1 (1) 5 (15) 41 H (2)
Solicitud de elementos desde el catálogo 5 (15) 5 (10) 5 (5) 5 (15) 45 H (1)
Consultas de los clientes 1 (3) 1 (2) 1 (1) 1 (3) 9 L (4)
Diálogo de selección de elementos 1 (3) 5 (10) 1 (1) 1 (3) 17 L (3)

Estrategia de prueba

La estrategia de prueba describe el enfoque general y los objetivos de un esfuerzo de prueba específico.

Una buena estrategia de prueba debe contener lo siguiente:

Tipo de prueba y objetivo Ir a la parte superior de la página

Indicar claramente el tipo de prueba que se está implementando y el objetivo de la prueba. Indicando explícitamente esta información se reduce la confusión y se minimizan los malentendidos (especialmente porque algunas pruebas pueden resultar muy similares). El objetivo debe indicar claramente porqué la prueba se está ejecutando.

Ejemplos:

"Prueba funcional. La prueba funcional se centra en la ejecución de los casos de uso siguientes implementados en el destino de la prueba, de la interfaz de usuario."

"Prueba de rendimiento. La prueba de rendimiento para el sistema se centrará en la medida del tiempo de respuesta para los casos de uso 2, 4 y 8 - 10. Para estas pruebas, una carga de trabajo de un actor, ejecutando estos casos de uso sin utilizar ninguna otra carga de trabajo en el sistema de prueba."

"Prueba de configuración. Las pruebas de configuración se implementarán para identificar y evaluar el comportamiento del destino de la prueba en tres configuraciones diferentes, comparando las características de rendimiento para la configuración del estándar de comparación.

Estadio de prueba

Indique claramente el estadio en que se ejecutará la prueba. A continuación se identifican los estadios en que se ejecutan las pruebas habituales:

  Estadio de prueba
Tipo de pruebas Unidad Integración Sistema Aceptación
Pruebas funcionales

(Configuración, Función, Instalación, Seguridad, Volumen)

X X X X
Pruebas de rendimiento

(perfiles de rendimiento de componentes individuales)

X X (X)

opcional o cuando las pruebas de rendimiento del sistema descubren defectos

 
Pruebas de rendimiento

(Carga, Tensión, Contienda)

    X X
Fiabilidad

(Integridad, Estructura)

X X (X)

opcional o cuando otras pruebas descubren defectos

 

Técnica

La técnica debe describir cómo se implementará y se ejecutará la prueba. Incluya qué se probará, las acciones principales a desarrollar durante la ejecución de la prueba, y los métodos utilizados para evaluar los resultados.

Ejemplo:

Prueba funcional:

  • Para cada flujo de sucesos del caso de uso, se identificará un conjunto representativo de transacciones, cada una representando las acciones desempeñadas por el actor cuando se ejecuta el caso de uso.
  • Un mínimo de dos casos de prueba se desarrollarán para cada transacción; un caso de prueba para reflejar la condición positiva y una para reflejar la negativa (inaceptable).
  • En la primera iteración, los casos de uso 1 - 4, y 12 se probarán, del modo siguiente:
    • Caso de uso 1:
      • El caso de uso 1 empieza con el actor ya registrado en la aplicación y en la ventana principal, y termina cuando el usuario ha especificado GUARDAR.
      • Cada caso de prueba se implementará y ejecutará mediante Rational Robot.
      • La verificación y valoración de la ejecución de cada caso de prueba se realizará utilizando los métodos siguientes:
        • Ejecución del script de prueba (¿cada script de prueba se ha ejecutado satisfactoriamente y tal como se deseaba?)
        • La existencia de ventana, o métodos de verificación de datos de objeto (implementados en los scripts de prueba) se utilizarán para verificar qué ventanas clave se muestran y qué datos especificados se capturan / muestran en el destino de la prueba durante la ejecución de la prueba.
        • La base de datos destino de la prueba (con Microsoft Access) se examinará antes de la prueba y después de esta para verificar que los cambios que se han ejecutado durante la prueba se reflejan con precisión en los datos.

Prueba de rendimiento:

  • Para cada caso de uso, un conjunto representativo de transacciones, tal como se identifican en el documento de análisis de carga de trabajo se implementará y se ejecutará utilizando Rational Suite PerformanceStudio (vu scripts) y Rational Robot (scripts GUI).
  • Como mínimo tres cargas de trabajo se reflejarán en los scripts de prueba y las planificaciones de ejecución de prueba incluyendo lo siguiente:
    • Carga de trabajo destacada: 750 usuarios (15 % gestores, 50 % ventas, 35 % marketing)
    • Carga de trabajo punta: 350 usuarios (10 % gestores, 60 % ventas, 30 % marketing)
    • Carga de trabajo nominal: 150 usuarios (2 % gestores, 75% ventas, 23 % marketing)
  • Los scripts de prueba que se utilizan para ejecutar cada transacción incluirán los temporizadores apropiados para capturar los tiempos de respuesta, como tiempo de transacción total (tal como se define en el documento de análisis de carga de trabajo) y la tarea de transacción clave o los tiempos de proceso.
  • Los scripts de prueba ejecutarán las cargas de trabajo durante una hora (a menos que se indique lo contrario en el documento de análisis de carga de trabajo).
  • La verificación y valoración de la ejecución de cada ejecución de prueba (de una carga de trabajo) incluirá:
    • La ejecución de prueba se supervisará mediante histogramas de estado (para verificar que la prueba y las cargas de trabajo se están ejecutando según se esperaba y deseaba)
    • Ejecución del script de prueba (¿cada script de prueba se ha ejecutado satisfactoriamente y tal como se deseaba?)
    • Captura y evaluación de los tiempos de respuesta identificados utilizando los informes siguientes:
      • Percentil de rendimiento
      • Tiempo de respuesta


Criterios de terminación

Los criterios de terminación se indican con dos objetivos:

  • identificar la calidad aceptable del producto
  • identificar cuando se ha implementado satisfactoriamente el esfuerzo de prueba

Una sentencia clara de los criterios de terminación debe incluir los elementos siguientes:

  • función, comportamiento o condición que se mide
  • método de medición
  • criterios o grado de conformidad con las mediciones

Ejemplo 1

  • Todos los casos de prueba se han ejecutado
  • Todos los defectos identificados se han dirigido a una resolución acordada
  • Todos los casos de prueba planificados se han vuelto a ejecutar y todos los defectos conocidos se han solucionado según lo acordado, y no se han descubierto nuevos defectos

Ejemplo 2

  • Todos los casos de prueba de alta prioridad se han ejecutado.
  • Todos los defectos identificados se han dirigido a una resolución acordada.
  • Todos los defectos de Gravedad 1 ó 2 se han resuelto (estado = corregido o pospuesto).
  • Todos los casos de prueba de alta prioridad se han vuelto a ejecutar y todos los defectos conocidos se han solucionado según lo acordado, y no se han descubierto nuevos defectos.

Ejemplo 3

  • Todos los casos de prueba planificados se han ejecutado.
  • Todos los defectos identificados se han dirigido a una resolución acordada.
  • Todos los defectos de Gravedad 1 ó 2 se han resuelto (estado = verificado o pospuesto).
  • Todos los casos de prueba de alta prioridad se han vuelto a ejecutar y todos los defectos conocidos se han solucionado según lo acordado, y no se han descubierto nuevos defectos.

Consideraciones especiales

En esta sección se deben identificar las influencias o dependencias que pueden impactar o influenciar el esfuerzo de prueba descrito en la estrategia de prueba. Las influencias pueden incluir:

  • recursos humanos (como disponibilidad o necesidad de que los recursos que no son de prueba den soporte / participen en la prueba)
  • restricciones, (como limitaciones de equipamiento o disponibilidad, o la necesidad / falta de equipamiento especial)
  • requisitos especiales, como la planificación de prueba o el acceso a los sistemas

Ejemplos:

  • Las bases de datos de prueba requerirán el soporte de un diseñador / administrador de bases de datos para crear, actualizar y renovar los datos de prueba.
  • Las pruebas de rendimiento del sistema utilizará los servidores en la red existente (que da soporte al tráfico que no es de prueba). Las pruebas deberán planificarse posteriormente para garantizar que no hay tráfico que no sea de prueba en la red.
  • El destino de la prueba debe sincronizar el sistema heredado (o la sincronización simulada) para que se implemente y se ejecute la prueba funcional completa