Departamento de

Control de Calidad

Plan Maestro de Pruebas:

[Nombre completo del
sistema] ver [no. versión]

ID Documento: [Nombre corto]_[Ver]_PMP

Versión del Documento: [Ver]

 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

Control de Versiones

Documento Nuevo
No. Fecha de
Autor Puesto Descripción
Ver emisión
Versión inicial

Historia de Cambios
No. Fecha de Resumen de cambios Cambios marcados
Rev revisión

Revisiones y Aprobaciones
Este documento requiere la revisión y aprobación de las siguientes personas.
Nombre

Distribución
Este documento será distribuido a:
Nombre

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]

Pág. 2 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

Tabla de Contenido
1. Introducción
1.1. Compromisos organizacionales
1.2. Alcance del proyecto.
1.3. Alcance del plan.
1.4. Relación con otros planes
1.5. Stakeholders
1.6. Metodología, Técnicas y Herramientas
1.7. Material de referencia

2. Objetivos y Factores de Motivación de Pruebas

2.1. Misión.
2.2. Elementos a probar
2.2.1. Aspectos técnicos.
2.2.2. Aspectos funcionales.
2.3. Elementos que no serán sujetos a prueba.
2.3.1. Aspectos técnicos
2.3.2. Aspectos funcionales

3. Estrategia de prueba
3.1. Prueba Funcional por Unidades (Cobertura)
3.2. Prueba de Integración (Cobertura)
3.3. Pruebas de Verificación
3.4. Pruebas Automatizadas
3.5. Pruebas de Tecnología
3.6. Pruebas de Aceptación
3.7. Prueba de Documentación del sistema

4. Criterios de aceptación /rechazo de “elementos” de prueba.

5. Criterios de suspensión de prueba y condiciones para

reanudarla.

6. Administración del proyecto

6.1. Cobertura de prueba.
6.2. Administración de Cambios.
6.2.1. Administración del cambio de versiones.
6.2.2. Administración de la implementación de cambios en el sistema.
6.3. Colección y Validación de Métricas.
6.4. Juntas, reportes y comunicaciones.
6.5. Entregables de prueba.
6.6. Otros tópicos

7. Requerimientos de ambiente
7.1. Requerimientos de Hardware
7.2. Requerimientos de software
7.3. Comunicaciones
7.4. Configuración de ambientes de pruebas
7.5. Documentación
Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]
Pág. 3 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

7.6. Instalaciones
7.7. Consumibles

8. Necesidades de personal
8.1. Definición del equipo de trabajo requerido
8.2. Distribución del trabajo
8.2.1. Definición de roles y responsabilidades
8.2.2. Asignación de tareas
8.2.3. Capacitación

9. Programa de actividades de prueba.

10. Planeación de riesgos

10.1. Dependencias.
10.2. Restricciones
10.3. Recursos Humanos

11. Planes de contingencia

12. Aprobaciones.

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]

Pág. 4 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

1. Introducción
1.1. Compromisos organizacionales

Visión de la Desarrollo y comercialización de sistemas de cómputo y servicios

Empresa:
Misión de la Ofrecer a nuestros clientes un servicio oportuno, eficiente y certero
Empresa: con nuestros productos para cumplir ampliamente sus necesidades,
a través de nuestra gente.
Valores de la Honestidad, Tiempo, Participación, Empeño, Trabajo, Disposición,
Empresa: Humildad, Objetividad, Puntualidad, Positivismo, Constancia,
Respecto, Entusiasmo, Mente abierta, Compromiso, Autenticidad y
Congruencia.

Objetivo [Especificar los objetivos planteados por la Dirección General para

General del el proyecto]
Proyecto:
Objetivos
Específicos del
Proyecto:

1.2. Alcance del proyecto.

[Se debe dar una descripción básica del alcance de la nueva versión, incluyendo
características principales, historia, etc. Debe incluir sentencias como por ejemplo: “Este
proyecto cubrirá todas las características actualmente en uso en SAE 4.5, más __
funciones nuevas y __ funciones mejoradas...”]

1.3. Alcance del plan

[Descripción de los tipos de prueba a que serán utilizados. Debe hacer especificaciones
como por ejemplo: “Este Plan Maestro de Prueba cubre las pruebas de integración,
funcionales y de aceptación, pero no las pruebas unitarias, dado que estas pruebas están
siendo realizadas por el equipo de pruebas internas”. También se debe mencionar si es
un solo plan de pruebas o existen varios (uno por cada nivel o tipo de prueba).]

