Historial de Cambios de Documentos

Traducido del inglés al español - www.onlinedoctranslator.
com
<<NOMBRE DEL PROYECTO-

NOMBRE DE LA
INSTITUCIÓN>>
Plan de prueba
Historial de cambios de documentos
Número de versión Fecha Contribuyente Descripción
V1.0 ¿Qué cambios (adiciones y

eliminaciones) se realizaron
para esta versión?
** Nota para el autor del documento –REl texto rojo y azul (con la excepción del título y el nombre del
documento anteriores) de este documento está dirigido al usuario de la plantilla para describir procesos, crear
estándares y ayudar a crear el documento a partir de la plantilla. Todo ese texto rojo y azul debe eliminarse antes de
enviar cualquier documentación formal, incluidos los entregables borradores y/o finales. ****
<<Documento del plan de prueba-SOW#opcional>>
Tabla de contenido
1. INTRODUCCIÓN....................................................................................................................................................3
1.1 ALCANCE...............................................................................................................................................................3
1.1.1 Alcance..........................................................................................................................................................3
1.1.2 Fuera de alcance...........................................................................................................................................3
1.2 OBJETIVO DE CALIDAD..........................................................................................................................................3
1.2.1 Objetivo principal..........................................................................................................................................3
1.2.2 Objetivo secundario.......................................................................................................................................4
1.3 FUNCIONES Y RESPONSABILIDADES......................................................................................................................4
1.3.1 Desarrollador................................................................................................................................................4
1.3.2 Adoptante.......................................................................................................................................................4
1.3.3 Equipo de gestión del proceso de prueba......................................................................................................4
1.4 SUPUESTOS PARA LA EJECUCIÓN DE LA PRUEBA...................................................................................................5
1.5 RESTRICCIONES PARA LA EJECUCIÓN DE LA PRUEBA............................................................................................5
1.6 DEFINICIONES........................................................................................................................................................6
2 METODOLOGÍA DE PRUEBA..............................................................................................................................6
2.1 PROPÓSITO.............................................................................................................................................................6
2.1.1 Descripción general.......................................................................................................................................6
2.1.2 Pruebas de usabilidad...................................................................................................................................6
2.1.3 Pruebas unitarias (múltiples)........................................................................................................................7
2.1.4 Pruebas de iteración/regresión.....................................................................................................................7
2.1.5 Pruebas de lanzamiento final........................................................................................................................7
2.1.6 Criterios de integridad de la prueba.............................................................................................................8
2.2 NIVELES DE PRUEBA..............................................................................................................................................8
2.2.1 Pruebas de compilación................................................................................................................................8
2.2.1.1 Nivel 1: Pruebas de aceptación de compilación.........................................................................................................8
2.2.1.2 Nivel 2: Pruebas de humo...........................................................................................................................................8
2.2.1.3 Nivel 2a: Prueba de regresión de errores....................................................................................................................8
2.2.2 Pruebas de hitos............................................................................................................................................8
2.2.2.1 Nivel 3: Pruebas de ruta crítica...................................................................................................................................8
2.2.3 Pruebas de lanzamiento.................................................................................................................................9
2.2.3.1 Nivel 4 - Pruebas estándar..........................................................................................................................................9
2.2.3.2 Nivel 5 - Prueba sugerida...........................................................................................................................................9
2.3 REGRESIÓN DE ERRORES........................................................................................................................................9
2.4 CLASIFICACIÓN DE ERRORES.................................................................................................................................9
2.5 CRITERIOS DE SUSPENSIÓN Y REQUISITOS DE REANUDACIÓN.............................................................................10
2.6 COMPLETITUD DE LA PRUEBA.............................................................................................................................10
2.6.1 Condiciones estándar:.................................................................................................................................10
2.6.2 Condiciones de clasificación y notificación de errores:.............................................................................10
3 ENTREGABLES DE PRUEBA..............................................................................................................................10
3.1 MATRIZ DE ENTREGABLES...................................................................................................................................11
3.2 DOCUMENTOS......................................................................................................................................................12
3.2.1 Documento de enfoque de prueba...............................................................................................................12
3.2.2 Plan de prueba.............................................................................................................................................12
3.2.3 Calendario de pruebas................................................................................................................................12
3.2.4 Especificaciones de prueba.........................................................................................................................13
3.2.5 Matriz de Trazabilidad de Requisitos..........................................................................................................13
3.3 SEGUIMIENTO Y DEPURACIÓN DE DEFECTOS.......................................................................................................13
3.3.1 Flujo de trabajo de prueba..........................................................................................................................13
3.3.2 Informe de defectos utilizando G FORGE...................................................................................................14
3.4 INFORMES.................................................................................................................................................DIECISÉIS
3.4.1 Informes de estado de las pruebas.....................................................................................................dieciséis
1
3.4.2 Informes de finalización de fase........................................................................................................dieciséis

3.4.3 Informe final de prueba: aprobación.................................................................................................dieciséis
3.5 MATRIZ DE RESPONSABILIDAD................................................................................................................ DIECISÉIS
4 NECESIDADES DE RECURSOS Y MEDIO AMBIENTE................................................................DIECISÉIS
4.1 HERRAMIENTAS DE PRUEBA.....................................................................................................................DIECISÉIS
4.1.1 Herramientas de seguimiento............................................................................................................dieciséis
4.1.1.1 Gestión de configuración..........................................................................................................................................17
4.2 ENTORNO DE PRUEBA..........................................................................................................................................17
4.2.1 Hardware.....................................................................................................................................................17
4.2.2 Software.......................................................................................................................................................17
4.3 DEFINICIÓN DE GRAVEDAD Y PRIORIDAD DE ERRORES.......................................................................................17
4.3.1 Lista de gravedad........................................................................................................................................17
4.3.2 Lista de prioridades.....................................................................................................................................18
4.4 INFORME DE ERRORES.........................................................................................................................................18
5 TÉRMINOS/ACRÓNIMOS...................................................................................................................................18
2
1 Introducción
Este documento de enfoque de prueba describe las estrategias, procesos, flujos de trabajo y
metodologías apropiados utilizados para planificar, organizar, ejecutar y gestionar pruebas de
proyectos de software dentro de caBIG.
1.1 Alcance
Describa el alcance del enfoque de prueba actual según su función y los objetivos del proyecto.
1.1.1 En alcance
ElEl plan de prueba de caBIG <nombre del espacio de trabajo> <nombre del sistema> define el
enfoque de prueba de unidad, integración, sistema, regresión y aceptación del cliente. El
alcance de la prueba incluye lo siguiente:
 Prueba de todos los requisitos funcionales, de rendimiento de
