Actividad: Verificar el enfoque de prueba
Esta actividad demuestra que las diversas técnicas esbozadas en el enfoque de prueba facilitará el esfuerzo de prueba planificado. La idea es verificar mediante demostración que el enfoque va a funcionará, producirá resultados precisos y será adecuado para los recursos disponibles.
DescripciónEstructura de desglose de trabajoAsignación de equiposUtilización del producto de trabajo
Relaciones
Actividades principales
Descripción

El objetivo es obtener una comprensión sólida de las restricciones y limitaciones de cada técnica ya que se aplicará en el contexto del proyecto en concreto y para una de las dos funciones siguientes:

  • buscar una solución de implementación adecuada para cada técnica
  • buscar técnicas alternativas que pueden utilizarse.

De esta forma se mitiga el riesgo de descubrir demasiado tarde en el ciclo vital del proyecto que el enfoque de la prueba es imposible de llevar a cabo.
Para cada iteración, este trabajo se centra fundamentalmente en:

  • Una verificación inicial de que la estrategia de prueba que se pretende va a poderse realizar y que produce resultados de algún valor
  • Establecer la infraestructura básica para habilitar y dar soporte a la estrategia de prueba
  • Obtener el compromiso del equipo de desarrollo de que desarrollarán el software de forma que cumpla con los requisitos de comprobabilidad necesarios para alcanzar la estrategia de prueba, y para proporcionar un soporte continuado de los requisitos de comprobabilidad.
  • Identificar el ámbito, los límites, las limitaciones y las restricciones de cada técnica
Propiedades
Condicionado por sucesos
Varias apariciones
Continuo
Opcional
PlaneadoYes
Se puede repetir
Personal

Aunque la mayoría de roles implicados en la disciplina de prueba desempeñan un papel en la realización de este trabajo, el esfuerzo se centra fundamentalmente en torno a los roles de diseñador de pruebas y de verificador. Las áreas más importantes de habilidades se necesitan para este trabajo incluyen arquitectura de software, diseño de software y resolución de problemas.

Es habitual que este trabajo precise más recursos en las iteraciones del final de la fase inicial y del principio de las fases de construcción, y que sólo precise unos recursos mínimos al final de las fases de construcción y de transición. Sin embargo, tenga en cuenta que a medida que el proyecto progresa, pueden identificarse nuevos objetivos o entregables que precisen nuevas estrategias de prueba que deban definirse y verificarse.

Como heurística para la asignación de recursos relativos por fase, los porcentajes habituales del uso de recursos de prueba para esta actividad son: principio: 30%, elaboración: 20%, construcción: 10% y transición: 05%.

Utilización
Instrucciones de utilización

Esta actividad se inicia al principio de cada iteración, tan pronto como se alcanza el acuerdo suficiente sobre la misión para la iteración, y sigue según se necesita durante la iteración. Se utiliza más frecuentemente en las primeras fases de la fase inicial, la elaboración y al principio de la construcción, desapareciendo normalmente a finales de la fase de construcción y de transición.

Esta actividad se considera opcional cuando el método de prueba es muy conocido, y su posibilidad de aplicación en el contexto actual está bien establecida.

Este trabajo es de algún modo independiente de los ciclos de pruebas y, a menudo, incluye la verificación de técnicas que no se utilizarán hasta iteraciones posteriores. Este trabajo normalmente empieza cuando se ha definido la misión de evaluación para la iteración actual, aunque puede empezar antes. En algunos casos, para encontrar el mejor método de implementación a una técnica pueden ser necesarias varias iteraciones.

Las actividades de implementación y ejecución de pruebas que forman parte de este trabajo se llevan a cabo para obtener pruebas demostrables que las técnicas que se están verificando pueden funcionar realmente. Como tal, debería limitar su selección de pruebas a un subconjunto pequeño y representativo, centrándose normalmente en áreas con un riesgo significativo para la calidad. Debería intentar incluir una selección de pruebas que espera que fallen para confirmar que la técnica detectará correctamente estos fallos.

Aunque se identificarán las anomalías de los elementos de prueba de destino y se registrarán convenientemente estos incidentes, este trabajo no se centra directamente en intentar identificar anomalías en los elementos de prueba de destino como objetivo principal. Nuevamente, el objetivo es verificar que el enfoque es adecuado (produce resultados que complementan los objetivos de la iteración), que es alcanzable (que se puede implementar con las restricciones de recursos existentes) y que funcionará.

Para que este trabajo produzca los resultados oportunos, a menudo es necesario utilizar compilaciones "no oficiales" incompletas, o bien realizar este trabajo fuera de una configuración de entorno de pruebas reconocida. Aunque estos son compromisos adecuados, tenga en cuenta las restricciones, las presuposiciones y los riesgos implicados al verificar su perspectiva bajo estas condiciones.

A medida que el ciclo vital avanza a través de sus distintas fases, el enfoque del esfuerzo de prueba normalmente cambia. Potencialmente, se hace necesario utilizar perspectivas nuevas o adicionales, que a menudo requieren la introducción de nuevos tipos de pruebas o nuevas técnicas para apoyar al esfuerzo de prueba.

En situaciones en las que la combinación del dominio, el entorno de prueba y otros aspectos fundamentales de la estrategia no tienen precedentes, debería dejar más tiempo y esfuerzo para completar este trabajo. En algunos casos, especialmente cuando la automatización es un requisito, puede ser más económico poder contar con de recursos con habilidades especializadas que tengan una experiencia probada en los aspectos sin precedentes de la estrategia durante un período de tiempo limitado (como un contrato) para definir y verificar las necesidades técnicas clave de la estrategia de prueba.

Más información