1.4. Relación con otros planes

[Si se deciden desarrollar planes de prueba específicos, hay listarlos en esta parte]

1.5. Stakeholders principales

[Los stakeholders son todas aquellas personas que afectan o son afectados por el
proyecto y que pueden ejercer cierta influencia sobre él, pero que no están directamente
involucrados con la ejecución del trabajo. ]

Nombre Área - Responsabilidades, Necesidades o

Puesto Expectativas

1.6. Metodología, Técnicas y Herramientas

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]
Pág. 5 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

1.6.1. Resumen de la Metodología

[Enunciar brevemente los pasos de la metodología a utilizar]

1.6.2. Resumen de Técnicas de prueba

[Enunciar brevemente las técnicas de prueba a utilizar]

1.6.3. Herramientas de control

[Hacer una lista de las herramientas que se requieren para el control del
proyecto]

Herramienta Descripción

1.7. Material de referencia

[Hacer una lista de todos los documentos y fuentes de información a los que se hacen
referencia en todo el PMP]

Documento Tipo Descripción Ubicación

2. Objetivos y Factores de Motivación de Pruebas

2.1. Misión.
[Proporciona una breve descripción que define la misión para el esfuerzo de prueba. Esta
descripción puede incorporar una o más preocupaciones como:
 Encontrar los errores que sea posible
 Encontrar los problemas importantes
 Evaluar si los riesgos percibidos han sido mitigados
 Certificar un estándar
 Verificar una especificación (requerimientos, diseño o pretensión)
 Notificar acerca de la calidad del producto
 Buscar la aceptación o validar las expectativas de la empresa
La misión debe proveer el contexto en el que el esfuerzo de prueba debe ser realizado]

2.2. Elementos a probar

2.2.1. Aspectos técnicos.
[Qué es lo que se deberá probar desde el punto de vista técnico. Este punto debe
ser completado en colaboración con los líderes de librerías y de desarrollo y con
la experiencia en prueba de CdC.]

2.2.2. Aspectos funcionales

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]

Pág. 6 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

[Qué es lo que se deberá probar desde el punto de vista del usuario. Este punto
debe ser completado en colaboración con el área de soporte técnico y con la
experiencia en prueba de CdC.]

2.3. Elementos que no serán sujetos a prueba.

[Esta sección puede hacer abrir los ojos a personas externas al equipo de pruebas,
quienes no pueden concebir que concientemente se decida no probar una
características, por lo cual se debe ser muy cuidadoso en la documentación de las
razones por las que se decide no probar una característica en particular. Sin embargo,
estas mismas personas pueden aprobar calendarios que no permiten probar todo, por lo
que esta sección trata de elegir inteligentemente qué no probar (que deben ser SIEMPRE
características de bajo riesgo) en lugar de sólo dejar que pase el tiempo y no probar lo
que sea que “toque” en la fecha de liberación.]

2.3.1. Aspectos técnicos

[Registro de cualquier aspecto técnico que no será probado y por qué.]

2.3.2. Aspectos funcionales

[Registro de cualquier característica funcional que no será probada y por qué.]

3. Estrategia de prueba
[Esta sección debe contener una descripción de cómo se ejecutará la revisión del sistema
con base en los tipos de prueba establecidos en la metodología de la empresa.]

3.1. Prueba Funcional por Unidades (Cobertura)

3.1.1. Pruebas de Funciones Administrativas.
3.1.2. Pruebas de Funciones Generales de la línea

3.2. Prueba de Integración (Cobertura)

3.2.1. Pruebas de Interacción del sistema
3.2.2. Pruebas de Interfaces Aspel
3.2.3. Pruebas de Interoperabilidad
3.2.4. Pruebas de Red

3.3. Pruebas de Verificación

3.3.1. Pruebas de Regresión
3.3.2. Pruebas de Cierre y Liberación

3.4. Pruebas Automatizadas

3.4.1. Pruebas de Desempeño y Volumen
3.4.2. Pruebas de Stress
3.4.3. Baterías de Prueba

3.5. Pruebas de Tecnología

3.5.1. Pruebas de compatibilidad
3.5.2. Pruebas de Instalación
3.5.3. Pruebas de seguridad

3.6. Pruebas de Aceptación

3.6.1. Pruebas de Producto
Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]
Pág. 7 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

3.6.2. Pruebas de Versiones Anteriores

3.6.3. Pruebas de Soporte Técnico
3.6.4. Pruebas Alfa
3.6.5. Pruebas Beta

