Suscríbete a DeepL Pro para poder editar este documento.

Esquema delenplan
Entra de
www.DeepL.com/pro para más información.
pruebas del IEEE

ESQUEMA DEL PLAN DE

ENSAYOS (FORMATO
IEEE 829)
1) Identificador del plan de pruebas
2) Referencias
3) Introducción
4) Artículos de prueba
5) Problemas de riesgo del software
6) Características a probar
7) Características que no deben ser probadas
8) Acercamiento
9) Criterios de paso o fallo del artículo
10) Criterios de suspensión y requisitos de reanudación
11) Entregas de prueba
12) Tareas de prueba restantes
13) Necesidades ambientales
14) Necesidades de personal y formación
15) Responsabilidades
16) Programación
17) Planificación de riesgos y contingencias
18) Aprobaciones
19) Glosario

Preparado por Systeme Evolutif Página

Limited 1
 PLANTILLA DEL PLAN DE
PRUEBAS DEL IEEE

1 IDENTIFICADOR DEL PLAN DE PRUEBAS

Algún tipo de empresa única generó un número para identificar este plan de pruebas, su nivel
y el nivel de software con el que está relacionado. Preferiblemente el nivel del plan de
pruebas será el mismo que el nivel de software relacionado. El número también puede
identificar si el plan de pruebas es un plan maestro, un plan de nivel, un plan de integración o
cualquier nivel de plan que represente. Esto es para ayudar a coordinar las versiones de
software y software de prueba dentro de la gestión de la configuración.
Tengan en cuenta que los planes de prueba son como otra documentación de software, son
de naturaleza dinámica y deben mantenerse actualizados. Por lo tanto, tendrán números de
revisión.
Es posible que desee incluir información sobre el autor y la información de contacto,
incluida la información del historial de revisiones, como parte de la sección de identificación
o como parte de la introducción.

2 REFERENCIAS
Enumere todos los documentos que apoyan este plan de pruebas. Consulte el número de
versión/liberación real del documento tal y como está almacenado en el sistema de gestión
de la configuración. No duplique el texto de otros documentos, ya que esto reducirá la
viabilidad de este documento y aumentará el esfuerzo de mantenimiento. Los documentos
a los que se puede hacer referencia incluyen
• Plan del proyecto
• Especificaciones de requisitos
• Documento de diseño de alto nivel
• Documento de diseño detallado
• Normas del proceso de desarrollo y ensayo
• Directrices metodológicas y ejemplos
• Normas y directrices corporativas

3 INTRODUCCIÓN
Declarar el propósito del Plan, posiblemente identificando el nivel del plan (maestro, etc.).
Esta es esencialmente la parte del resumen ejecutivo del plan.
Tal vez desee incluir referencias a otros planes, documentos o artículos que contengan
información pertinente a este proyecto/proceso. Si es preferible, puede crear una sección de
referencias que contenga todos los documentos de referencia.
Identificar el alcance del plan en relación con el plan del Proyecto de Software al que se
refiere. Otros elementos pueden ser las limitaciones de recursos y presupuesto, el alcance
del esfuerzo de ensayo, la forma en que el ensayo se relaciona con otras actividades de
evaluación (Análisis y exámenes), y el posible proceso que se utilizará para el control de los
cambios y la comunicación y coordinación de las actividades clave.
Como este es el "Resumen Ejecutivo", mantén la información breve y al grano.
4 ELEMENTOS DE PRUEBA (FUNCIONES)
Estas son las cosas que pretende probar dentro del alcance de este plan de pruebas.
Esencialmente, algo que probará, una lista de lo que se va a probar. Esto puede
desarrollarse a partir de los inventarios de aplicaciones de software, así como de otras
fuentes de documentación e información.
 Esto puede ser controlado y definido por su proceso local de Gestión de la Configuración
(CM), si lo tiene. Esta información incluye los números de versión, los requisitos de
configuración cuando sea necesario (especialmente si se admiten varias versiones del
producto). También puede incluir cuestiones clave del programa de entrega para elementos
críticos.
Recuerde, lo que está probando es lo que pretende entregar al cliente.
Esta sección puede orientarse al nivel del plan de pruebas. Para los niveles superiores puede
ser por aplicación o área funcional, para los niveles inferiores puede ser por programa,
unidad, módulo o construcción.

5 PROBLEMAS DE RIESGO DEL SOFTWARE

Identificar qué software se va a probar y cuáles son las áreas críticas, tales como:
A. Entrega de un producto de terceros.
B. Nueva versión del software de interfaz
C. Capacidad de usar y entender un nuevo paquete/herramienta, etc.
D. Funciones extremadamente complejas
E. Modificaciones de los componentes con un historial de fracaso en el pasado
F. Módulos o solicitudes de cambio mal documentados
Existen algunos riesgos inherentes a los programas informáticos, como la complejidad; es
necesario identificarlos.
A. Seguridad
B. Múltiples interfaces
C. Impactos en el cliente
D. Los reglamentos y normas del gobierno
Otra área clave de riesgo es un malentendido de los requisitos originales. Esto puede ocurrir a
nivel de la administración, el usuario y el desarrollador. Hay que tener en cuenta los requisitos
vagos o poco claros y los que no se pueden probar.
El historial de defectos (bugs) descubiertos durante las pruebas de la Unidad ayudará a
identificar áreas potenciales dentro del software que son riesgosas. Si la prueba unitaria
descubrió un gran número de defectos o una tendencia a los defectos en un área particular
del software, esto es una indicación de posibles problemas futuros. La naturaleza de los
defectos es que se agrupen y agrupen. Si el defecto se ha producido antes, lo más probable
es que siga siendo propenso a los defectos.
Un buen enfoque para definir dónde están los riesgos es tener varias sesiones de lluvia de
ideas.
• Empieza con ideas, como, lo que me preocupa de este proyecto/aplicación.