aplicaciones, de seguridad y de casos de uso enumerados en el
documento de casos de uso.
 Requisitos de calidad y métricas de ajuste<nombre del sistema>.
 Pruebas de extremo a extremo y pruebas de interfaces de todos los
sistemas que interactúan con el <nombre del sistema>.
1.1.2 Fuera del ámbito

Lo siguiente se considera fuera del alcance del plan de prueba del sistema caBIG <nombre del
espacio de trabajo> <nombre del sistema> y del alcance de la prueba:
 Pruebas de requisitos funcionales para sistemas fuera de <nombre
de la aplicación>
 Pruebas de SOP de Negocio, recuperación ante desastres y Plan de
Continuidad de Negocio.
1.2 Objetivo de calidad
1.2.1 Objetivo primario

Un objetivo principal de probar los sistemas de aplicaciones es: asegurar que el sistema
cumpla con todos los requisitos, incluidos los requisitos de calidad (también conocidos como
requisitos no funcionales) y ajustar las métricas para cada requisito de calidad y satisfacer los
escenarios de casos de uso y mantener la calidad del producto. . Al final del ciclo de desarrollo
del proyecto, el usuario debe encontrar que el proyecto ha cumplido o superado todas sus
expectativas como se detalla en los requisitos.
Cualquier cambio, adición o eliminación al documento de requisitos, especificación funcional o

especificación de diseño se documentará y probará al más alto nivel de calidad permitido
dentro del tiempo restante del proyecto y dentro de la capacidad del equipo de prueba.
3
1.2.2 Objetivo secundario

El objetivo secundario de probar los sistemas de aplicaciones será: identificar y exponer todos
los problemas y riesgos asociados, comunicar todos los problemas conocidos al equipo del
proyecto y garantizar que todos los problemas se aborden de manera adecuada antes de su
lanzamiento. Como objetivo, esto requiere pruebas cuidadosas y metódicas de la aplicación
para garantizar primero que todas las áreas del sistema sean analizadas y, en consecuencia,
que todos los problemas (errores) encontrados se traten adecuadamente.

1.3 Funciones y responsabilidades

Las funciones y responsabilidades pueden diferir según la SOW real. Las funciones
enumeradas a continuación son para la fase de prueba.
1.3.1 Desarrollador
Un centro oncológico designado por el NCI seleccionado y financiado por el NCICB para
participar en un espacio de trabajo específico para llevar a cabo actividades de desarrollo de
soluciones o software. Responsable de:
(a) Desarrollar el sistema/aplicación

(b) Desarrollar casos de uso y requisitos en colaboración con los adoptantes.
(c) Realizar pruebas de unidad, sistema, regresión e integración.
(d) Apoyar las pruebas de aceptación del usuario.
1.3.2 Adoptante
Un centro oncológico designado por el NCI seleccionado y financiado por el NCICB para llevar
a cabo la adopción, prueba, validación y aplicación formal de productos o soluciones
desarrollados por Workspace Developers. Responsable de:
(a) Contribuir al caso de uso, desarrollo de requisitos a través de la revisión.

(b) Contribuir al desarrollo y ejecución de los scripts de prueba de desarrollo
mediante revisión.
(c) Realizar pruebas de aceptación total del usuario, regresión y de un extremo a
otro; esto incluye identificar escenarios de prueba, crear scripts de prueba,
ejecutar scripts e informar los resultados de las pruebas.
1.3.3 Equipo de gestión de procesos de prueba

Incluya los líderes del NCI, BAH y del centro oncológico asignados al <nombre del espacio de
trabajo>. Grupo responsable de gestionar todo el proceso de pruebas, flujo de trabajo y gestión
de calidad con actividades y responsabilidades para:
(a) Supervisar y gestionar la integridad de las pruebas y respaldar las

actividades de prueba.
(b) Coordinar actividades entre los centros oncológicos.
4
Agregue más según corresponda al alcance de la prueba
1.4 Supuestos para la ejecución de la prueba
A continuación se muestran algunos supuestos mínimos (en negro) que se han completado con
algunos ejemplos (en rojo). Se puede utilizar cualquier ejemplo si se considera apropiado para
el proyecto en particular. También podrán añadirse nuevos supuestos que se razonan como
adecuados al proyecto.
 Para las pruebas de aceptación del usuario, el equipo de
desarrolladores completó las pruebas de unidad, sistema e
integración y cumplió con todos los requisitos (incluidos los requisitos
de calidad) según la Matriz de trazabilidad de requisitos.
 Las pruebas de aceptación del usuario serán realizadas por los
usuarios finales.
 Los resultados de las pruebas se informarán diariamente utilizando
Gforge. Los scripts fallidos y la lista de defectos de Gforge con
evidencia se enviarán directamente al desarrollador.
 Los adoptantes han desarrollado casos de uso para las pruebas de
aceptación del usuario. Los casos de uso son aprobados por el líder
de prueba.
 Los guiones de prueba se desarrollan y aprueban.
 El equipo de pruebas apoyará y proporcionará orientación adecuada
