Decida qué productos de trabajo utilizar y cómo utilizarlos de forma efectiva. En la tabla siguiente se describe qué
productos de trabajo recomendamos que utilice y cuáles puede tener en cuenta en contextos particulares. Para obtener
información más detallada sobre cómo personalizar cada producto de trabajo, y una discusión de las ventajas y
desventajas de este producto de trabajo específico, lea la sección titulada "Personalización" de cada producto de
trabajo.
Para cada producto de trabajo, decida cómo debe utilizarse el producto de trabajo:Debe tener, Debería tener, Puede
tener o No tendrá. Para obtener más detalles, consulte el apartado Técnica: Clasificación de productos de trabajo.
Producto de trabajo
|
Objetivo
|
Personalización (Opcional, recomendada)
|
Resumen de evaluación de prueba
|
Resume los resultados de la prueba que utiliza principalmente el equipo de gestión y otros interesados
externos del equipo de prueba.
|
Recomendada para la mayoría de proyectos.
Donde la cultura del proyecto es relativamente información, puede ser apropiado registrar los
resultados de prueba y no crear resúmenes de evaluación formales. En otros casos, los resúmenes de
evaluación de prueba se pueden incluir como sección dentro de otros productos de trabajo de valoración,
como la valoración de iteración o el registro de revisión.
|
Resultados de la prueba
|
Este producto de trabajo es el resultado analizado determinado a partir de los datos brutos de uno o
más registros de prueba.
|
Recomendado. La mayoría de equipos de prueba mantienen algún tipo de registro razonablemente detallado
de los resultados de las pruebas. Los resultados de las pruebas manuales habitualmente se registran
aquí directamente, y se combinan con los registros de prueba destilados a partir de las pruebas
automatizadas.
En algunos casos, los equipos de prueba irán directamente de los registros de prueba a producir el
Resumen de evaluación de prueba.
|
Registro de prueba
|
Los datos brutos obtenidos durante la prueba de ejecución, habitualmente producido por las pruebas
automatizadas.
|
Opcional.
Muchos proyectos que efectúan pruebas automatizadas tendrán alguna forma de registro de prueba. Los
proyectos difieren sobre si los registros de prueba se mantienen o se descartan después de que los
resultados de la prueba se hayan determinado.
Puede mantener registros de prueba si necesita satisfacer ciertos requisitos de auditoría, si desea
llevar a cabo el análisis sobre cómo cambian con el tiempo los datos de prueba brutos resultantes o
si no está seguro de qué principio de todos los análisis es necesario que proporcione.
|
Conjunto de aplicaciones de prueba
|
Se utiliza para agrupar pruebas individuales relacionadas (script de prueba) en subconjuntos
significativos.
|
Recomendado para la mayoría de proyectos.
También es necesario para definir las secuencias de ejecución de scripts de prueba que sean necesarios
para que las pruebas funcionen correctamente.
|
Lista de ideas de prueba
|
Es una lista enumerada de ideas, a menudo parcialmente formada, que deben tenerse en cuenta como
pruebas útiles de desarrollar.
|
Recomendado para la mayoría de proyectos.
En algunos casos, estas listas se definirán y descartarán informalmente una vez que se hayan definido
scripts de prueba o guiones de prueba para ellos.
|
Estrategia de prueba
|
Define el plan estratégico sobre cómo se efectuará el esfuerzo de prueba contra uno o más aspectos de
los sistemas de destino.
|
Recomendado para la mayoría de proyectos.
En la mayoría de casos se recomienda una única estrategia de prueba por proyecto o por fase dentro de
un proyecto. De forma opcional, puede reutilizar las estrategias existentes cuando sea apropiado, o
puede volver a subdividir las estrategias de prueba basadas en el tipo de prueba que se realiza.
|
Plan de prueba
|
Define objetivos de prueba más detallados, motivaciones, enfoques, recursos, planificación y
entregables que gobiernan una iteración.
|
Recomendado para la mayoría de proyectos.
Se recomienda un plan de prueba separado por iteración para definir la estrategia de prueba específica
y de gran granularidad. De forma opcional, puede incluir el plan de prueba como sección dentro del plan de iteración.
|
Plan de prueba
|
Define objetivos de prueba de alto nivel, objetivos, enfoques, recursos, planificación y entregables
que gobiernan una fase o todo el ciclo vital.
|
Opcional. Útil para la mayoría de proyectos.
Un plan de prueba maestro define la estrategia de alto nivel de esfuerzo de prueba sobre grandes
partes del ciclo de vida de desarrollo del software. De forma opcional, puede incluir el plan de prueba
como sección dentro del plan de desarrollo de software.
Considere la opción de mantener un plan de prueba "Maestro" además de los planes de prueba de
"Iteración". El plan de prueba maestro cubre principalmente la información de actuación logística y de
proceso que habitualmente está relacionada con todo el ciclo de vida del proyecto y que, por lo tanto,
no es probable que cambie entre las iteraciones.
|
Script de prueba, Datos de prueba
|
Los script de prueba y los datos de prueba son la realización o implementación de la prueba, donde el
script de prueba representa los aspectos de procedimiento, y los datos de prueba las características de
definición.
|
Recomendado para la mayoría de proyectos.
Los proyectos suelen diferir en cómo se tratan formalmente estos productos de trabajo. En algunos
casos, estos son informales y transitorios y el equipo de prueba se juzga basándose en otros criterios.
En otros casos, especialmente con pruebas automatizadas, los scripts de prueba y los datos de prueba
asociados (o alguno de sus subconjuntos) se consideran entregables importantes del esfuerzo de prueba.
|
Guión de prueba
|
Define un conjunto específico de entradas de prueba, condiciones de ejecución, y resultados
esperados.
La documentación de guiones de prueba permite revisar si están completados y son correctos, y
considerarlos antes de planificar y gastar el esfuerzo de implementación.
Esto resulta muy útil donde la entrada, las condiciones de ejecución y los resultados esperados son
especialmente complejos.
|
Recomendamos que en la mayoría de proyectos, donde las condiciones necesarias para desarrollar
pruebas específicas sean complejas o extensivas, defina guiones de prueba. También necesitará
documentar guiones de prueba donde sean un entregable necesario contractualmente.
En la mayoría de otros casos recomendamos mantener la lista de ideas de prueba y los scripts de
prueba implementados en lugar de guiones de prueba textuales detallados.
Algunos proyectos simplemente destacan guiones de prueba en un alto nivel y transfieren detalles a
los scripts de prueba. Otro estilo que suele utilizarse es documentar la información de guión de
prueba como comentarios dentro de los scripts de prueba.
|
Modelo de análisis de carga de trabajo
|
Un tipo especializado de guión de prueba. Se utiliza para definir una carga de trabajo
representativa para permitir los riesgos de calidad asociados con el sistema que operan debajo de
la carga que se valora.
|
Recomendado para la mayoría de sistemas, especialmente aquellos en que debe valorarse el
rendimiento del sistema bajo una carga, o donde existen otros riesgos de calidad significativos
asociados con la operación del sistema bajo carga.
No suele ser necesario para sistemas que se desplegarán en un sistema de destino autónomo.
|
Clases de comprobabilidad en el modelo de diseño
Elementos de comprobabilidad en el modelo de
implementación
|
Si el proyecto debe desarrollar un comportamiento adicional especializado significativo para
acomodar y dar soporte a las pruebas, estas preocupaciones se representan con la inclusión de las
clases de comprobabilidad en el modelo de diseño y los elementos de comprobabilidad en el modelo de
implementación.
|
Donde sea necesario.
Fragmentos para simulación son una categoría común de las clases
de prueba y los componentes de prueba.
|
Arquitectura de automatización de pruebas
|
Proporciona una visión general arquitectónica del sistema de automatización de pruebas, mediante
una serie de vistas arquitectónicas diferentes para representar diferentes aspectos del sistema.
|
Opcional.
Recomendado para proyectos donde la arquitectura de prueba es relativamente compleja, cuando un
número elevado de personas colaborará en las pruebas de construcción automatizada, o cuando se
espera mantener el sistema de automatización de prueba durante un periodo de tiempo prolongado.
En algunos casos puede ser, sencillamente, un diagrama en la pizarra que se registre centralmente
para que los consulten las partes interesadas.
|
Especificación de la interfaz de prueba
|
Define un conjunto necesario de comportamientos por parte de un clasificador (específicamente, una
clase, subsistema o componente) con el objetivo de las pruebas (comprobabilidad). Los tipos comunes
incluyen acceso de prueba, comportamiento fragmentado, registro de diagnóstico y oráculos de
prueba.
|
Opcional.
En muchos proyectos, hay suficiente accesibilidad para probar en las operaciones visibles de las
clases, interfaces de usuario, etc.
Algunos motivos comunes para crear especificaciones de la interfaz de prueba incluyen las
ampliaciones de la UI para permitir que las herramientas de prueba de la GUI interactúen con las
rutinas de herramientas y registro de mensajes de diagnóstico, especialmente para procesos por
lotes.
|
Personalice cada producto de trabajo para que se adecue a las necesidades del proyecto. Para consideraciones sobre la
personalización, consulte el apartado de Personalización de la página de descripción de los productos de trabajo, o los
pasos descritos debajo del título "Personalizar productos de trabajo por disciplina" en Tarea: Desarrollar guión de desarrollo.
En esta sección se proporcionan algunas directrices que le ayudarán a decidir cómo debe revisar los productos de
trabajo de prueba. Para obtener orientaciones generales, consulte el apartado Directriz: Niveles
de revisión.
Defectos
El tratamiento de las revisiones de defecto depende mucho del contexto pero, sin embargo, se trata generalmente como
Informal, Formal-Interno o Formal-Externo. Este proceso de revisión suele forzarse o como mínimo
asistirse con la gestión de flujo de trabajo en un sistema de seguimiento de defectos. Como comentario general, el
nivel de formalidad de la revisión suele estar relacionado con la gravedad percibida o el impacto del defecto; sin
embargo, factores como la cultura del proyecto y el nivel de ceremonia a menudo tienen efecto en la elección de la
gestión de la revisión.
En algunos casos es posible que deba considerar la separación de la gestión de los defectos, que también se conocen
como síntomas o errores- de anomalías; el origen real del error. Para proyectos pequeños, puede gestionar supervisando
únicamente los defectos y gestionando implícitamente los errores. Sin embargo, a medida que crece la complejidad del
sistema, puede resultar beneficioso separar la gestión de los defectos de los errores. Por ejemplo, muchos defectos
pueden ser producidos por el mismo error. Por lo tanto, si se soluciona un error, es necesario encontrar los defectos
reportados e informar a los usuarios que enviaron los defectos, lo que sólo es posible si los defectos y errores se
pueden identificar separadamente.
Plan de prueba y Estrategia de prueba
En cualquier proyecto en que las pruebas no sean triviales, necesitará alguna forma de plan de prueba o estrategia.
Generalmente necesitará un plan de prueba para cada iteración y alguna forma de gobierno de la estrategia de prueba.
Opcionalmente, puede crear y mantener un plan de prueba maestro. En muchos casos, estos productos de trabajo se revisan
como Informales; es decir, se revisan, pero no se aprueban formalmente. Donde la visibilidad de la prueba tiene
importancia para los interesados externos del equipo de prueba, debe probarse como Formal-Interno o incluso
Formal-Externo.
Scripts de prueba
Los scripts de prueba Test se tratan habitualmente como Informales; es decir, los aprueba alguien del equipo de
prueba. Si muchos verificadores deben utilizar los scripts de prueba, y los deben compartir o reutilizar para muchas
pruebas diferentes, deben tratarse como Formal-Interno.
Guiones de prueba
Los guiones de prueba los crea el equipo de prueba y, dependiendo del contexto, se revisan habitualmente utilizando un
proceso Informal o simplemente no revisándolos. Cuando corresponda, los guiones de prueba los aprobarán otros
miembros del equipo en cuyo caso se pueden tratar como Formal-Interno, o los interesados externos en cuyo caso
serían Formal-Externo.
Como norma general, le recomendamos que planee revisar formalmente qué guiones de prueba son necesarios, que
generalmente se limitarán a un pequeño subconjunto que representa los guiones de prueba más significativos. Por
ejemplo, cuando un cliente desee validar un producto antes de que se lance al mercado, puede seleccionarse algún
subconjunto de guiones de prueba como base para esta validación. Estos guiones de prueba deben tratarse como
Formal-Externo.
Productos de trabajo de prueba en diseño e implementación
Las clases de comprobabilidad se encuentran en el modelo de diseño, y los elementos de comprobabilidad en el modelo de
implementación. También existen otros dos productos de trabajo relacionados (aunque no son específicos de la prueba):
Paquetes en el modelo de diseño, y subsistemas en el modelo de implementación.
Estos productos de trabajo son productos de trabajo de diseño e implementación, aunque se crean con el objetivo de
proporcionar soporte a las pruebas de funcionalidad del software. El lugar natural donde mantenerlos es con los
productos de trabajo de diseño e implementación. Recuerde que debe nombrarlas o etiquetarlas de modo que estén
claramente separadas del diseño y la implementación del sistema central. Revise estos productos de trabajo siguiendo
los procedimientos de revisión para los productos de trabajo de diseño e implementación.
A medida que entre cada iteración, esfuércese para definir clara y directamente cómo se juzgará el esfuerzo de prueba
para ser suficiente, y sobre que base se medirá ese juicio. Hágalo discutiendo con la persona o grupo responsable de
tomar la decisión de aprobación.
A continuación se muestran ejemplos de modos de gestionar la aprobación de la iteración:
-
El equipo de gestión del proyecto aprueba la iteración y valora el esfuerzo de prueba revisando los resúmenes de
evaluación de prueba.
-
El cliente aprueba la iteración revisando los resúmenes de evaluación de prueba.
-
El cliente aprueba la iteración basada en los resultados de una demostración que ejerce un cierto subconjunto de
las pruebas totales. Este subconjunto de pruebas debe definirse y acordarse con anterioridad, preferiblemente en un
estadio temprano de la iteración. Estas pruebas se tratan como Formal-Externo y se les suele hacer
referencia como pruebas de aceptación.
-
El cliente aprueba la calidad del sistema realizando sus propias pruebas independientes. Una vez más, la naturaleza
de estas pruebas debe definirse y acordarse con anterioridad, preferiblemente en un estadio temprano de la
iteración. Estas pruebas se tratan como Formal-Externo y se les suele hacer referencia como pruebas de
aceptación.
Esta decisión es importante. No puede alcanzar un objetivo si no sabe qué es.
|