6 CARACTERÍSTICAS A PROBAR
Este es un listado de lo que se va a probar desde el punto de vista de los USUARIOS de lo
que hace el sistema. Esto no es una descripción técnica del software, sino un punto de vista
de los USUARIOS de las funciones.
Establezca el nivel de riesgo de cada característica. Utilice una simple escala de clasificación
como (H, M, L): Alto, Medio y Bajo. Estos tipos de niveles son comprensibles para un
usuario. Debe estar preparado para discutir por qué se eligió un nivel en particular.
Cabe señalar que la sección 4 y la sección 6 son muy similares. La única diferencia
verdadera es el punto de vista. La Sección 4 es una descripción de tipo técnico que incluye
los números de versión y otra información técnica y la Sección 6 es desde el punto de vista
del usuario. Los usuarios no entienden
 terminología técnica de los programas informáticos; entienden las funciones y los procesos
en relación con su trabajo.

7 CARACTERÍSTICAS QUE NO DEBEN SER PROBADAS

Se trata de un listado de lo que NO debe probarse tanto desde el punto de vista de los
usuarios de lo que hace el sistema como desde el punto de vista de la gestión de la
configuración/control de la versión. Esto no es una descripción técnica del software, sino una
vista de los USUARIOS de las funciones.
Identificar POR QUÉ la característica no debe ser probada, puede haber cualquier número de
razones.
• No se incluirá en esta versión del software.
• De bajo riesgo, se ha utilizado antes y se considera estable.
• Será liberado pero no probado o documentado como parte funcional de la liberación
de esta versión del software.
Las secciones 6 y 7 están directamente relacionadas con las secciones 5 y 17. Lo que se
somete y lo que no se somete a prueba se ve directamente afectado por los niveles de riesgo
aceptables dentro del proyecto, y lo que no se somete a prueba afecta al nivel de riesgo del
proyecto.

8 ENFOQUE (ESTRATEGIA)
Esta es su estrategia general de prueba para este plan de pruebas; debe ser apropiada para el
nivel del plan (maestro, aceptación, etc.) y debe estar de acuerdo con todos los niveles
superiores e inferiores de los planes. Se deben identificar las normas y procesos generales.
• ¿Hay alguna herramienta especial que se deba usar y cuál es?
• ¿Requerirá la herramienta un entrenamiento especial?
• ¿Qué métrica se recogerá?
• ¿En qué nivel se recogerá cada métrica?
• ¿Cómo se manejará la Gestión de la Configuración?
• ¿Cuántas configuraciones diferentes se probarán?
• Hardware
• Software
• Combinaciones de HW, SW y otros paquetes de proveedores
• ¿Qué niveles de pruebas de regresión se harán y cuánto en cada nivel de prueba?
• ¿Se basarán las pruebas de regresión en la gravedad de los defectos detectados?
• ¿Cómo se procesarán los elementos de los requisitos y el diseño que no tienen
sentido o que no son comprobables?
Si se trata de un plan maestro de ensayos, también se debe identificar el enfoque general
del proyecto de ensayos y los requisitos de cobertura.
Especifique si existen requisitos especiales para las pruebas.
• Sólo se probará el componente completo.
• Debe probarse un segmento específico de agrupación de
características/componentes en conjunto. Otra información que puede ser útil para
establecer el enfoque es:
• MTBF, Tiempo medio entre fallos - si es una medida válida para la prueba en cuestión y
si los datos están disponibles.
• SRE, Software Reliability Engineering - si esta metodología está en uso y si la
información está disponible.
 ¿Cómo se gestionarán las reuniones y otros procesos de organización?

9 CRITERIOS DE APROBACIÓN O RECHAZO DE ARTÍCULOS

¿Cuáles son los criterios de finalización de este plan? Este es un aspecto crítico de
cualquier plan de pruebas y debe ser apropiado para el nivel del plan.
• En el nivel de prueba de la Unidad podrían ser artículos como:
• Todos los casos de prueba completados.
• Un porcentaje determinado de casos completados con un porcentaje que contiene
algún número de defectos menores.
• La herramienta de cobertura de códigos indica todos los códigos cubiertos.
• En el nivel del plan maestro de pruebas, podrían ser artículos como..:
• Todos los planes de nivel inferior completados.
• Un número determinado de planes completados sin errores y un porcentaje con
defectos menores.
Puede tratarse de un criterio de nivel de caso de prueba individual o de un plan de nivel
unitario, o puede tratarse de requisitos funcionales generales para planes de nivel superior.
¿Cuál es el número y la gravedad de los defectos localizados?
• ¿Es posible comparar esto con el número total de defectos? Esto puede ser imposible,
ya que algunos defectos nunca se detectan.
• Un defecto es algo que puede causar una falla, y puede ser aceptable dejarlo en la
solicitud.
• Un fallo es el resultado de un defecto visto por el usuario, el sistema se bloquea, etc.

10 CRITERIOS DE SUSPENSIÓN Y REQUISITOS DE