a los adoptantes y desarrolladores para realizar pruebas.
 Las dependencias importantes deben informarse inmediatamente
después de la reunión de inicio de las pruebas.
1.5 Restricciones para la ejecución de pruebas

A continuación se muestran algunos supuestos mínimos (en negro) seguidos de restricciones
de ejemplo (rojo). Se puede utilizar cualquier ejemplo si se considera apropiado para el
proyecto en particular. También se pueden agregar nuevas restricciones que se consideren
adecuadas para el proyecto.
 Los adoptantes deben comprender claramente los procedimientos de
prueba y el registro de un defecto o mejora. El equipo de gestión del
proceso de pruebas programará una teleconferencia con los
desarrolladores y adoptantes para capacitar y abordar cualquier
problema relacionado con las pruebas.
 El desarrollador recibirá una lista consolidada de solicitudes para la
configuración del entorno de prueba, configuración de cuentas de
usuario, conjunto de datos (datos reales y simulados), lista de
defectos, etc. a través de GForge después de la reunión inicial de
inicio de la prueba de Adopter.
 El desarrollador apoyará las actividades de prueba en curso según
las prioridades.
5

 Los scripts de prueba deben ser aprobados por el líder de pruebas
antes de la ejecución de la prueba.
 Los scripts de prueba, el entorno de prueba y las dependencias
deben abordarse durante la reunión inicial de la prueba en presencia
de una PYME y la lista de solicitudes debe enviarse dentro de los 3
días posteriores a la reunión inicial.
 El Desarrollador no puede ejecutar los scripts de aceptación del
usuario y de prueba de extremo a extremo. Después de la
depuración, el desarrollador puede realizar su prueba interna, pero no
se pueden registrar ni informar resultados de esa prueba.
 Los adoptantes son responsables de identificar las dependencias
entre los scripts de prueba y enviar una solicitud clara para configurar
el entorno de prueba.
1.6 Definiciones
Errores: cualquier error o defecto que provoque un mal funcionamiento del software/aplicación
o hardware. Eso también está incluido en los requisitos y no cumple con el flujo de trabajo,
proceso o punto de función requerido.
Mejora:
1) Cualquier alteración o modificación del sistema existente para un mejor flujo de trabajo y
proceso.
2) Un error o defecto que provoca un mal funcionamiento del software/aplicación o hardware.
Cuando 1) y 2) NO están incluidos en los requisitos, se pueden clasificar como una mejora.
La mejora se puede agregar como un nuevo requisito después del proceso de gestión de
cambios adecuado.
2 Metodología de prueba
2.1 Objetivo
2.1.1 Descripción general

La siguiente lista no pretende limitar el alcance del plan de prueba y puede modificarse para
que sea adecuada para el proyecto en particular.
El propósito del Plan de Pruebas es lograr lo siguiente:

 Definir estrategias de prueba para cada área y subárea para incluir todos los requisitos
funcionales y de calidad (no funcionales).
6
 Divida las especificaciones de diseño en áreas y subáreas comprobables (no las confunda
con especificaciones de prueba más detalladas). Asegúrese también de identificar e incluir
áreas que también se omitirán (no se probarán).
 Definir procedimientos de seguimiento de errores.
 Identificar los riesgos de las pruebas.
 Identificar los recursos necesarios y la información relacionada.
 Proporcionar cronograma de pruebas.
2.1.2 Pruebas de usabilidad

<
2.1.3 Pruebas unitarias (múltiples)

El desarrollador realiza las pruebas unitarias durante el proceso de desarrollo del código para
garantizar que cada desarrollador haya logrado la funcionalidad y la cobertura del código
adecuadas, tanto durante la codificación como en preparación para la aceptación en las
pruebas de iteraciones.
Las siguientes son áreas de ejemplo del proyecto que deben probarse unitariamente y
aprobarse antes de pasar a las pruebas de regresión:
 Bases de datos, procedimientos almacenados, desencadenadores, tablas e índices
 Servicios NT
 Conversión de base de datos
 .OCX, .DLL, .EXE y otros ejecutables con formato binario
2.1.4 Pruebas de iteración/regresión

Durante los ciclos repetidos de identificación de errores y recepción de nuevas compilaciones
(que contienen cambios en el código de corrección de errores), hay varios procesos que son
comunes a esta fase en todos los proyectos. Estos incluyen los distintos tipos de pruebas:
funcionalidad, rendimiento, estrés, configuración, etc. También existe el proceso de comunicar
los resultados de las pruebas y garantizar que las nuevas caídas/iteraciones contengan
correcciones estables (regresión). El proyecto debe planificar un mínimo de 2 o 3 ciclos de
pruebas (caídas/iteraciones de nuevas construcciones).
En cada iteración, se debe realizar una sesión informativa. Específicamente, el informe debe
mostrar que, en el mejor grado posible durante la fase de prueba de iteración, se han
comunicado y solucionado todos los errores identificados de gravedad 1 y gravedad 2. Como
mínimo, todos los errores de prioridad 1 y 2 deben resolverse antes de ingresar a la fase beta.
A continuación se muestran ejemplos. Se puede utilizar cualquier ejemplo si se considera

apropiado para el proyecto en particular. También se podrán añadir nuevos contenidos que se
consideren adecuados al proyecto.
Los entregables importantes requeridos para la aceptación en las pruebas de la versión final
incluyen:
 Aplicación SETUP.EXE
 Instrucciones de instalación
 Toda la documentación (guiones de prueba beta, manuales o guías de formación, etc.)
7
2.1.5 Pruebas de lanzamiento final