3.7. Prueba de Documentación del sistema

3.7.1. Prueba Estática
3.7.2. Prueba Dinámica

4. Criterios de aceptación y/o rechazo

de “elementos” de prueba.
[En este punto se describen los criterios de Aceptación/rechazo de cada elemento item
descrito en la Sección 2.2 “Elementos a probar”. Así como cada caso de prueba necesita un
resultado esperado, cada elemento de prueba necesita un resultado esperado. Típicamente
los criterios de aceptación/rechazo se expresan en términos de porcentajes de casos de
prueba exitosos, número, severidad y localización de errores, cobertura de los casos de
prueba, conclusión exitosa de pruebas de usuario, completitud de documentación, criterios
de desempeño. ]

5. Criterios de suspensión de prueba y

condiciones para reanudarla.
[En esta sección se debe identificar cualquier condición que justifique una suspensión
temporal de prueba y el criterio para reanudarla. Esto para evitar que se lleve a cabo trabajo
que no remunerará los resultados esperados por no realizarse contando con las condiciones
necesarias para ello. Las métricas pueden ser establecidas como bandera que señale una
condición que justifica suspender la prueba. Por ejemplo, si se encuentra un número
predeterminado de errores de cierta severidad, la prueba debería pararse hasta que se
pueda determinar si se va a rediseñar una parte del sistema, si se intentará una estrategia
alternativa o si se tomará alguna otra acción.]

6. Administración del proyecto

6.1. Cobertura de prueba.
[Hay diversos tipos de medidas de cobertura que se utilizan en la prueba del software.
Las hay a través de herramientas especializadas, las cuales miden el porcentaje de
sentencias de programa o caminos ejecutados por un conjunto de prueba (grupo de
casos de prueba). También se pude medir la cobertura de requerimientos, diseños y de
interfases. La cobertura de requerimientos mide el porcentaje de requerimientos de
negocio que son cubiertos por un conjunto de prueba, mientras que la de diseños mide
cuánto del diseño está cubierto. La cobertura de interfase mide el porcentaje de
interfases que son ejecutadas por un conjunto de pruebas.]

6.2. Administración de Cambios.

6.2.1. Administración del cambio de versiones.
[Es importante porque es crítico mantener el seguimiento de la versión del
software a liberar y de los documentos relacionados que son probados. En esta
sección se debe enunciar en que se llevará a cabo esta administración.]
Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]
Pág. 8 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

6.2.2. Administración de la implementación de cambios en

el sistema.
[Se debe enunciar la forma en que se organizará el equipo de CdC y el de
sistema en los diferentes niveles y tiempos de prueba para revisar, priorizar,
arreglar y re-probar errores corregidos. Por ejemplo, en un inicio se arreglarán
TODOS los errores reportados. En un punto intermedio, se arreglarán únicamente
errores autorizados por la Gerencia de CdC. En un punto próximo de liberación,
sólo se arreglarán errores autorizados por la Gerencia de CdC y la Dirección de
Sistemas]
6.3. Colección y Validación de Métricas.
[Todos los esfuerzos de prueba necesitan una forma de medir el estado de la prueba, la
efectividad de la prueba, calidad del software, cumplimiento de calendario, etc.]

6.4. Juntas, reportes y comunicaciones.

[Principalmente para el reporte de Estatus de la prueba. Se deben indicar detalles
relativos a la frecuencia de las reuniones, el formato, las métricas a utilizar para
monitorear y comunicar resultados. Asimismo, la línea de comando y qué hacer para
resolver conflictos].

6.5. Entregables de prueba.

[Listado de todos los documentos, herramientas y otros componentes que van a ser
desarrollados y mantenidos para soportar el esfuerzo de la prueba. Incluye planes de
prueba, diseños de prueba, casos de prueba, reportes de defectos, reportes de
resúmenes de prueba, datos de prueba....
Los artefactos que soportan el esfuerzo de prueba necesitan ser identificados a lo largo
de todo el proyecto como entregables, y deben tener asignados los recursos apropiados
para el seguimiento del proyecto. Esto asegurará que el proceso de prueba tenga
visibilidad en todo el proceso de seguimiento del proyectos y que las actividades de
prueba usadas para la creación de estos entregable son comenzadas en el tiempo
apropiado.]

6.6. Otros tópicos

[Cualquier cosa que tenga un impacto significante en la efectividad o costo de la prueba
es candidata a incluirse en esta sección.]