REANUDACIÓN
Saber cuándo hacer una pausa en una serie de pruebas.
• Si el número o el tipo de defectos llega a un punto en el que el seguimiento de la prueba
no tiene ningún valor, no tiene sentido continuar la prueba; sólo se están desperdiciando
recursos.
Especificar qué constituye la interrupción de una prueba o serie de pruebas y cuál es el nivel
aceptable de defectos que permitirá que la prueba proceda más allá de los defectos.
Las pruebas después de un error verdaderamente fatal generarán condiciones que pueden
ser identificadas como defectos, pero que en realidad son errores fantasmas causados por
los defectos anteriores que fueron ignorados.

11 ENTREGAS DE PRUEBA
¿Qué se va a entregar como parte de este plan?
• Documento del plan de pruebas.
• Casos de prueba.
• Especificaciones de diseño de la prueba.
• Herramientas y sus resultados.
• Simuladores.
• Generadores estáticos y dinámicos.
• Registros de errores y registros de ejecución.
• Informes de problemas y medidas correctivas.
Una cosa que no se puede entregar como prueba es el propio software que aparece en la
lista de elementos de prueba y que se entrega por desarrollo.
12 LAS TAREAS DE PRUEBA RESTANTES
Si se trata de un proceso de varias fases o si la solicitud se va a entregar en incrementos,
puede haber partes de la solicitud que no se aborden en este plan. Es necesario identificar
estas áreas para evitar cualquier confusión en caso de que se informe de los defectos en esas
futuras funciones. Esto también permitirá a los usuarios y a los probadores evitar funciones
incompletas y evitar el desperdicio de recursos en la búsqueda de no defectos.
Si el proyecto se desarrolla como un proceso multipartito, este plan sólo podrá cubrir una
parte del total de las funciones/características. Es necesario identificar esta situación para que
en esas otras áreas se desarrollen planes para ellas y para evitar el desperdicio de recursos en
el seguimiento de defectos que no se relacionan con este plan.
Cuando un tercero está desarrollando el software, esta sección puede contener descripciones
de las tareas de prueba pertenecientes tanto a los grupos internos como a los grupos externos.

13 NECESIDADES AMBIENTALES
¿Hay algún requisito especial para este plan de pruebas, como:
• Hardware especial como simuladores, generadores estáticos, etc.
• Cómo se proporcionarán los datos de la prueba. ¿Existen requisitos especiales de
recolección o rangos específicos de datos que deban ser proporcionados?
• ¿Cuántas pruebas se harán en cada componente de una función de varias partes?
• Requerimientos especiales de energía.
• Versiones específicas de otros programas informáticos de apoyo.
• Uso restringido del sistema durante las pruebas.

14 NECESIDADES DE PERSONAL Y CAPACITACIÓN

Entrenamiento en la aplicación/sistema.
Entrenamiento para cualquier herramienta
de prueba que se vaya a utilizar.
La sección 4 y la sección 15 también afectan a esta sección. Qué se va a probar y quién es
responsable de las pruebas y el entrenamiento.

15 RESPONSABILIDADES
¿Quién está a cargo?
Este número incluye todas las áreas del plan. Aquí hay algunos ejemplos:
• Estableciendo riesgos.
• Seleccionando las características a probar y no probar.
• Estableciendo una estrategia general para este nivel de plan.
• Asegurarse de que todos los elementos necesarios están en su lugar para las pruebas.
• Prever la resolución de conflictos de programación, especialmente si se realizan
pruebas en el sistema de producción.
• ¿Quién proporciona el entrenamiento requerido?
• ¿Quién toma las decisiones críticas de ir/no ir para los artículos no cubiertos en los planes
de prueba?
16 HORARIO
Debe basarse en estimaciones realistas y validadas. Si las estimaciones para el desarrollo de
la aplicación son inexactas, todo el plan del proyecto se deslizará y las pruebas formarán
parte del plan general del proyecto.
• Como todos sabemos, la primera área de un plan de proyecto que se corta cuando llega
el momento de la verdad al final de un proyecto es la prueba. Normalmente se reduce a
la decisión, "Pongamos algo aunque no funcione muy bien". Y, como todos sabemos,
esta suele ser la peor decisión posible.
También debe abordarse aquí la forma en que se manejará el desfase en el calendario.
• Si los usuarios saben de antemano que un deslizamiento en el desarrollo causará un
deslizamiento en la prueba y en la entrega general del sistema, pueden ser un poco
más tolerantes, si saben que les conviene obtener una aplicación mejor probada.
• Explicando los efectos aquí tienes la oportunidad de discutirlos antes de que ocurran.
Incluso puedes conseguir que los usuarios acepten algunos defectos por adelantado, si el
programa se resbala.
En este punto, se deben identificar todos los hitos pertinentes con su relación al proceso
de desarrollo identificado. Esto también ayudará a identificar y rastrear posibles
desviaciones en el calendario causadas por el proceso de ensayo.
Siempre es mejor vincular todas las fechas de las pruebas directamente a las fechas de sus
actividades de desarrollo relacionadas. Esto evita que el equipo de pruebas sea percibido
como la causa de un retraso. Por ejemplo, si las pruebas del sistema van a comenzar
después de la entrega de la construcción final, entonces las pruebas del sistema comienzan
el día después de la entrega. Si la entrega se retrasa, las pruebas del sistema comienzan
desde el día de la entrega, no en una fecha específica. Esto se llama fecha dependiente o
relativa.

17 PLANIFICACIÓN DE RIESGOS Y CONTINGENCIAS