El equipo de pruebas con los usuarios finales también participa en este proceso importante
proporcionando comentarios de confirmación sobre nuevos problemas descubiertos y
comentarios basados en problemas idénticos o similares detectados anteriormente. La
intención es verificar que el producto esté listo para su distribución, sea aceptable para el
cliente y solucione posibles problemas operativos.
Suponiendo que los errores críticos se resuelvan durante las pruebas de iteraciones anteriores:
durante todo el ciclo de prueba de la versión final, las correcciones de errores se centrarán en
errores menores y triviales (gravedad 3 y 4). Las pruebas continuarán con su proceso de
verificar la estabilidad de la aplicación mediante pruebas de regresión (errores conocidos
existentes, así como casos de prueba existentes).
El objetivo de esta fase es establecer que la aplicación bajo prueba haya alcanzado un nivel de
estabilidad, apropiado para su uso (número de usuarios, etc.), que pueda ser lanzada a los
usuarios finales y a la comunidad caBIG.
2.1.6 Criterios de integridad de la prueba

El lanzamiento para producción puede ocurrir solo después de la finalización exitosa de la
aplicación bajo prueba en todas las fases e hitos discutidos anteriormente.
El objetivo del hito es colocar la versión/aplicación (compilación) en producción después de que

se haya demostrado que la aplicación ha alcanzado un nivel de estabilidad que cumple o
supera las expectativas del cliente según lo definido en los Requisitos, Especificaciones
funcionales y Estándares de producción de caBIG. .
2.2 Niveles de prueba

La prueba de una aplicación se puede dividir en tres categorías principales y varios subniveles.
Las tres categorías principales incluyen pruebas realizadas en cada compilación (pruebas de
compilación), pruebas realizadas en cada hito importante (pruebas de hitos) y pruebas
realizadas al menos una vez en cada ciclo de lanzamiento del proyecto (pruebas de
lanzamiento). Las categorías de prueba y los niveles de prueba se definen a continuación:
2.2.1 Pruebas de compilación

2.2.1.1 Nivel 1: pruebas de aceptación de compilación
Las pruebas de aceptación de compilación deberían tardar menos de 2 a 3 horas en
completarse (lo normal es 15 minutos). Estos casos de prueba simplemente garantizan que la
aplicación se pueda crear e instalar correctamente. Otros casos de prueba relacionados
garantizan que los adoptantes hayan recibido el documento de versión de desarrollo adecuado
además de otra información relacionada con la compilación (punto de entrega, etc.). El objetivo
es determinar si es posible realizar más pruebas. Si falla algún caso de prueba de Nivel 1, la
compilación se devuelve a los desarrolladores sin haber sido probada.
2.2.1.2 Nivel 2 - Pruebas de humo

Las pruebas de humo deben automatizarse y durar menos de 2 a 3 horas (lo normal es 20
minutos). Estos casos de prueba verifican la funcionalidad principal en un alto nivel.
8
El objetivo es determinar si es posible realizar más pruebas. Estos casos de prueba deberían
enfatizar la amplitud más que la profundidad. Se deben tocar todos los componentes y cada
característica importante se debe probar brevemente mediante la prueba de humo. Si falla
algún caso de prueba de Nivel 2, la compilación se devuelve a los desarrolladores sin haber
sido probada.
2.2.1.3 Nivel 2a: Prueba de regresión de errores

Cada error que estuvo "Abierto" durante la compilación anterior, pero marcado como
"Corregido, necesita volver a probarse" para la compilación actual bajo prueba, deberá
retroceder o volver a probarse. Una vez que se completa la prueba de humo, es necesario
corregir todos los errores resueltos. La regresión de la mayoría de los errores debería llevar
entre 5 minutos y 1 hora.
2.2.2 Pruebas de hitos

2.2.2.1 Nivel 3: pruebas de ruta crítica
Los casos de prueba de ruta crítica se centran en características y funcionalidades que el
usuario verá y utilizará todos los días.
Los casos de prueba de ruta crítica deben pasar al final de cada 2 o 3 ciclos de prueba de
compilación. No es necesario probarlos cada gota, pero sí al menos una vez por hito. Por lo
tanto, todos los casos de prueba de ruta crítica deben ejecutarse al menos una vez durante el
ciclo de iteración y una vez durante el ciclo de lanzamiento final.
2.2.3 Pruebas de lanzamiento

2.2.3.1 Nivel 4 - Pruebas estándar
Casos de prueba que deben ejecutarse al menos una vez durante todo el ciclo de prueba de
esta versión. Estos casos se ejecutan una vez, no se repiten como ocurre con los casos de
prueba en niveles anteriores. Pruebas funcionales y pruebas de diseño detallado (casos de
prueba de especificaciones funcionales y especificaciones de diseño, respectivamente). Estos
se pueden probar varias veces para cada ciclo de prueba de hitos (iteración, lanzamiento final,
etc.).
Los casos de prueba estándar suelen incluir instalación, datos, GUI y otras áreas de prueba.
2.2.3.2 Nivel 5 - Prueba sugerida

Estos son casos de prueba que sería bueno ejecutar, pero que pueden omitirse debido a
limitaciones de tiempo.
La mayoría de los casos de pruebas de rendimiento y estrés son ejemplos clásicos de casos de
prueba sugeridos (aunque algunos deben considerarse casos de prueba estándar). Otros
ejemplos de casos de prueba sugeridos incluyen pruebas de WAN, LAN, red y carga.
2.3 Regresión de errores

Bug Regression será un inquilino central en todas las fases de prueba.
Todos los errores que se resuelvan como "Solucionados, es necesario volver a probarlos" se
corregirán cuando se notifique al equipo de pruebas sobre la nueva entrega que contiene las
correcciones. Cuando un error pasa la regresión, se considerará "Cerrado, Corregido". Si un
error falla en la regresión, el equipo de pruebas de los adoptantes notificará al equipo de
9
desarrollo ingresando notas en GForge. Cuando un error de Gravedad 1 falla en la regresión, el

