Nombre del departamento o

programa
[ NOMBRE DEL SISTEMA/APLICACIÓN ]

Seguro de calidad
Plan de prueba
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Plan de prueba/control de calidad del proyecto

Directrices de plantilla

Para ayudar en la creación de un plan de prueba/control de calidad del proyecto completado con éxito, revise las
siguientes pautas. Para obtener instrucciones e información adicionales, consulte la Oficina de Gestión del
Programa de Servicios Universitarios. Elimine estas pautas del documento completo .

Objetivo El plan de pruebas/control de calidad del proyecto es un plan general que abarca todas las
pruebas necesarias para un proyecto. Es el plan de prueba de más alto nivel que documenta
la estrategia de prueba para el proyecto, describe el enfoque general que se adoptará en las
pruebas, proporciona la estructura y filosofía generales para cualquier otro documento de
prueba requerido y define qué se probará para asegurar los requisitos. del producto, servicio
o sistema (es decir, los entregables).
Según el tamaño, la complejidad y el tipo de proyecto, se pueden crear y utilizar planes de
prueba posteriores durante el proceso de prueba para verificar que el entregable funcione
correctamente, sea comprensible y esté conectado lógicamente. Estos planes de prueba
incluyen las siguientes categorías y tipos. Las áreas/coordinadores de pruebas tendrían
plantillas específicas para estos planes.

Los tipos de planificación de garantía de calidad incluyen:

 Los planes de control de calidad del proceso documentan cómo el proyecto cumple con
los estándares de calidad y cumplimiento, asegurando que exista la documentación
correcta para guiar la ejecución del proyecto y las acciones correctivas, y
 Los planes de prueba de requisitos/aplicaciones documentan cómo el producto,
servicio o sistema cumple con los requisitos comerciales y técnicos establecidos, y cómo
funcionará dentro de los procesos operativos/comerciales y el flujo de trabajo definidos.

Los planes de prueba que normalmente se utilizan para los esfuerzos de desarrollo incluyen:
 Los planes de prueba unitaria (UT ) documentan lo que el programador está codificando
para una pantalla o unidad en particular.
 El Plan de pruebas de sistemas integrados ( IST ) documenta cómo se probará el
sistema para garantizar que se solucionen los errores principales y cómo se realizarán las
pruebas de un extremo a otro entre aplicaciones únicas.
 Los planes de prueba de aplicaciones de integración (IAT ) documentan cómo las
aplicaciones probarán de un extremo a otro todas las funciones nuevas en todas las
aplicaciones.
 La prueba de aceptación del usuario ( UAT ) documenta cómo los usuarios, que
admitirán la funcionalidad nueva y existente en producción, probarán esta nueva
funcionalidad antes de la instalación en producción.
 El Plan de prueba de preparación de la interfaz de operaciones ( OIR ) documenta cómo
el usuario de operaciones probará todas las funciones nuevas y existentes.

Los enfoques de prueba que pueden usarse para probar o validar proyectos que tienen alto
riesgo o impacto incluyen:
 Las pruebas de regresión garantizan que todas las correcciones identificadas durante
IAT y UAT se realizaron en el sistema y no afectaron la funcionalidad clave existente
(utilizada principalmente con nuevos proyectos importantes de desarrollo de software) .
 La prueba de aplicación de integración de conversión se utiliza para simular los
primeros días de procesamiento después de una conversión.
 Un prototipo es una técnica utilizada en la etapa de diseño, construcción o prueba para
construir un modelo del producto, servicio o sistema para verificar una función, un
diseño, cómo funciona un módulo o programa en particular, etc.
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

 La prueba de concepto se utiliza para probar una idea en un entorno controlado para
probar nuevas funciones.
 Alpha Testing prueba un nuevo producto, servicio o sistema antes de su
implementación, donde puede tener impactos importantes y el equipo del proyecto
quiere identificar problemas/errores importantes antes de la implementación (o entra
en producción).
 Beta Testing se diferencia de Alpha Testing en la cantidad de pruebas y limpieza que se
deben realizar. El proyecto debe estar listo para su implementación.
 Piloto es un uso limitado del producto, servicio o sistema por parte de un sitio remoto,
un subconjunto de la base de clientes, etc. Esta técnica de prueba se utiliza para
resolver problemas logísticos, validar el entregable y minimizar el impacto de una
implementación limitada.
 Las pruebas paralelas ocurren cuando el producto, servicio o sistema antiguo y nuevo se
ejecutan simultáneamente para permitir que el cliente del proyecto verifique que el
entregable funciona según las especificaciones.
 Las pruebas de estrés/carga garantizan que el sistema funcionará de manera confiable