¿Cuáles son los riesgos generales del proyecto, con énfasis en el proceso de prueba?
• Falta de recursos de personal cuando las pruebas van a comenzar.
• La falta de disponibilidad del hardware, software, datos o herramientas necesarias.
• Entrega tardía del software, hardware o herramientas.
• Retrasos en la formación sobre la aplicación y/o las herramientas.
• Cambios en los requisitos o diseños originales.
Especificar lo que se hará para varios eventos, por
ejemplo:
• La definición de los requisitos se completará para el 1 de enero de 19XX y, si los
requisitos cambian después de esa fecha, se tomarán las siguientes medidas.
• El programa de pruebas y el programa de desarrollo se moverán un número
apropiado de días. Esto rara vez ocurre, ya que la mayoría de los proyectos tienden a
tener fechas de entrega fijas.
• El número de pruebas realizadas se reducirá.
• Se aumentará el número de defectos aceptables.
• Estos dos artículos podrían disminuir la calidad general del producto entregado.
• Se añadirán recursos al equipo de pruebas.
• El equipo de pruebas trabajará horas extras.
• Esto podría afectar a la moral del equipo.
• El alcance del plan puede ser modificado.
• Puede haber cierta optimización de los recursos. Esto debe evitarse, si es posible,
por razones obvias.
 • Podrías simplemente dejarlo. Una opción bastante extrema, por no decir otra cosa.
La administración suele ser reacia a aceptar escenarios como el anterior, aunque lo haya
visto en el pasado.
Lo importante es recordar que, si no se hace nada en absoluto, el resultado habitual es que las
pruebas se recortan o se omiten por completo, lo que no debería ser una opción aceptable.

18 APROBACIONES
¿Quién puede aprobar el proceso como completo y permitir que el proyecto pase al siguiente
nivel (dependiendo del nivel del plan)?
A nivel del plan maestro de pruebas, pueden ser todas las partes involucradas.
Al determinar el proceso de aprobación, tenga en cuenta quién es el público.
• La audiencia de un plan de nivel de prueba de unidad es diferente a la de un plan de
nivel de integración, sistema o maestro.
• Los niveles y el tipo de conocimiento en los diversos niveles también serán diferentes.
• Los programadores son muy técnicos pero pueden no tener una comprensión clara
del proceso empresarial general que impulsa el proyecto.
• Los usuarios pueden tener diversos niveles de perspicacia comercial y muy poca
capacidad técnica.
• Desconfíe siempre de los usuarios que afirman tener un alto nivel de conocimientos
técnicos y de los programadores que afirman comprender plenamente el proceso
comercial. Este tipo de individuos pueden causar más daño que bien si no tienen las
habilidades que creen poseer.

19 GLOSARIO
Se utiliza para definir los términos y acrónimos utilizados en el documento, y para probar en
general, a fin de eliminar la confusión y promover la coherencia de las comunicaciones.
 PLAN MAESTRO DE PRUEBAS
DE MUESTRAS
1 PLAN DE PRUEBAS IDENTIFIER RS-MTP01.3
2 REFERENCIAS
Ninguno identificado.

3 INTRODUCCIÓN
Este es el Plan Maestro de Prueba para el proyecto de Reescritura de Ventas
Reasignadas. Este plan se ocupará sólo de los elementos y elementos relacionados
con el proceso de Ventas Reasignadas, tanto los elementos directa como
indirectamente afectados serán tratados. El objetivo principal de este plan es
asegurar que la nueva aplicación de Ventas Reasignadas proporcione el mismo nivel
de información y detalle que el sistema actual, permitiendo al mismo tiempo
mejoras y aumentos en la adquisición de datos y el nivel de detalles disponibles
(granularidad).
El proyecto tendrá tres niveles de prueba, Unidad, Sistema/Integración y Aceptación. Los
detalles de cada nivel se abordan en la sección sobre el enfoque y se definirán con más
detalle en los planes específicos de cada nivel.
El plazo estimado para este proyecto es muy agresivo (seis (6) meses), por lo que cualquier
retraso en el proceso de desarrollo o en la instalación y verificación del software de terceros
podría tener efectos significativos en el plan de pruebas. Se espera que la prueba de
aceptación tome un (1) mes a partir de la fecha de entrega de la aplicación de la prueba del
sistema y que se haga en paralelo con el proceso de aplicación actual.