equipo de pruebas de los adoptantes también debe enviar un correo electrónico inmediato al
desarrollo. El líder de pruebas será responsable de realizar un seguimiento e informar a la
gestión de desarrollo y productos sobre el estado de las pruebas de regresión.
2.4 Clasificación de errores

La selección de errores se llevará a cabo durante todas las fases del ciclo de desarrollo. La
clasificación de errores será responsabilidad del líder de pruebas. Las clasificaciones se
llevarán a cabo de forma regular y el período de tiempo estará determinado por la tasa de
búsqueda de errores y los cronogramas del proyecto.
Por lo tanto, sería típico realizar algunas selecciones durante la fase de planificación, luego tal
vez una clasificación por semana durante la fase de diseño y aumentar hasta dos veces por
semana durante las últimas etapas de la fase de desarrollo. Luego, la fase de Estabilización
debería ver una reducción sustancial en la cantidad de nuevos errores encontrados, por lo que
unas pocas clasificaciones por semana sería el máximo (para lidiar con el estado de los errores
existentes).
El líder de pruebas, el gerente de producto y el líder de desarrollo deben participar en estas

reuniones de clasificación. El líder de pruebas proporcionará la documentación requerida y los
informes sobre errores para todos los asistentes. El propósito de la clasificación es determinar
el tipo de resolución para cada error y priorizar y determinar un cronograma para todos los
"Errores a corregir". Luego, el desarrollo asignará los errores a la persona adecuada para que
los solucione e informará la resolución de cada error al sistema de seguimiento de errores de
GForge. El líder de pruebas será responsable de rastrear e informar sobre el estado de todas
las resoluciones de errores.
2.5 Criterios de suspensión y requisitos de reanudación

Esta sección debe definirse para enumerar los criterios y requisitos de reanudación en caso de
que no se cumplan ciertos grados y niveles predefinidos de objetivos y metas de prueba.
Consulte el ejemplo a continuación:
- Las pruebas se suspenderán en el módulo de software afectado cuando se descubran errores
en los casos de prueba de prueba de humo (nivel 1) o ruta crítica (nivel 2) después de la
tercera iteración.
- Las pruebas se suspenderán si hay un cambio crítico en el alcance que afecte la ruta crítica
El equipo de desarrollo debe presentar un informe de error. Después de corregir el error, el

equipo de desarrollo seguirá los criterios de eliminación (descritos anteriormente) para
proporcionar su última versión para pruebas adicionales. En ese momento, los usuarios
corregirán el error y, si se supera, continuarán probando el módulo.
2.6 Completitud de la prueba

Las pruebas se considerarán completadas cuando se hayan cumplido las siguientes
condiciones:
10
2.6.1 Condiciones estándar:

 Cuando los Adoptadores y Desarrolladores, acuerdan que las pruebas están completas,
que la aplicación es estable y que la aplicación cumple con los requisitos funcionales.
 Se ha pasado la ejecución del script de todos los casos de prueba en todas las áreas.
 Se han superado casos de prueba automatizados en todas las áreas.
 Todos los errores de prioridad 1 y 2 se han resuelto y cerrado.
 El NCI aprueba la realización de la prueba
 Cada área de prueba ha sido aprobada como completada por el líder de prueba.
 El 50 % de todos los errores de gravedad 1 y 2 resueltos se han vuelto a corregir con éxito
como validación final.
 Se han completado pruebas ad hoc en todas las áreas.
2.6.2 Condiciones de clasificación y notificación de errores:

Agregue informes de errores y condiciones de clasificación que se enviarán y evaluarán para
medir el estado actual.
 La tasa de búsqueda de errores indica una tendencia decreciente antes de la tasa de
errores cero (no se encontraron errores nuevos en las secciones 1/2/3).
 La tasa de búsqueda de errores se mantiene en 0 errores nuevos encontrados (gravedad
1/2/3) a pesar de un esfuerzo de prueba constante durante 3 días o más.
 La distribución de la gravedad de los errores ha cambiado a una disminución constante en
Sev. 1 y 2 errores descubiertos.
 No quedan errores que 'deben corregirse' a pesar de las pruebas sostenidas.
3 Entregables de la prueba
Las pruebas proporcionarán resultados específicos durante el proyecto. Estos entregables se
dividen en tres categorías básicas: documentos, casos de prueba/escritos de errores e
informes. A continuación se muestra un diagrama que indica las dependencias de los distintos
entregables:
11
Require- Test Case Bug

ments [PM] Results Results
Project Plan Test Plan Test Spec. Test Bugs

[PM] / Outline Cases
Detailed
Functional Design
Spec [PM] TC Coverage Bug Reports
[Dev]
Reports
Weekly
Status
Reports
Como muestra el diagrama anterior, hay una progresión de un entregable al siguiente. Cada
entregable tiene sus propias dependencias, sin las cuales no es posible completarlo por
completo.
La siguiente página contiene una matriz que describe todos los entregables que utilizará
Testing.
3.1 Matriz de entregables
A continuación se muestra la lista de artefactos impulsados por procesos y que deben

producirse durante el ciclo de vida de las pruebas. Ciertos entregables deben entregarse como
parte de la validación de la prueba; puede agregarlos a la siguiente lista de entregables que
respalden los objetivos generales y mantengan la calidad.
Esta matriz debe actualizarse periódicamente durante todo el ciclo de desarrollo del proyecto
en su plan de prueba específico del proyecto.
Entregable
Documentos
Enfoque de prueba
 Plan de prueba
 Calendario de pruebas
 Especificaciones de prueba
Caso de prueba/escritos de errores
Casos de prueba/Resultados
12
Informes de cobertura de pruebas

Rastreador de errores de GForge para informes de errores
Informes
Informe de resultados de la prueba
Informe final de prueba: aprobación
3.2 Documentos
3.2.1 Documento de enfoque de prueba