durante la producción completa y cargas de trabajo pesadas.
 Las pruebas de preparación operativa/empresarial recorren los procesos y flujos de
trabajo operativos/empresariales para garantizar que los procedimientos, la
documentación, la conciliación, la formación y los flujos de trabajo estén completos y
sean correctos.

Propiedad El Gerente de Proyecto es responsable de garantizar que se creen todos los planes de prueba
y los identifica bajo un plan general (es decir, el Plan Maestro de Calidad/Prueba del
Proyecto). Los líderes del equipo de pruebas del proyecto desarrollan los planes de pruebas
posteriores necesarios.

Cuando El plan de pruebas y control de calidad del proyecto se completa durante la fase de diseño del
Fase: Diseño ciclo de vida de entrega de la solución. Debe actualizarse cada vez que información adicional
Etapa: o cambios en el proyecto afecten su contenido.
Planificación
Es un entregable obligatorio en proyectos grandes y medianos, y una mejor práctica en
proyectos Fast Track. Para obtener orientación adicional, la Hoja de trabajo de clasificación
de proyectos está disponible.
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Finalización de 1. No incluya las pautas de la plantilla en su documento final. Ingrese la información del
plantilla proyecto en el encabezado y pie de página, la página de título y los contribuyentes del
Nota: El texto documento y el control de versiones.
entre corchetes < 2. Complete el documento utilizando el texto sugerido cuando corresponda e ingresando
> debe texto/campos donde se muestran entre corchetes <texto azul> . Tenga en cuenta que el
reemplazarse con texto azul NO debe incluirse en su documento final. Su propósito es proporcionar
información orientación para completar el documento o mostrar dónde se deben ingresar el texto o
específica del los campos.
proyecto. 3. Una vez que haya realizado los cambios en su documento y esté listo para finalizar,
asegúrese de actualizar la sección Tabla de contenido (TOC). Para actualizar el TOC : si
no está seguro de cómo hacer esto, coloque la flecha del mouse a la izquierda de la
primera entrada en la sección Tabla de contenido y haga clic en el botón izquierdo una
vez. Una vez que toda la sección esté resaltada, mueva la flecha del mouse a cualquier
lugar dentro de la sección resaltada y haga clic en el botón derecho una vez. En el menú
desplegable, elija Actualizar campo y números de página únicamente o Campo
completo, según sea necesario. Tenga en cuenta que es posible que deba repetir los
pasos mencionados anteriormente para volver a cambiar la fuente a Tahoma 10 pt.
4. El Plan Maestro de Pruebas debe conservarse junto con otra documentación relacionada
con el proyecto y mantenerse de acuerdo con la política de retención de registros de la
línea de negocio.

Empoderamiento Esta plantilla se proporciona como una guía a seguir para producir la información básica
y escalabilidad mínima necesaria para completar con éxito un plan de prueba/control de calidad del proyecto
cumpliendo con las pautas de la PMO e ilustra el arte y la ciencia de la gestión de proyectos.
Los gerentes de proyecto están autorizados a utilizar esta plantilla según sea necesario para
abordar cualquier requisito específico del proyecto propuesto en cuestión. La cantidad de
detalles incluidos en la plantilla dependerá del tamaño y la complejidad del proyecto.