4 ELEMENTOS DE PRUEBA
La siguiente es una lista, por versión y lanzamiento, de los artículos que se van a
probar:
A. Paquete EXTOL EDI, versión 3.0
Si hay una nueva versión disponible antes del lanzamiento, no se utilizará hasta después de
la instalación. Será un proyecto separado de actualización/actualización.
B. Paquete de transacciones DNS PC EDI, versión 2.2
Si hay una nueva versión disponible antes del lanzamiento, no se utilizará hasta después de
la instalación. Será un proyecto separado de actualización/actualización.
C. Paquete de transacciones EDI de PC personalizado (sólo dos distribuidores).
D. Nuevo software de ventas reasignado, la versión inicial será la 1.0
En el sistema y en los documentos de diseño detallados se proporcionará una lista
detallada de programas, bases de datos, pantallas e informes.
E. Orden de entrada del software de interfaz EDI, versión actual en el momento
del piloto. Actualmente, la versión 4.1.
F. Documento de requisitos del Sistema de Ventas Reasignado, SST_RQMT.WPD
versión 4.1
G. Documento de diseño del sistema de ventas reasignado, SST_SYSD.WPD versión
3.02
H. Reasignado Documento de Diseño de Detalle de Ventas, SST_DTLD.WPD versión 3.04
5 PROBLEMAS DE RIESGO DEL SOFTWARE
Hay varias partes del proyecto que no están bajo el control de la aplicación de Ventas
Reasignadas pero que tienen impactos directos en el proceso y deben ser revisadas también.
A. El proveedor local de AS/400 suministró el paquete de software EDI. Este paquete
proporcionará todo el soporte de reformateo desde los formatos ANSI X12 EDI a los
formatos de archivos de la base de datos interna del AS/400.
B. El paquete de software basado en PC instalado en la ubicación de cada distribuidor
(tanto el escrito personalizado como el suministrado por el proveedor)
proporcionará el formato de los datos de los distribuidores en los formatos EDI X12
correctos.
C. La copia de seguridad y la recuperación de los archivos de transmisión EDI, las
bases de datos locales y el reinicio del proceso de traducción, deben ser
cuidadosamente revisados.
D. La capacidad de reiniciar la aplicación en medio del proceso es un factor crítico
para la fiabilidad de la aplicación. Esto es especialmente cierto en el caso de los
archivos de transmisión, ya que una vez que los datos se extraen del buzón, ya no
están disponibles allí y deben ser protegidos localmente.
E. La seguridad y el acceso a la base de datos deben ser definidos y verificados,
especialmente para los archivos compartidos entre la aplicación de entrada de
pedidos y el proceso de ventas reasignadas. Toda la seguridad básica se
proporcionará a través del proceso de seguridad nativa de los sistemas AS/400.

6 CARACTERÍSTICAS A PROBAR
A continuación se enumeran las áreas en las que se debe centrar la atención durante el ensayo
de la aplicación.
A. Nuevo proceso de adquisición de datos EDI.
B. Rediseño de las pantallas en línea.
C. Informes rediseñados/convertidos.
D. Nuevo proceso de archivo automatizado.
E. Interfaz con el sistema de entrada de órdenes y las bases de datos.
F. Cálculo de la actividad de venta por región para las comisiones

7 CARACTERÍSTICAS QUE NO DEBEN SER PROBADAS

A continuación se enumeran las esferas que no se abordarán específicamente. Todas las
pruebas en estas áreas serán indirectas como resultado de otros esfuerzos de prueba.
A. Procesos de entrada de órdenes que no son de la EDI.
Sólo se verificará la interfaz EDI de la aplicación de entrada de pedidos. No se prevé
que los cambios en la interfaz EDI para apoyar las ventas reasignadas tengan un
impacto en la aplicación de Entrada de Pedidos. La Entrada de Pedidos es una
aplicación separada que sólo comparte la interfaz de datos, los pedidos seguirán
procesándose de la misma manera.
B. Seguridad de la red y acceso telefónico.

Los cambios para incluir las transacciones EDI para las ventas reasignadas no tendrán
ningún impacto en los aspectos de seguridad de la red o la interfaz EXTOL/EDI.
C. Aspectos operativos del proceso de EDI.
Los cambios para incluir las transacciones EDI para las ventas reasignadas no
afectarán a los aspectos operativos de la interfaz EXTOL/EDI.
 D. Aplicaciones de análisis de hojas de cálculo basadas en PC usando datos de Ventas
Reasignadas.
Estas aplicaciones están completamente bajo el control del cliente y están fuera del
alcance de este proyecto. La información necesaria del formato de la base de datos se
proporcionará a los clientes para que puedan extraer los datos. La prueba de sus
aplicaciones es responsabilidad del mantenedor/desarrollador de la aplicación.
E. El análisis de negocios funciona utilizando los datos de Ventas Reasignadas.
Estas aplicaciones están completamente bajo el control del equipo de apoyo a la
gestión y están fuera del alcance de este proyecto. La información necesaria sobre el
formato de la base de datos se facilitará al equipo de apoyo para que pueda extraer los
datos. El ensayo de sus aplicaciones es responsabilidad del encargado de
mantenerlas/desarrollarlas.
F. Procesos de comercialización/previsión utilizando datos de ventas reasignados.
Estas aplicaciones están completamente bajo el control de la comercialización y
están fuera del alcance de este proyecto. La información necesaria sobre el formato
de la base de datos se proporcionará a la comercialización para que puedan extraer
datos. El ensayo de sus aplicaciones es responsabilidad del encargado de su
mantenimiento/desarrollo.