El documento de Enfoque de Prueba se deriva de los documentos del Plan del Proyecto,
Requisitos y Especificaciones Funcionales. Este documento define el enfoque de prueba
general que se adoptará para el proyecto. El documento de Enfoque de prueba estándar que
está leyendo actualmente es un texto estándar del cual se puede extraer el documento de
Enfoque de prueba más específico del proyecto.
Cuando se complete este documento, el líder de pruebas lo distribuirá al gerente de producto,

al líder de desarrollo, al representante del usuario, al gerente de programa y a otros, según sea
necesario, para su revisión y aprobación.
3.2.2 Plan de prueba

El plan de prueba se deriva del enfoque de prueba, los requisitos, las especificaciones
funcionales y las especificaciones de diseño detalladas. El Plan de prueba identifica los detalles
del enfoque de prueba, identificando las áreas de casos de prueba asociadas dentro del
producto específico para este ciclo de lanzamiento.
El propósito del documento del Plan de Prueba es:
 Especifique el enfoque que utilizará Testing para probar el producto y los entregables
(extracto del Enfoque de prueba).
 Divida el producto en áreas distintas e identifique las características del producto que se
van a probar.
 Especifique los procedimientos que se utilizarán para probar la aprobación y el lanzamiento
del producto.
 Indique las herramientas utilizadas para probar el producto.
 Enumere los planes de recursos y programación.
 Indique las personas de contacto responsables de las distintas áreas del proyecto.
 Identificar riesgos y planes de contingencia que puedan impactar las pruebas del producto.
 Especifique los procedimientos de gestión de errores para el proyecto.
 Especificar criterios para la aceptación de lanzamientos de desarrollo a prueba (de
compilaciones).
3.2.3 Calendario de pruebas

Esta sección no es vital para el documento en su conjunto y puede modificarse o eliminarse si
el autor lo necesita.
El Programa de pruebas es responsabilidad del Jefe de pruebas (o del Programador de
departamento, si existe) y se basará en la información del Programador de proyectos (realizado
13
por el Gerente de producto). El cronograma de pruebas específico del proyecto se puede

realizar en MS Project.
3.2.4 Especificaciones de prueba

Un documento de especificación de prueba se deriva del plan de prueba, así como de los
documentos de requisitos, especificaciones funcionales y especificaciones de diseño.
Proporciona especificaciones para la construcción de casos de prueba e incluye listas de áreas
de casos de prueba y objetivos de prueba para cada uno de los componentes que se probarán
según lo identificado en el plan de pruebas del proyecto.
3.2.5 Requerimientos de trazabilidad matriz

Una Matriz de Trazabilidad de Requisitos (RTM) que se utiliza para vincular los escenarios de
prueba con los requisitos y casos de uso es una parte obligatoria de la documentación del Plan
de pruebas para todos los proyectos. La trazabilidad de requisitos se define como la capacidad
de describir y seguir la vida de un requisito, tanto hacia adelante como hacia atrás (es decir,
desde sus orígenes, a través de su desarrollo y especificación, hasta su posterior
implementación y uso, y a través de períodos de refinamiento y desarrollo continuos). iteración
en cualquiera de estas fases).1
Se adjunta un ejemplo de RTM básico que podría proporcionar un punto de partida para esta
documentación. Lo importante es elegir una plantilla o base documental que consiga una
trazabilidad exhaustiva durante toda la vida del proyecto.
3.3 Seguimiento y depuración de defectos
3.3.1 Flujo de trabajo de prueba

El siguiente flujo de trabajo ilustra el proceso de flujo de trabajo de prueba para desarrolladores
y adoptantes para la aceptación del usuario y las pruebas de un extremo a otro.
Pl. tenga en cuenta el proceso resaltado en amarillo en el que el Adoptante debe enviar
directamente la lista de defectos con evidencia al Desarrollador. De manera similar, el
Desarrollador debe confirmar directamente con el Adoptador después de corregir errores junto
con la actualización de Bugzilla.
1
http://www.projectperfect.com.au/info_requirements_traceability.php
14
3.3.2 Informe de defectos utilizando G FORGE

TODOS los defectos deben registrarse utilizando 'G FORGE' para abordarlos y depurarlos.
También se solicita a los adoptantes que envíen un informe diario de defectos al desarrollador.
Los desarrolladores actualizarán la lista de defectos en G Forge y notificarán al solicitante una
vez que se haya resuelto el defecto.
Los desarrolladores y adoptantes deben solicitar una cuenta en G Forge para el espacio de
trabajo correspondiente. La depuración debe basarse en Prioridad: Alta > Media > Baja; estas
prioridades las establecen los Adoptadores y se basan en qué tan crítico es el script de prueba
en términos de dependencia y principalmente en el escenario del caso de uso.
La siguiente captura de pantalla muestra la pantalla 'Agregar nuevo defecto', los campos
marcados con (*) son campos obligatorios y los Adoptantes también deben cargar el archivo de
evidencia para todos los defectos enumerados.
Todos los defectos de alta prioridad deben abordarse dentro de 1 día de la solicitud y
resolverse/cerrarse dentro de 2 días de la solicitud inicial.
Todos los defectos de prioridad media deben abordarse dentro de los 2 días posteriores a la
solicitud y resolverse/cerrarse dentro de los 4 días posteriores a la solicitud inicial.
Todos los defectos de baja prioridad deben resolverse/cerrarse a más tardar 5 días después de
la solicitud inicial.
URL de Forja G -http://gforge.nci.nih.gov