7. Requerimientos de ambiente
[Esta sección presenta los recursos no humanos requeridos para el plan de prueba]

7.1. Requerimientos de Hardware

[Plataformas, impresoras, scanners, modems..]

7.2. Requerimientos de software

[Software requerido para montar el ambiente de prueba] (Sistemas operativos, base de
datos de prueba)
7.3. Comunicaciones
[Gateways, conexiones, autorizaciones, protocolos]

7.4. Configuración de ambientes de pruebas

[Configuración estándar, configuración mínima, red inalámbrica, VPN, Conexión
remota...]

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]

Pág. 9 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

7.5. Documentación
[Requerimientos, Diseños, Operaciones del usuario]

7.6. Instalaciones
[Lugar, espacio, seguridad, infraestructura]

7.7. Consumibles
[Formas, papel]

8. Necesidades de personal

8.1. Definición del equipo de trabajo requerido

[Esta sección del plan describe el número de personas requeridas para el proyecto y las
habilidades que deben tener. En algunos casos se requerirán analistas de prueba y en
otros sólo “testers”]

8.2. Distribución del trabajo

8.2.1. Definición de roles y responsabilidades
[Si ya se tiene a alguien en mente, se recomienda establecer los requerimientos
incluyendo específicamente a la persona. Se recomienda presentarlo a través de
una matriz que muestre las responsabilidades más importantes tales como el
establecimiento del ambiente de prueba, administración de la configuración,
división de pruebas, etc. ]
8.2.2. Asignación de tareas
8.2.3. Capacitación
[Con relación a las necesidades de capacitación, se puede incluir entrenamiento
en cómo usar una herramienta en particular, metodologías de prueba, sistemas
de administración como Mantis, administración de la configuración o
conocimiento básico del negocio relacionado con el sistema a probar]

9. Programa de actividades de prueba.

[El programa de prueba debe ser generado con base en los milestones del Proyect, tales
como fechas de entrega de documentos, módulos, disponibilidad de recursos, interfaces, etc.
También hay que agregar los milestones de prueba, tales como revisiones de requerimientos
y diseños, entrega de código, término de manuales, disponibilidad de interfases.]

10. Planeación de riesgos

10.1. Dependencias.
[Enumerar cualquier dependencia identificada durante el desarrollo del plan de
pruebas que puede afectar su ejecución si esas dependencias no se cumplen.
Dentro de las más comunes se encuentran:
 Funciones terminadas a cierta fecha (Fechas de entrega que no se cumplen)
Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]
Pág. 10 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc
 Control de Calidad:
PMP de: [Nombre corto sistema y versión]

 Disponibilidad de la gente (plan de contratación autorizado)

 Opciones de ambientes entregadas a tiempo (infraestructura: hardware, red,
sistemas operativos....)
 Necesidades de entrenamiento cubiertas a una fecha (nueva funcionalidad)]

Dependencia con otras áreas Impacto potencial de Responsables

dependencia

10.2. Restricciones
[Enumerar cualquier restricción puesta en el esfuerzo de prueba que haya tenido
un efecto negativo en la manera en que se ha planeado la estrategia de prueba]

10.3. Recursos Humanos

[Disponibilidad de la gente –plan de contratación autorizado-, permanencia de la
gente, incapacidades...]

11. Planes de contingencia

[Como posibles contingencias se encuentran:
 Reducción del alcance de la aplicación (recorte de alcances)
 Retraso en la implementación (entrega de funcionalidad en partes)
 Recursos adicionales (más gente)
 Reducción del proceso de calidad (menos prueba)]

12. Aprobaciones.
[Dependiendo del tipo de aprobaciones que se requieran para la definición, desarrollo y/o
finalización del Plan, se deberá hacer un listado de las personas que tengan la autoridad
para dar el Vo.Bo a cada una de las fases requeridas. Por ejemplo:
 Aprobación del PMP
 Aprobación de las especificaciones del PMP que tienen que ver con el
trabajo con otras áreas:
 Criterios de aceptación/rechazo de “elementos” de prueba.
 Criterios de suspensión de prueba y condiciones para reanudarla.
 Requerimientos del ambiente de prueba]

Elaborado por: [Nombre autor] F. Elaboración: [dd/mes/aaaa] Ver: [No.Ver]

Pág. 11 de 11
Modificado por: [Nombre quien modifca] F. Modificación: [dd/mes/aaaa]
Ubicación del archivo:/conversion/tmp/scratch/459876437.doc