8 ENFOQUE
8.1 Niveles de prueba
Las pruebas del proyecto de Ventas Reasignadas consistirán en niveles de prueba de Unidad,
Sistema/Integración (combinados) y Aceptación. Se espera que haya al menos una persona
independiente a tiempo completo para la prueba de sistema/integración. Sin embargo, con las
limitaciones presupuestarias y el calendario establecido, la mayor parte de las pruebas las
realizará el director de la prueba con la participación de los equipos de desarrollo.
Las pruebas de UNIT serán hechas por el desarrollador y serán aprobadas por el líder del
equipo de desarrollo. La prueba de la prueba de la unidad (lista de casos de prueba, salida de
muestras, impresiones de datos, información de defectos) debe ser proporcionada por el
programador al líder del equipo antes de que la prueba de la unidad sea aceptada y entregada
a la persona que realiza la prueba. Toda la información de la prueba unitaria también se
proporcionará a la persona de prueba.
SISTEMA/INTEGRACIÓN Las pruebas serán realizadas por el gerente de la prueba y el líder
del equipo de desarrollo con la asistencia de los desarrolladores individuales según sea
necesario. No hay herramientas de prueba específicas disponibles para este proyecto. Los
programas entrarán en la prueba de Sistema/Integración después de que todos los defectos
críticos hayan sido corregidos. Un programa puede tener hasta dos defectos importantes
siempre que no impidan la prueba del programa (es decir, hay un trabajo alrededor del error).
Las pruebas de aceptación serán realizadas por los usuarios finales reales con la ayuda del
director de la prueba y el líder del equipo de desarrollo. La prueba de aceptación se hará en
paralelo con el proceso manual existente de ZIP/FAX durante un período de un mes después
de la finalización del proceso de prueba del Sistema/Integración.
Los programas entrarán en la prueba de aceptación después de que todos los defectos
críticos y mayores hayan sido corregidos. Un programa puede tener un defecto importante
siempre que no impida la prueba del programa (es decir, que haya un trabajo para el error).
Antes de la finalización de la prueba de aceptación, todos los defectos críticos y mayores
abiertos DEBEN ser corregidos y verificados por el representante de pruebas del cliente.
Un número limitado de distribuidores participará en el proceso de prueba de aceptación
inicial. Una vez completada la prueba de aceptación, los distribuidores serán añadidos a
medida que su capacidad de generar los datos EDI requeridos sea verificada y comprobada
con sus datos de FAX/ZIP. Así pues, algunos distribuidores estarán en producción real y
otros en pruebas paralelas al mismo tiempo. Esto requerirá una cuidadosa
 coordinación de las tablas de control del sistema de producción para evitar la contabilización
de los datos de las pruebas en el sistema.

8.2 Gestión de la configuración/Control de cambios

El movimiento de programas desde la porción de desarrollo del sistema 'RED' a la porción de
prueba del sistema 'RED' se controlará a través del proceso de aplicación existente de Gestión
de Configuración, 'EXTRACTO'. Esto asegurará que los programas en desarrollo y los que
están en plena prueba tendrán los mismos controles de versión y seguimiento de los cambios.
El mismo proceso de extracción se utilizará para migrar los programas del sistema 'ROJO' de
desarrollo/prueba al sistema 'AZUL' de producción una vez que todas las pruebas se hayan
completado de acuerdo con los planes y directrices publicados.
Todas las pruebas de la unidad y del sistema inicial se realizarán en el sistema de
desarrollo AS/400 "RED". Una vez que el sistema haya alcanzado un nivel razonable de
estabilidad, sin defectos críticos o importantes pendientes, las pruebas piloto iniciales se
realizarán en el sistema AS/400 "AZUL" de producción. Todas las pruebas realizadas en
el sistema "AZUL" se harán en un modo paralelo con todos los controles establecidos
para evitar la actualización real de los archivos de producción.
Esto permitirá algunas pruebas tempranas de los números recibidos a través del antiguo
proceso ZIP/FAX y el mayor nivel de detalle recibido a través del nuevo proceso EDI. Esto
también ayudará a identificar posibles problemas en la comparación de los dos conjuntos de
números.
Todos los cambios, mejoras y otras solicitudes de modificación del sistema se tramitarán
mediante los procedimientos de control de cambios publicados. Toda modificación de los
procedimientos estándar se identifica en la sección de control de cambios del plan de
proyecto.

8.3 Herramientas de prueba

Las únicas herramientas de prueba que se usarán son las utilidades y comandos estándar del
AS/400.
A. El Administrador de Desarrollo de Programas (PDM) se utilizará como la
herramienta de gestión de la configuración de la versión fuente junto con la utilidad
de control de entrada y salida de la casa. La utilidad de control de entrada/salida es
parte del menú de acceso al AS/400 estándar de cada desarrollador.
B. Los prototipos iniciales para las nuevas pantallas se desarrollarán utilizando la
Ayuda para el Diseño de Pantallas AS/400 (SDA). El diseño inicial y el contenido
general de las pantallas se mostrarán al personal de administración de ventas antes
de proceder a las pruebas y el desarrollo de las pantallas.
C. Toda la edición, compilación y depuración se hará utilizando la Utilidad de
Entrada de Fuente (SEU).
D. La adquisición de datos será de los archivos de producción real cuando estén
disponibles usando el comando de copia de la base de datos AS/400 CPYF y sus
varias funciones. Se crearán datos adicionales y se modificarán según sea necesario
usando la Utilidad de Archivos de Datos (DFU). No se harán cambios en los
archivos de producción real bajo ninguna circunstancia.
E. Los datos iniciales para las pruebas de EDI se harán utilizando uno o dos sitios beta
y replicando los datos en la ubicación del buzón o localmente en los archivos de
control, para crear datos de alto volumen y simular múltiples distribuidores que
envíen datos.