El usuario puede buscar un espacio de trabajo o seleccionar de la lista de proyectos recientes
en la parte inferior derecha de la ventana. Por ejemplo, buscar 'caties'.
En el espacio de trabajo, el usuario puede solicitar a los administradores que configuren su
cuenta de usuario para ese espacio de trabajo.
Después de iniciar sesión, el usuario puede seleccionar la pestaña 'Rastreador' para 'Enviar
nuevo defecto'. El usuario puede agregar información sobre defectos. Como se muestra en la
siguiente pantalla.
15
Comentarios de campo
Hardware: enumera el hardware del entorno de prueba. por ejemplo, PC,
MAC
Producto: agregue valor predeterminado al nombre del espacio de trabajo,
por ejemplo, caTIES
Sistema operativo: Win 98, Win 2k, Win XP, MAC, etc.
Versión - Versión de la aplicación
Gravedad: se trata de una mejora o un error de gravedad menor a
mayor que puede no interferir con pruebas adicionales ni bloquear por
completo cualquier esfuerzo de prueba futuro.
Resolución: solo el DESARROLLADOR actualizará según el defecto
Módulo: para una aplicación con varios módulos, seleccione el módulo
apropiado para el defecto informado.
URL: agregue la URL si corresponde
Asignado a: lo actualizará el desarrollador a quien se le ha asignado el
ticket.
Prioridad: establezca una prioridad según la gravedad
Resumen: resumen del defecto, error o problema
16
Descripción detallada. - Detalles del defecto, error o problema.

Subir archivo - Adjuntar archivo de evidencia
Enviar: enviar el ticket de error
3.4 Informes
El líder de pruebas será responsable de redactar y difundir los siguientes informes al personal
apropiado del proyecto según sea necesario.
3.4.1 Informes de estado de las pruebas

El líder de pruebas proporcionará un informe de estado semanal o quincenal al personal del
proyecto. Este informe resumirá las actividades de prueba semanales, problemas, riesgos,
recuentos de errores, cobertura de casos de prueba y otras métricas relevantes.
3.4.2 Informes de finalización de fase

Cuando se complete cada fase de la prueba, el líder de pruebas distribuirá un informe de
finalización de la fase al gerente de producto, al líder de desarrollo y al gerente de programa
para su revisión y aprobación.
Las siguientes viñetas ilustran un ejemplo de lo que puede incluir el documento.
El documento debe contener las siguientes métricas:
 Total de casos de prueba, número ejecutado, número de aprobaciones/fallos, número aún
por ejecutar
 Número de errores encontrados hasta la fecha, número resuelto y número aún abierto
 Desglose de errores por matriz de gravedad/prioridad
 Discusión de riesgos no resueltos
 Discusión sobre el progreso del cronograma (¿estamos donde se supone que debemos
estar?)
3.4.3 Informe final de prueba: aprobación

El jefe de prueba emitirá un informe de prueba final. Certificará hasta qué punto se han
completado realmente las pruebas (se sugiere un informe de cobertura del caso de prueba) y
una evaluación de la preparación del producto para su lanzamiento a producción.
3.5 Matriz de responsabilidad
Insertar una matriz de recursos de prueba: quién participa y cuál es su función.
4 Necesidades de recursos y medio ambiente
17
4.1 Herramientas de prueba
4.1.1 Herramientas de seguimiento

caBIG utiliza el rastreador de errores GForge para ingresar y rastrear todos los errores y
problemas del proyecto. El líder de pruebas es responsable de mantener la base de datos de
GForge.
4.1.1.1 Gestión de configuración

Por favor incluya su plan de gestión de configuración
4.2 Entorno de prueba
4.2.1 Hardware
Incluya los requisitos mínimos de hardware que se utilizarán para probar la Aplicación.
Las pruebas tendrán control de acceso a uno o más servidores de aplicaciones/bases de datos
separados de los utilizados por miembros del equipo del proyecto que no sean de prueba. Las
pruebas también tendrán control de acceso a una cantidad adecuada de estaciones de trabajo
de PC configuradas de diversas formas para garantizar que las pruebas tengan un rango desde
las configuraciones de hardware mínimas hasta las recomendadas por el cliente enumeradas
en los documentos de Requisitos, Especificaciones funcionales y Especificaciones de diseño
del proyecto.
4.2.2 Software
Además de la aplicación y cualquier otro software especificado por el cliente, la siguiente lista
de software debe considerarse como mínimo:
 Estación de trabajo NT 4.0 o Windows 95.
 MS Office 95 Profesional
 Intercambio de MS
 TCM (servidor de herramientas de prueba)
 Administrador de tareas (servidor de herramientas de prueba)
4.3 Definición de gravedad y prioridad de errores

Ω
El líder de pruebas, el líder de desarrollo y el administrador del programa participarán en

reuniones de revisión de errores para asignar la prioridad de todos los errores actualmente
activos. Esta reunión se conocerá como “Reuniones de clasificación de errores”. El líder de
pruebas es responsable de organizar estas reuniones de forma rutinaria para abordar el
conjunto actual de errores nuevos y existentes pero no resueltos.
4.3.1 Lista de gravedad

El evaluador que ingresa un error en GForge también es responsable de ingresar la gravedad
del error.
18
ID de Nivel de Descripción de gravedad

1 Crítico El módulo/producto falla o el error causa condiciones no recuperables.
Los fallos del sistema, los errores de GP, la corrupción de archivos o
bases de datos, o la posible pérdida de datos, los bloqueos del
programa que requieren reinicio son todos ejemplos de un problema
grave. 1 error.
2 Alto Componente principal del sistema inutilizable debido a una falla o
funcionalidad incorrecta. sev. 2 causan problemas graves, como falta
de funcionalidad o mensajes de error insuficientes o poco claros que
pueden tener un impacto importante para el usuario, impiden que se
prueben otras áreas de la aplicación, etc. 2 errores pueden tener una
solución alternativa, pero la solución es inconveniente o difícil.
3 Medio Funcionalidad incorrecta del componente o proceso. Existe una
solución sencilla para el error si es Sev. 3.
4 Menor Errores de documentación o errores de gravedad 3 aprobados.
4.3.2 Lista de prioridades