Noticia Como esta plantilla puede cambiar, se recomienda encarecidamente que acceda a una
importante plantilla en blanco desde el sitio web de la Oficina de Gestión de Programas (
http://www.uservices.umn.edu/pmo/ ) cada vez que necesite una para un nuevo proyecto y
no simplemente use uno de un proyecto anterior cambiando el texto antiguo.
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

INFORMACIÓN Y APROBACIONES DE DOCUMENTOS

HISTORIAL DE VERSIONES
Versión # Fecha Revisado por Razón para el cambio
1.0 4/27/12 Aaron De Menge Revisión de la PMO

APROBACIONES DE DOCUMENTOS
Nombre del aprobador Rol del proyecto Firma/Aprobación Electrónica Fecha
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

TABLA DE CONTENIDO
Introducción................................................................................................................... 1
Alcance.................................................................................................................................................... 1
Objetivos de la prueba............................................................................................................................ 1
Objetivos de prueba................................................................................................................................ 1
Calidad................................................................................................................................................ 1
Fiabilidad............................................................................................................................................. 2

Garantía de calidad del proyecto..................................................................................2

Documentos requeridos para el proyecto de vía rápida..........................................................................2

Metodología de prueba..................................................................................................2
Criterios de entrada................................................................................................................................. 2
Criterio de salida..................................................................................................................................... 3
Ejecución de pruebas.............................................................................................................................. 3
Examen de la unidad.......................................................................................................................... 3
Pruebas funcionales............................................................................................................................ 3
Pruebas de regresión.......................................................................................................................... 3
Pruebas de integración....................................................................................................................... 3
Pruebas de interfaz............................................................................................................................. 3
Pruebas destructivas........................................................................................................................... 4
Pruebas de aceptación del usuario..................................................................................................... 4
Escenarios de prueba............................................................................................................................. 4
Desarrollo de guiones de prueba............................................................................................................ 4
Informe de defectos................................................................................................................................. 5

Entorno de prueba......................................................................................................... 5
Requisitos................................................................................................................................................ 5
Plataforma de prueba................................................................................................................................. 5

Plan de prueba de aceptación del usuario..................................................................5

Definición................................................................................................................................................. 5
Requisitos de prueba.............................................................................................................................. 6
Probadores/Participantes........................................................................................................................ 6
Calendario de pruebas............................................................................................................................ 6

Supuestos y riesgos......................................................................................................7
Suposiciones........................................................................................................................................... 7
Riesgos................................................................................................................................................... 7

Reunión de ir/no ir......................................................................................................... 7

Funciones y responsabilidades....................................................................................7
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Aprobación y reconocimiento...................................................................................... 8

Director de pruebas: proceso de seguimiento de defectos.....................................10

SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

INTRODUCCIÓN

Alcance
El objetivo general de las pruebas es garantizar que la aplicación {nombre de la aplicación} cumpla con todos sus
requisitos técnicos, funcionales y comerciales. El propósito de este documento es describir el plan de prueba
general y la estrategia para probar la aplicación {nombre de la aplicación}. El enfoque descrito en este documento
proporciona el marco para todas las pruebas relacionadas con esta aplicación. Se escribirán casos de prueba
individuales para cada versión de la aplicación que se publique. Este documento también se actualizará según sea
necesario para cada versión.

Objetivos de la prueba
Los objetivos de calidad de probar la aplicación {nombre de la aplicación} son garantizar la validación completa de
los requisitos comerciales y de software:

 Verificar que los requisitos de software sean completos y precisos

 Realizar una planificación de pruebas detallada
 Identificar los estándares y procedimientos de prueba que se utilizarán en el proyecto.
 Preparar y documentar escenarios de prueba y casos de prueba.
 Pruebas de regresión para validar que la funcionalidad sin cambios no se haya visto afectada por los
cambios
 Gestionar el proceso de seguimiento de defectos
 Proporcionar métricas de prueba/informes resumidos de pruebas.
 Asegúrese de que la aplicación esté certificada para su lanzamiento en el entorno de producción de la
Universidad de Minnesota.
 Programar reunión Ir/No Ir
 Exigir la aprobación de todas las partes interesadas

Objetivos de prueba
Los objetivos al probar esta aplicación incluyen validar la calidad, usabilidad, confiabilidad y rendimiento de la
aplicación. Las pruebas se realizarán desde un enfoque de caja negra, sin basarse en ningún conocimiento de
diseño o código interno. Las pruebas se diseñarán en función de los requisitos y la funcionalidad.

Otro objetivo es hacer que las pruebas sean repetibles para su uso en pruebas de regresión durante el ciclo de vida
del proyecto y para futuras actualizaciones de la aplicación. Una parte del enfoque en las pruebas será realizar
inicialmente una "Prueba de humo" al momento de la entrega de la solicitud para la prueba. La prueba de humo
suele ser un esfuerzo de prueba inicial para determinar si una nueva versión de software está funcionando lo
suficientemente bien como para aceptarla en un esfuerzo de prueba importante. Por ejemplo, si el nuevo software
falla con frecuencia o corrompe las bases de datos, el software no se encuentra en una condición lo
suficientemente estable como para justificar pruebas adicionales en su estado actual. Esta prueba se realizará
primero. Después de la aceptación de la compilación entregada para la prueba del sistema, las funciones se
probarán según la prioridad designada (crítica, alta, media, baja).

Calidad
El software de calidad está razonablemente libre de errores, cumple con los requisitos y/o expectativas y es
mantenible. Probar la calidad de la aplicación será un proceso de dos pasos de verificación y validación
independientes. Primero, se llevará a cabo un proceso de verificación que incluirá revisiones y reuniones para
evaluar documentos, planes, requisitos y especificaciones para garantizar que el resultado final de la aplicación sea
comprobable y que los requisitos estén cubiertos. El objetivo general es garantizar que los requisitos sean claros,
completos, detallados, coherentes, alcanzables y comprobables. Además, esto ayuda a garantizar que todos los
interesados acuerden los requisitos.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 1
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

En segundo lugar, se realizarán pruebas reales para garantizar que se cumplan los requisitos. El estándar por el
cual la aplicación cumple con las expectativas de calidad se basará en la matriz de prueba de requisitos, los casos
de uso y los casos de prueba para garantizar la cobertura de los requisitos. Este proceso de prueba también
ayudará a garantizar la utilidad de la aplicación, es decir, la funcionalidad del diseño y "¿la aplicación hace lo que
los usuarios necesitan?"

Fiabilidad
La confiabilidad es tanto la consistencia como la repetibilidad de la aplicación. Gran parte de probar una aplicación
implica validar su confiabilidad en sus funciones, datos y disponibilidad del sistema. Para garantizar la
confiabilidad, el enfoque de prueba incluirá pruebas funcionales positivas y negativas (break-it). Además, para
garantizar la confiabilidad durante todo el ciclo iterativo de desarrollo de software, se realizarán pruebas de
regresión en todas las iteraciones de la aplicación.

GARANTÍA DE CALIDAD DEL PROYECTO

Todos los artefactos del proyecto se publican en el sitio de SharePoint del proyecto EPM, ubicado en: {ingrese la
URL del sitio de SharePoint}

Documentos requeridos para el proyecto de vía rápida

Artefactos del proyecto Completo
Propuesta de Proyecto en EPM 
Lista de verificación de la fase de iniciación
Proyecto EDT
Carta del proyecto
Documento de requisitos comerciales
Lista de verificación de revisión del plan del proyecto
Lista de verificación de la fase de análisis
Lista de verificación de revisión de diseño
Lista de verificación de revisión de la arquitectura de TI conceptual
Diseño de arquitectura de aplicaciones
Diseño de arquitectura del sistema
Lista de verificación de revisión de código
Lista de verificación del plan de implementación
Plan de pruebas de control de calidad
Lista de verificación de planificación de pruebas
Lista de verificación de evaluación de la preparación para la implementación
Cerrar sesión de aceptación del usuario
Acuerdo de nivel de servicio y lista de verificación
Lecciones aprendidas
Cerrar informe

METODOLOGÍA DE PRUEBA

Criterios de entrada
 Todos los requisitos comerciales están documentados y aprobados por los usuarios comerciales.
 Todas las especificaciones de diseño han sido revisadas y aprobadas.
 El equipo de desarrollo, incluidos los proveedores, ha completado las pruebas unitarias.
 Todo el hardware necesario para el entorno de prueba está disponible.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 2
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

 La aplicación entregada al entorno de prueba es de calidad confiable.

 El equipo de pruebas aprueba la prueba de humo inicial de la funcionalidad entregada.
 Los cambios de código realizados en el sitio de prueba pasarán por un proceso de control de cambios.

Criterio de salida
 Todos los escenarios de prueba se han completado con éxito.
 Todos los problemas priorizados y los problemas de prioridad 1 resueltos.
 Todos los defectos pendientes se documentan en un resumen de prueba con un estado de prioridad y
gravedad.
 Se lleva a cabo una reunión de aprobación/no aprobación para determinar la aceptabilidad del producto.

Ejecución de pruebas
La fase de ejecución de la prueba es el proceso de ejecutar casos de prueba contra la compilación del software
para verificar que los resultados reales cumplan con los resultados esperados. Los defectos descubiertos durante el
ciclo de prueba se ingresarán en la lista de defectos del sitio del equipo de SharePoint del proyecto o en el Centro
de calidad (ofrecido por la OIT). Una vez que un desarrollador soluciona un defecto, el código corregido se
incorporará a la aplicación y se realizará una prueba de regresión.

Se deberán completar las siguientes fases de prueba (si corresponde):

Examen de la unidad
Las pruebas unitarias las realizan los desarrolladores de informes de U Services IT y OIT en sus entorno de
desarrollo. Los desarrolladores conocen y probarán la estructura lógica interna de cada componente de software.
Se debe proporcionar una descripción de las pruebas unitarias al equipo del proyecto.

Pruebas funcionales
Las pruebas funcionales se centran en los requisitos funcionales del software y se realizan para confirmar que la
aplicación funciona con precisión de acuerdo con las especificaciones y requisitos documentados, y para garantizar
que las interfaces con sistemas externos funcionen correctamente.

Pruebas de regresión
Se realizarán pruebas de regresión para verificar que las características y funciones previamente probadas no
tengan nuevos defectos introducidos, mientras se corrigen otros problemas o se agregan y modifican otras
características.

Pruebas de integración
La prueba de integración es la fase de prueba de software en la que los módulos de software individuales se
combinan y prueban como grupo. En su forma más simple, dos unidades que ya han sido probadas se combinan en
un componente y se prueba la interfaz entre ellas. En un escenario realista, muchas unidades se combinan en
componentes, que a su vez se agregan en partes aún mayores del programa. La idea es probar combinaciones de
piezas y eventualmente ampliar el proceso para probar tus módulos con los de otros grupos. Finalmente, todos los
módulos que componen un proceso se prueban juntos.

Pruebas de interfaz
Esta prueba sigue una transacción a través de todos los procesos del producto que interactúan con ella y prueba el
producto en su totalidad. Se realizarán pruebas de interfaz para garantizar que el producto realmente funcione de
la forma en que un usuario típico interactuaría con él.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 3
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Pruebas destructivas
Las pruebas destructivas se centran en las áreas de detección y prevención de errores del producto. Esta prueba se
realiza en un intento de anticipar condiciones en las que un usuario puede encontrar errores. Las pruebas
destructivas están menos estructuradas que otras fases de prueba y las determinan los evaluadores individuales.

Pruebas de aceptación del usuario

Las actividades de prueba de aceptación del usuario serán realizadas por los usuarios comerciales. El propósito de
esta prueba será garantizar que la aplicación cumpla con las expectativas de los usuarios. Esto también incluye
enfoques en la usabilidad e incluirá; apariencia, coherencia de los controles, coherencia de los nombres de los
campos, precisión de las listas de información de campos desplegables, ortografía de todos los nombres de
campos/valores de datos, precisión de los valores de campos predeterminados, secuencia de pestañas y mensajes
de error/ayuda

Escenarios de prueba
A continuación se muestran los escenarios de alto nivel que se probarán. Estos escenarios se derivan de la Matriz
de Requisitos y los Casos de Uso. A partir de estos, se crearán scripts de prueba detallados.
identificación

del script de

¿Completo?
Número de

Referencia

Pruebas
prueba
Descripción del escenario de prueba

TODOS LOS REQUISITOS DECLARADOS EXISTEN Y FUNCIONAN

{Un escenario de prueba es casi como una historia: un usuario ingresa a la
aplicación desde la ventana de inicio de sesión ingresando un nombre de usuario y
001 contraseña válidos. Después de ingresar, hará clic en el módulo Nómina y hará clic
en la función Última nómina para ver su última nómina". Cualquier escenario de
prueba contendrá un objetivo específico.}

002
SEGURIDAD
003 {Agregar descripción de los requisitos.}
004
VALIDACIÓN DE DATOS
005 {Agregar descripción de los requisitos.}
006
AMBIENTE
007 {Agregar descripción de los requisitos.}
008
INTERFACES
009 {Agregar descripción de los requisitos.}
010

Desarrollo de guiones de prueba

El diseño de scripts de prueba es el foco central de un proceso de garantía de calidad del software. Un script de
prueba se define como una especificación escrita que describe cómo se probará un requisito individual o un grupo
de requisitos del sistema o del negocio. El script de prueba consta de un conjunto de acciones que se realizarán,
datos que se utilizarán y los resultados esperados de la prueba. Los resultados reales de la prueba se registran
durante la ejecución de la prueba. Los scripts de prueba también se actualizarán a medida que avancen las
pruebas.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 4
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Los scripts de prueba escritos para este proyecto incluyen lo siguiente:

 ID del script de prueba
 Casos de prueba verificados
 Requisitos verificados
 Propósito de la prueba
 Cualquier dependencia y/o instrucciones de configuración especiales necesarias para realizar la prueba.
 Descripción y pasos de la prueba.
 Resultados previstos

Informe de defectos
Se realiza un seguimiento de los problemas/defectos para su resolución con las siguientes pautas:
 Los problemas se informarán según los requisitos documentados.
 El equipo de pruebas realizará un seguimiento de los problemas, los informará y los ingresará en Quality
Center.
 El equipo de desarrollo solucionará los problemas según la prioridad/gravedad asignada por el líder de
prueba.
 Todos los defectos críticos/prioridad 1 se solucionarán antes del lanzamiento a producción.

Consulte el Proceso de seguimiento de defectos al final de este documento para obtener instrucciones detalladas
sobre cómo registrar y rastrear defectos en Quality Center.

ENTORNO DE PRUEBA

Requisitos
Requisitos técnicos del servidor cliente:
 Se admiten varios navegadores (Internet Explorer, Firefox, Mozilla)
 Base de datos Oracle
 Plataforma de cliente: PC y Macintosh
 Ubicación del servidor de producción:

Plataforma de prueba
 PC de escritorio: la aplicación es compatible con todos los navegadores A-Grade para los sistemas
operativos Windows y Mac, según lo definen los estándares de compatibilidad con navegadores
graduados de Yahoo!. http://developer.yahoo.com/yui/articles/gbs/ Windows 2000/IE6 puede estar
excluido.
 Ubicación del servidor de prueba:

PLAN DE PRUEBA DE ACEPTACIÓN DEL USUARIO

Definición
El objetivo general de las pruebas es garantizar que la aplicación {nombre de la aplicación} funcione a un nivel
aceptable para el cliente. Esta sección describe el plan detallado para las pruebas de aceptación del usuario de esta
aplicación.

Este plan de prueba se utilizará para registrar la aprobación por parte del cliente de los escenarios documentados.
Se han desarrollado guiones/casos de prueba detallados que se utilizarán para registrar los resultados de las
pruebas de los usuarios. Este documento es una guía de alto nivel y no pretende reemplazar ningún procedimiento
de prueba de aceptación de usuario específico que puedan tener áreas individuales.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 5
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

Requisitos de prueba
 Las pruebas se llevarán a cabo en {insertar ubicación}. Algunos evaluadores pueden optar por realizar
algunas pruebas desde sus estaciones de trabajo habituales cuando sea posible. Los resultados de las
pruebas aún deben coordinarse con otros.
 La UAT se llevará a cabo a partir del {insertar fecha}.
 Los participantes de la prueba identificados recibirán instrucciones antes del inicio de la prueba.
 Los participantes de las pruebas identificados realizarán el equivalente de su función comercial normal en
el entorno actualizado.
 Los guiones/casos y escenarios de prueba se prepararán antes del inicio de la UAT.
 Los participantes de la prueba realizarán las pruebas y documentarán los resultados.
 Los defectos se ingresarán en el Director de pruebas y el Jefe de pruebas los rastreará.

Probadores/Participantes
Los participantes en las pruebas deben incluir representantes de todas las áreas involucradas en la aplicación. Es
beneficioso incluir representantes de todas las áreas para validar las funciones del sistema antes de que la
actualización entre en producción.

Los mejores candidatos para la UAT son:

 Personal directamente afectado por los próximos cambios en el sistema y los procesos comerciales.
 Usuarios frecuentes de la aplicación y funciones planificadas en scripts/casos de prueba.
 Personas con un sólido conocimiento de los procesos de negocio en las áreas que representan.
 Personas con el tiempo necesario para comprometerse con este emprendimiento.
 Dispuesto a experimentar (probar varios métodos para ver qué funciona y qué no).
 Paciente y tolerante a la ambigüedad.

Área de enfoque de las

Nombre del probador Departamento/Área que representa
pruebas

Calendario de pruebas
Toda la funcionalidad actualizada y los datos de prueba se migrarán al entorno de prueba antes del inicio de las
pruebas de aceptación del usuario.

Actividad Responsabilidad principal Fecha

Identificar y seleccionar probadores para UAT
Desarrollar escenarios de prueba y guiones/casos.
Validar la disponibilidad de los participantes para la
prueba.
Revisar escenarios/guiones para verificar su precisión,
integridad y secuencia (confirmar que los datos de la
prueba sean correctos)
Asegúrese de que los escritorios de UAT Lab estén
configurados para realizar pruebas
Validación del entorno UAT
Pruebas realizadas por participantes de la UAT

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 6
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

SUPUESTOS Y RIESGOS

Suposiciones
 El equipo de Negocios ha revisado y aceptado la funcionalidad identificada en los documentos de
requisitos de negocio y de software.
 Proceso de control de cambios del proyecto implementado para gestionar los requisitos.
 El equipo de desarrollo completará los tutoriales/revisiones del código.
 El equipo de desarrollo completará las pruebas unitarias antes de entregarlas al equipo de pruebas.
 Los evaluadores probarán lo que está documentado en los requisitos.
 El equipo de prueba tendrá un entorno de prueba separado para realizar las pruebas.
 Todos los cambios en los requisitos se comunicarán al equipo de prueba.
 Los recursos identificados en este plan están disponibles para probar la aplicación y resolver defectos y
abordar problemas a medida que los plantee el equipo de prueba.
 Que la entrega del producto a producción contenga toda la configuración, etc., necesaria para un
rendimiento óptimo en el sitio de producción.
 Los patrocinadores del proyecto, comerciales y técnicos, brindarán orientación práctica sobre la
priorización y resolución de defectos.
 El entorno UAT estará disponible y los escritorios estarán disponibles para realizar pruebas.

Riesgos
 La variación del alcance (adición de nuevos requisitos de última hora) afecta los plazos para el equipo de
desarrollo y el equipo de pruebas.
 Una fecha límite agresiva aumenta el riesgo de que los defectos se migren a producción. Si no se cumplen
los plazos de desarrollo, esto afectará directamente los plazos de prueba.
 Los recursos clave tienen prioridades de finalización, lo que hace que la disponibilidad sea menor que la
programada.
 Cualquier tiempo de inactividad del sistema de prueba afectará significativamente el ciclo de prueba.
 Las pruebas de carga no se completan de manera consistente; Es posible que no se conozca el verdadero
rendimiento de la aplicación hasta su lanzamiento a producción.

REUNIÓN DE IR/NO IR
Una vez que el equipo de prueba haya completado el ciclo de prueba, se programa una reunión de Go/No-go como
parte de la planificación de implementación bajo preparación para el lanzamiento. A esta reunión asisten el
director del proyecto, el equipo comercial, el líder de pruebas, el líder técnico y cualquier otra parte interesada.

El líder de pruebas proporcionará un resumen de las pruebas y enumerará todos los defectos pendientes no
resueltos y cualquier riesgo asociado con la puesta en producción del producto. Todas las cuestiones pendientes se
discuten en ese momento antes de tomar la decisión de pasar a producción. Todos los miembros del equipo firman
un formulario de aprobación escrito como se indica anteriormente. La lista de cuestiones pendientes también se
adjunta al formulario de aprobación.

FUNCIONES Y RESPONSABILIDADES
Tipo de recurso Responsabilidades Nombre
Patrocinador  Proporciona autorización Go/No Go de que el
producto está listo para su lanzamiento como parte
de la planificación de implementación y el proceso
de lanzamiento.
 Prioriza problemas y defectos, y gestiona recursos

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 7
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

técnicos.
 Toma decisiones sobre temas no resueltos.
Gerente de proyecto  Proporciona orientación sobre el proyecto general.
 Coordina y desarrolla el cronograma del proyecto.
 Enlace con las empresas para garantizar la
participación y la propiedad.
 Realiza un seguimiento de todas las actividades y
recursos del proyecto, garantizando que el proyecto
permanezca dentro del alcance.
 Facilita la identificación y cierre de problemas
abiertos.
 Comunica el estado del proyecto.
Expertos en la materia  Definir los requisitos comerciales y los resultados
esperados para la aceptación comercial.
 Ejecutar pruebas de aceptación del usuario.
Líder del equipo de  Arquitectura de aplicaciones de diseño
desarrollo  Crear diseño técnico.
 Administrador de base de datos
Desarrolladores  Escribir código de aplicación
 Resolver defectos
 Probadores de soporte
Líder de Negocios  Redactar requisitos comerciales, planes de prueba y
casos de prueba.
 Mantener requisitos e informes de defectos en Test
Director
 Ciclo de prueba de plomo
Líder de control de  Mantener proyecto en Test Director
calidad  Escribir un plan de prueba para incluir escenarios y
casos de prueba.
 Facilitar las pruebas
 Mantener y gestionar defectos en Test Director.
Analista de negocios  Redactar requisitos comerciales y crear scripts de
prueba.
 Mantener requisitos en Test Director
 Liderar el ciclo de pruebas y coordinar el entorno de
pruebas.
Probadores  Realizar pruebas de aceptación del usuario.

APROBACIÓN Y RECONOCIMIENTO
Entiendo que al aceptar participar en esta prueba mediante la ejecución del plan de prueba, apruebo las
actividades definidas y autorizo a mi departamento a participar según lo documentado para la implementación
exitosa de esta aplicación en nuestro departamento.

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 8
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

_______________________________ Fecha: ___/___/___

Nombre del recurso
Título o Responsabilidad

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 9
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

DIRECTOR DE PRUEBAS: PROCESO DE SEGUIMIENTO DE DEFECTOS

Nombre de usuario y descripción breve sobre el defecto que se informa, que

Resumen: generalmente proporciona palabras clave con las que identificar y/o buscar el
defecto.
Se completa automáticamente con el ID de usuario de la persona que inició
Detectada por:
sesión.
Detectado en Fecha: Se completa automáticamente con la fecha actual.
Describe el grado de impacto que tiene un defecto en el funcionamiento de la
Gravedad:
aplicación.
Asignado a: Se le asigna al individuo el defecto a reparar.
Detectado en ID de compilación en el que se encontró el defecto. Build ID es un identificador
compilación: para la publicación del código, asignado por Desarrollo web.
Corregido en ID de compilación en el que se soluciona el defecto. Build ID es un
compilación: identificador para la publicación del código, asignado por Desarrollo web.
Este campo describe el impacto que tiene el defecto en el trabajo en curso y la
Prioridad:
importancia y el orden en que se debe corregir un error.
Indica el estado existente de un defecto, se completa automáticamente con un
Estado:
valor predeterminado de "Nuevo"
Introduzca la descripción del defecto

Agregue pasos individuales para reproducir. Incluya todos los pasos y

Descripción:
pantallas a las que se accedió.

Ingrese las palabras exactas del mensaje de error.

Defecto de correo Después de ingresar el defecto, haga clic derecho sobre él y seleccione el
electrónico: correo electrónico para enviarlo al desarrollador asignado.

Cuando se abre el defecto, se asigna a la persona adecuada y el estado

Proceso de cambia a "Asignado".
resolución de
defectos: Una vez solucionado el defecto:

1. El desarrollador a quien se le asignó el defecto actualizará los

comentarios del defecto para documentar la solución realizada. La ID
de usuario y la fecha se agregan automáticamente al defecto al hacer
clic en "Agregar comentario".
2. El desarrollador a quien se le asigna el defecto cambiará el estado a
"Reparado" y cambiará el campo "Asignado a" al evaluador o
administrador de defectos.
3. El evaluador volverá a probar el defecto enviado.
4. Si el defecto pasa la nueva prueba, el evaluador o el administrador de
defectos cambiará el estado a "Cerrado".
5. Si el defecto no se soluciona, el evaluador cambiará el estado a
"Asignado" e ingresará el ID de usuario del desarrollador en el campo
Asignado a.
6. Una vez que se haya verificado que el defecto se ha solucionado, el
director del proyecto (o director de defectos) actualizará el estado a
"Cerrado".

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 10
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 11
SISTEMA/APLICACIÓN PLAN DE PRUEBAS DE GARANTÍA DE CALIDAD

DEFINICIONES DE PRIORIDAD Y SEVERIDAD DE DEFECTOS

PRIORIDAD: Este campo describe el impacto que tiene el defecto en el trabajo en progreso y la
importancia y el orden en que se debe corregir un error. Los desarrolladores e ingenieros de pruebas
utilizan este campo para priorizar el esfuerzo de trabajo en la resolución de defectos.

1 – Trabajo de No se podrán realizar más desarrollos y/o pruebas hasta que se haya resuelto
bloques urgentes el defecto.

2 – Resolver lo antes
posible
3 – Cola normal
El defecto debe resolverse lo antes posible porque está perjudicando las
actividades de desarrollo y/o prueba.
El defecto debe resolverse mediante la priorización normal y la finalización de
la resolución del defecto.

El defecto es una molestia y debe resolverse, pero puede esperar hasta que
4 – Baja prioridad
se hayan solucionado defectos más graves.

5 – trivialidades El defecto tiene poco o ningún impacto en el trabajo de desarrollo y/o prueba.

SEVERIDAD: Este campo describe el grado de impacto que tiene un defecto en el funcionamiento de la
aplicación.
Pérdida crítica de función. El defecto provoca fallos del sistema, fallos de un
1 – Crítico subsistema o módulo clave, corrupción o pérdida de datos o una pérdida
grave de memoria.
Pérdida importante de función. El defecto da como resultado una falla del
2 – Mayor sistema, subsistema o módulo, pero no da como resultado la corrupción o la
pérdida de datos importantes.

Pérdida moderada de función. El defecto no resulta en una falla del sistema,

3 – Moderado subsistema o módulo, pero puede causar que el sistema muestre datos de
manera incorrecta, incompleta o inconsistente.
Pérdida menor de función u otro problema donde exista una solución
4 – Menor
alternativa. No hay problemas de integridad de datos.
El defecto está relacionado con la usabilidad del sistema, es el resultado de la
5 – Usabilidad no conformidad con un estándar o está relacionado con la estética del
sistema. No hay pérdida de la función del sistema.

El defecto es una solicitud de mejora, es decir, no está dentro del alcance del
6 – Mejora
esfuerzo actual del proyecto.

© 2012 Regentes de la Universidad de Minnesota. Reservados todos los derechos. Revisado June 28, 2024 Página 12