8.4 Reuniones
El equipo de pruebas se reunirá una vez cada dos semanas para evaluar el progreso hasta la
fecha y para identificar las tendencias de error y los problemas lo antes posible. El líder del
equipo de prueba se reunirá con el desarrollo y el director del proyecto una vez cada dos
semanas también. Estas dos reuniones se programarán en semanas diferentes. Se pueden
convocar reuniones adicionales según sea necesario para situaciones de emergencia.
8.5 Medidas y métricas
El equipo de desarrollo recogerá la siguiente información durante el proceso de prueba de la
Unidad. Esta información será proporcionada al equipo de prueba en el momento de la
rotación del programa, así como al equipo de proyecto cada dos semanas.
1. Defectos por módulo y gravedad.
2. Origen del defecto (requisito, diseño, código)
3. Tiempo dedicado a la resolución de defectos por defecto, sólo para Crítico y Mayor.
Todos los defectos menores pueden ser sumados.
La siguiente información será recogida por el equipo de prueba durante todas las fases de la
prueba. Esta información se proporcionará cada dos semanas al director de la prueba y al
equipo del proyecto.
1. Defectos por módulo y gravedad.
2. Origen del defecto (requisito, diseño, código)
3. Tiempo dedicado a la investigación defecto por defecto, sólo para Crítico y
Mayor. Todos los defectos menores pueden ser sumados.
4. Número de veces que un programa presentado al equipo de prueba está listo para la
prueba.
5. Defectos localizados en niveles más altos que deberían haber sido detectados
en niveles más bajos de pruebas.

9 CRITERIOS DE APROBACIÓN O RECHAZO DE ARTÍCULOS

El proceso de prueba se completará una vez que el conjunto inicial de distribuidores
haya enviado con éxito los datos de ventas reasignados por un período de un mes y
los nuevos datos de EDI se equilibren con los antiguos datos ZIP/FAX recibidos en
paralelo. Cuando el personal de administración de ventas esté satisfecho de que los
datos son correctos, el conjunto inicial de distribuidores se pondrá en activo y se
detendrá todo el paralelismo para esas cuentas.
En este momento el siguiente grupo de distribuidores comenzará el proceso paralelo, si no lo
está haciendo ya. Sólo el conjunto inicial de distribuidores debe pasar la prueba de
comparación de datos para completar la prueba, en ese momento la aplicación se considera
en vivo. Todas las activaciones adicionales se realizarán en el momento en que estén listas.
Cuando un distribuidor esté listo, y se verifiquen sus datos, entonces también se activarán.
10 CRITERIOS DE SUSPENSIÓN Y REQUISITOS DE
REANUDACIÓN
A. No hay distribuidores listos para la prueba en la iniciación del piloto.
El proyecto piloto se retrasará hasta que al menos tres distribuidores estén listos para iniciar
el proceso piloto. No se añadirán elementos adicionales al proyecto de Ventas Reasignadas
durante este retraso.
B. No hay disponibilidad de dos buzones de EDI.
En caso de que no se puedan obtener dos líneas de producción e instalaciones de buzones, se
seguirá utilizando la actual línea de producción y buzones hasta que se disponga de una
segunda línea. Esto requerirá una cuidadosa coordinación entre el departamento de Entrada de
Pedidos y el grupo de Ventas Reasignadas.
C. Distribuidor de software de EDI de PC retrasos.
En caso de que se produzca un retraso en la entrega o la disponibilidad del paquete de
programas informáticos para PC, el único retraso importante será el de las pruebas piloto.
Las pruebas de unidad, integración y sistemas pueden continuar utilizando datos limitados
hasta que el software de PC esté listo.
Esto también añadirá tiempo a los niveles más bajos de pruebas, ya que no se pueden hacer
pruebas completas sin cantidades razonables de datos. Los datos sólo pueden derivarse de las
transmisiones reales del paquete de software para PC.

11 ENTREGAS DE PRUEBA
Plan de pruebas de aceptación
Plan de pruebas de sistema/integración
Planes de pruebas de la
unidad/documentación de la facturación
Prototipos de pantalla
Reportar maquetas
Informes y resúmenes de
defectos/incidentes Registros de pruebas e
informes de rotación

12 LAS TAREAS DE PRUEBA RESTANTES

TARE Asignado a Estado

A
Crear un plan de pruebas de aceptación TM, PM, Cliente

Crear un plan de pruebas de TM, PM, Dev.

sistema/integración
Definir las reglas y procedimientos de la TM, PM, Dev.
prueba unitaria
Definir los procedimientos de rotación para TM, Dev
cada nivel
Verificar los prototipos de las pantallas Dev, Cliente, TM

Verificar los prototipos de los informes Dev, Cliente, TM

13 NECESIDADES AMBIENTALES
Los siguientes elementos son necesarios para apoyar el esfuerzo general de pruebas a
todos los niveles dentro del proyecto de ventas reasignado:
A. Acceso a los sistemas AS/400 tanto de desarrollo como de producción. Para el
desarrollo, la adquisición de datos y las pruebas.
B. Una línea de comunicación con el buzón de EDI. Esta tendrá que ser una línea
compartida con el proceso de Entrada de Pedidos ya que sólo se utiliza un buzón.
Tendrá que haber un esfuerzo coordinado para determinar la frecuencia con la que
se debe sondear el buzón, ya que el proceso de entrada de pedidos requiere que se
acceda a los datos cada hora y el proceso de ventas realmente sólo necesita ser
tirado una vez al día.
C. Una copia instalada y funcional del paquete de proveedores de EDI basado en AS/400.
D. Al menos un distribuidor con una copia instalada del paquete de vendedores de
EDI basado en PC para datos de ventas.
E. Acceso a las tablas de control maestro (bases de datos) para controlar el entorno de
producción/ensayo en los sistemas de producción y desarrollo.
F. Acceso al proceso de respaldo/recuperación nocturno.

14 NECESIDADES DE PERSONAL Y CAPACITACIÓN