ID de Nivel de Descripción de prioridad
5 debe arreglar Este error debe solucionarse de inmediato; El producto no se puede
enviar con este error.
4 debería arreglar Estos son problemas importantes que deberían solucionarse lo antes
posible. Sería una vergüenza para la empresa si se publicara este
error.
3 Reparar cuando El problema debería solucionarse dentro del tiempo disponible. Si el
tenga tiempo error no retrasa la fecha de envío, corríjalo.
2 Baja prioridad No es importante (en este momento) que se solucionen estos errores.
Corrija estos errores después de que se hayan solucionado todos los
demás errores.
1 Trivial Mejoras/Es bueno tener funciones incorporadas; simplemente están
fuera del alcance actual.
4.4 Informe de errores

El equipo de pruebas reconoce que el proceso de informe de errores es una herramienta de
comunicación fundamental dentro del proceso de prueba. Sin una comunicación eficaz de la
información sobre errores y otros problemas, el proceso de desarrollo y lanzamiento se verá
afectado negativamente.
El líder de pruebas será responsable de gestionar el proceso de informe de errores. Se

utilizarán las herramientas y procesos estándar de notificación de errores de Testing. GForge
es la herramienta estándar de registro/seguimiento de errores de toda la empresa. Las pruebas
y el desarrollo ingresarán sus datos en la base de datos de GForge siguiendo las definiciones
de entrada de campo definidas a continuación.
19
5 Términos/Acrónimos
Los siguientes términos se utilizan como ejemplos; agregue o elimine cualquier término relevante para el
documento.
TÉRMINO/SIGLA DEFINICIÓN
API Interfaz del programa de aplicación
BAH Booz Allen Hamilton
BCP Plan de negocios continuo
GATO Pruebas de aceptación del cliente
Pruebas de Prueba escenarios de usuario y diversas condiciones de ruta
extremo a extremo verificando que el sistema se ejecute y realice tareas con
precisión con el mismo conjunto de datos de principio a fin,
según lo previsto.
ER;ES Registros Electrónicos; Firmas Electrónicas
N/A No aplica
NCI Instituto Nacional del Cáncer
control de calidad Seguro de calidad
RTM Requerimientos de trazabilidad matriz
PYME Experto en la materia
COMPENSACIÓN Procedimiento Operativo Estándar
TBPT Banco de tejidos y herramientas de patología
Por determinar Estar determinado
TSR Informe resumido de la prueba
20

Historial de Cambios de Documentos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Historial de Cambios de Documentos

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

<<NOMBRE DEL PROYECTO-

V1.0 ¿Qué cambios (adiciones y

3.4.2 Informes de finalización de fase........................................................................................................dieciséis

1.1.2 Fuera del ámbito

1.2 Objetivo de calidad

1.2.1 Objetivo primario

Cualquier cambio, adición o eliminación al documento de requisitos, especificación funcional o

1.2.2 Objetivo secundario

1.3 Funciones y responsabilidades

(a) Desarrollar el sistema/aplicación

(a) Contribuir al caso de uso, desarrollo de requisitos a través de la revisión.

1.3.3 Equipo de gestión de procesos de prueba

(a) Supervisar y gestionar la integridad de las pruebas y respaldar las

Agregue más según corresponda al alcance de la prueba

1.4 Supuestos para la ejecución de la prueba

1.5 Restricciones para la ejecución de pruebas

2.1.1 Descripción general

El propósito del Plan de Pruebas es lograr lo siguiente:

2.1.2 Pruebas de usabilidad

2.1.3 Pruebas unitarias (múltiples)

2.1.4 Pruebas de iteración/regresión

A continuación se muestran ejemplos. Se puede utilizar cualquier ejemplo si se considera

2.1.5 Pruebas de lanzamiento final

2.1.6 Criterios de integridad de la prueba

El objetivo del hito es colocar la versión/aplicación (compilación) en producción después de que

2.2 Niveles de prueba

2.2.1 Pruebas de compilación

2.2.1.2 Nivel 2 - Pruebas de humo

2.2.1.3 Nivel 2a: Prueba de regresión de errores

2.2.2 Pruebas de hitos

2.2.3 Pruebas de lanzamiento

2.2.3.2 Nivel 5 - Prueba sugerida

2.3 Regresión de errores

desarrollo ingresando notas en GForge. Cuando un error de Gravedad 1 falla en la regresión, el

2.4 Clasificación de errores

El líder de pruebas, el gerente de producto y el líder de desarrollo deben participar en estas

2.5 Criterios de suspensión y requisitos de reanudación

El equipo de desarrollo debe presentar un informe de error. Después de corregir el error, el

2.6 Completitud de la prueba

2.6.1 Condiciones estándar:

2.6.2 Condiciones de clasificación y notificación de errores:

Require- Test Case Bug

Project Plan Test Plan Test Spec. Test Bugs

3.1 Matriz de entregables

A continuación se muestra la lista de artefactos impulsados por procesos y que deben

Informes de cobertura de pruebas

3.2.1 Documento de enfoque de prueba

Cuando se complete este documento, el líder de pruebas lo distribuirá al gerente de producto,

3.2.2 Plan de prueba

3.2.3 Calendario de pruebas

por el Gerente de producto). El cronograma de pruebas específico del proyecto se puede

3.2.4 Especificaciones de prueba

3.2.5 Requerimientos de trazabilidad matriz

3.3 Seguimiento y depuración de defectos

3.3.1 Flujo de trabajo de prueba

3.3.2 Informe de defectos utilizando G FORGE

URL de Forja G -http://gforge.nci.nih.gov

Descripción detallada. - Detalles del defecto, error o problema.

3.4.1 Informes de estado de las pruebas

3.4.2 Informes de finalización de fase

3.4.3 Informe final de prueba: aprobación

3.5 Matriz de responsabilidad

Insertar una matriz de recursos de prueba: quién participa y cuál es su función.