Es preferible que se asigne al menos un (1) probador a tiempo completo al
proyecto para las fases de prueba del sistema/integración y aceptación del
proyecto. Esto requerirá la asignación de una persona a tiempo parcial al comienzo
del proyecto para que participe en las revisiones, etc... y aproximadamente a los
cuatro meses de iniciado el proyecto se le asignará a tiempo completo. Si no se
dispone de una persona de prueba separada, el director del proyecto/director de
pruebas asumirá esta función.
A fin de proporcionar pruebas completas y adecuadas, es necesario abordar las siguientes
áreas en lo que respecta a la capacitación.
A. Los desarrolladores y probadores deberán ser entrenados en las operaciones básicas
de la interfaz de EDI. Antes de la aceptación final del proyecto, el personal de
operaciones también necesitará una capacitación completa en el proceso de
comunicaciones del EDI.
B. El personal de administración de ventas requerirá capacitación en las nuevas pantallas
e informes.
C. Al menos un desarrollador y un miembro del personal de operaciones necesita ser
entrenado en la instalación y control del paquete EDI de los distribuidores
basados en PC. El personal de los distribuidores también tendrá que ser
capacitado en el paquete basado en PC y sus características operativas.
15 RESPONSABILIDADES

TM PM Equi Equi Client

po de po de e
desar prue
rollo ba
Prueba de aceptación Documentación y ejecución X X X X
Prueba de sistema/integración Documentación y X X X
ejecución
Documentación y ejecución de pruebas de la X X X
unidad
Revisiones del diseño del sistema X X X X X
Reseñas de diseño detallado X X X X
Procedimientos y reglas de prueba X X X X
Revisiones de prototipos de Screen & Report X X X
Control de cambios y pruebas de regresión X X X X X

El jefe del equipo de desarrollo será responsable de la verificación y aceptación de todos los
planes de prueba y documentación de la unidad.
El director de proyecto/director de pruebas es responsable de todos los planes y
documentación de las pruebas.
Todo el equipo del proyecto participará en el examen de los diseños del sistema y de los
detalles, así como en el examen de cualquier solicitud de cambio que sea generada por el
usuario o como resultado de defectos descubiertos durante el desarrollo y las pruebas.
También se requiere que el personal de administración de ventas participe en el examen
inicial de alto nivel del sistema.
El personal de administración de ventas proporcionará una persona, según sea necesario,
durante todo el proyecto para verificar los resultados de las pruebas y responder a las
preguntas que surjan. Esta persona también será responsable de participar en la ejecución del
plan de pruebas de aceptación.

16 HORARIO
En el plan del proyecto se ha asignado tiempo para las siguientes actividades de ensayo. Las
fechas y horas específicas de cada actividad se definen en el calendario del plan de proyecto.
Las personas necesarias para cada proceso se detallan también en el calendario y el plan del
proyecto. La coordinación del personal necesario para cada tarea, equipo de prueba, equipo
de desarrollo, dirección y cliente será llevada a cabo por el gerente del proyecto junto con los
jefes de los equipos de desarrollo y de prueba.
A. Revisión del documento de requisitos por el personal del equipo de prueba (con
otros miembros del equipo) y creación inicial de clases, subclases y objetivos de
inventario.
B. Elaboración del plan maestro de pruebas por el director de la prueba y la prueba
 con el tiempo asignado para al menos dos revisiones del plan.
C. Revisión del documento de diseño del Sistema por el personal del equipo de
pruebas. Esto proporcionará al equipo una comprensión más clara de la estructura
de la aplicación y definirá con más detalle las clases, subclases y objetivos del
inventario.
 D. Elaboración de planes de pruebas de sistema/integración y aceptación por parte
del director de la prueba y otro personal esencial con tiempo asignado para al
menos dos revisiones de los planes.
E. Revisión de los documentos de diseño detallados por el personal del equipo de
pruebas, según sea necesario. Esto proporcionará al equipo una comprensión más
clara de la estructura del programa individual y definirá con más detalle las clases,
subclases y objetivos del inventario.
F. Tiempo de prueba de la unidad dentro del proceso de desarrollo.
G. El tiempo asignado para los procesos de prueba del Sistema/Integración y Aceptación.

17 PLANIFICACIÓN DE RIESGOS Y CONTINGENCIAS

A. Personal de ventas reasignado limitado.

El personal de administración de ventas reasignado tiene actualmente dos puestos

vacantes. Como resultado de esta escasez de personal puede haber demoras para que
el personal revise los documentos apropiados y participe en el proceso de prueba de
aceptación. Si el personal del cliente se convierte en un problema, las fechas
apropiadas para las revisiones y las pruebas de aceptación se deslizarán en
consecuencia. No se intentará eludir ninguna parte de los procesos de revisión y
pruebas.
Sin embargo, si es aceptable para el administrador del personal de ventas reasignado, un
miembro del equipo de pruebas puede estar disponible para actuar como representante del
cliente para parte de la prueba de aceptación en sí. Las revisiones de las pantallas e
informes deben tener la participación y aprobación del cliente.

18 APROBACIONES
Patrocinador del proyecto - Steve Sponsor

Gestión de Desarrollo - Gerente de Ron

Gerente de Proyectos EDI - Proyecto Peggy

Gerente de pruebas de RS - Dale Tester

Gerente del equipo de desarrollo de RS - Dale Tester

Ventas Reasignadas - Cathy Sales

Entrada de la orden Gerente del equipo EDI - Julie

Order