UEAO-PE 07092006-Plan de Pruebas v0.4

PLAN DE PRUEBAS
Fase Análisis
Análisis Unidad de Enseñanza Asistida por Ordenador

para el Plan de Emergencia de Metro de Madrid
(UEAO-PE)
CONTROL DOCUMENTAL
Elaborado por: Fecha:
Ana Combarros García 11/08/2006
Revisado por: Fecha:

Carmen García Palazón 29/08/2006
Visto bueno Calidad: Fecha:
Alejandro Rojo Roldán 29/08/2006
Objeto:
Plan de pruebas de la fase de Análisis del Sistema Unidad de Enseñanza Asistida por Ordenador
Versión Fecha Descripción

0.1 07/08/2006 Documento original
0.2 19/098/2006 Se incluye revisión a comentarios realizados por metro
0.3 28/089/2006 Se incluye revisión a comentarios realizados por metro
0.4 05/10/2006 Se modifican links a documentos
Lista de distribución:
Metro de Madrid, SA:
José Luís Gómez- Responsable de Formación en este Proyecto.
Esteban Meléndez- Sustituto del Responsable de Formación en los momentos que éste no pueda
asistir y responsable de buscar puntos de coincidencia en el módulo de gestión con lo definido en los
Simuladores y mini simuladores.
Maria Luisa Baena- Responsable de e-learning y multimedia dentro de la gerencia de formación.
Ignacio Laborda– Responsable de Contenidos y estructuración de cursos.
Mª Dolores Lucas - Responsable de Contenidos y estructuración de cursos.
Jesús Losáñez- jefe de Proyecto – Gerencia de Desarrollo e Integración de Soluciones.
Carmen Miyar- Responsable del Área de Desarrollos Corporativos.
Atos Origin:
Carmen García Jefe de Proyecto, Alfonso Portones-Director Técnico, Ana Combarros-Analista
Responsable del Modulo de Gestión ,Javier Picaporte-Consultor Multimedia
Alejandro Rojo-Responsable de Metodología y Calidad
Fecha: Autor: Revisor: Código Documento: Versión: Página:

07/09/2006 Ana Combarros Carmen García 399015702.doc 0.43 2 de 23
CONTROL DE CAMBIOS
Fecha / Versión Autor Página Cambio

OBJETO
El objeto de este documento es definir el plan de pruebas del sistema, el cual

sirve como guía para la realización de las mismas y permite verificar que el
sistema de información cumple las necesidades establecidas por el usuario, con
las debidas garantías de calidad.
El plan de pruebas es un producto formal que define los objetivos de la prueba de

un sistema, establece y coordina una estrategia de trabajo, y provee del marco
adecuado para elaborar una planificación paso a paso de las actividades de
prueba. El plan se inicia en el proceso Análisis del Sistema de Metro (ASM),
definiendo el marco general y estableciendo los requisitos de prueba de
aceptación, relacionados directamente con la especificación de requisitos.

GLOSARIO DE TÉRMINOS Y DOCUMENTACIÓN DE REFERENCIA
Glosario de Términos
ASM: Análisis del Sistema de Información de Metro de Madrid.
Atos: Atos Origin, Sae.
ERS: Especificación de Requisitos Software.
Metro: Metro de Madrid, S.A.
SAP: Software ERP (Enterprise Resource Planning).
UEAO: Unidad de Enseñanza Asistida por Ordenador.
UEAO-PE: Unidad de Enseñanza Asistida por Ordenador del Plan de Emergencia

de Metro de Madrid.
Documentación de Referencia
Plan de Proyecto
\\colonia\proyectos\UEAO-PE\08 - COMUN EQUIPO DE TRABAJO\01-Plan

Inicial\Aprobado\UEAO-PE_28042006_Pp_Plan de Proyecto_V1.0.doc
Especificación de Requisitos Software

\\colonia\proyectos\UEAO-PE\08 - COMUN EQUIPO DE TRABAJO\02-
Análisis\Pendiente de Aprobar\UEAO-PE_07092006_ERS_v0.5.doc

ÍNDICE DEL DOCUMENTO
Glosario de Términos.........................................................................................5
Documentación de Referencia..........................................................................5
1. ALCANCE DE LAS PRUEBAS.....................................................................8
2. NIVELES DE PRUEBAS.............................................................................10
3. VOLUMEN, ESTIMACIONES Y PONDERACIONES DE CASOS DE

PRUEBAS...............................................................................................................13
4. CICLOS DE PRUEBAS...............................................................................13
5. PRUEBAS MANUALES Y AUTOMATIZACIÓN DE PRUEBAS................14
6. PLANIFICACIÓN DE LAS PRUEBAS Y ESTIMACIÓN DE RIESGOS.....14

6.1. Planificación de pruebas.......................................................................14
6.2. Productos entregables..........................................................................15
6.3. Estimación de riesgos...........................................................................16
7. REQUERIMIENTOS DE PERSONAL.........................................................16
8. REQUERIMIENTOS Y PROCEDIMIENTOS DE PREPARACIÓN Y

RECUPERACIÓN DE CADA ENTORNO..............................................................17
9. REQUERIMIENTOS Y PROCEDIMIENTOS DE PREPARACIÓN Y

RECUPERACIÓN DE DATOS DE PRUEBAS EN CADA ENTORNO..................17
10. PROCEDIMIENTOS DE RECOPILACIÓN Y CRITERIOS DE

EVALUACIÓN DE RESULTADOS.........................................................................17
10.1. Procedimiento de recopilación de resultados.................................17
10.2. Criterio de evaluación de resultados................................................19
11. PROCEDIMIENTO DE ESTIMACIÓN Y CRITERIO DE SELECCIÓN DE

INCIDENCIAS A RESOLVER.................................................................................19

12. PROCEDIMIENTO DE RESOLUCIÓN Y SEGUIMIENTO DE INCIDENCIA
20
13. CRITERIOS DE INICIO, FINALIZACIÓN, PARADA Y RECUPERACIÓN

DE LAS PRUEBAS................................................................................................21
14. Plantilla de Prueba.......................................................................................23

1 . AL C A N C E D E L A S P R U E B A S
Este documento describe la forma en que se deben realizar las pruebas

necesarias para satisfacer los requisitos descritos y aprobados en el catalogo de
requisitos (apartado 3. Catalogo de requisitos del documento UEAO-
PE_07092006_ERS_v0.5), así como los distintos escenarios y recursos
necesarios para su realización.
Este plan se irá completando y detallando a medida que se avance en los
restantes procesos del ciclo de vida del proyecto, Diseño del Sistema de Metro
(DSM), Construcción del Sistema de Metro (CSM) e Implantación y
Aceptación del Sistema de Metro(IAS).
El plan de pruebas se centrará en los procesos de gestión y visualización de

UEAOs y su integración con el sistema SAP.
Los distintos niveles de prueba que se plantean son los siguientes:
- Pruebas unitarias
- Pruebas del integración
- Pruebas de volumen
- Pruebas del sistema
- Pruebas de implantación y aceptación
Para cada uno de estos niveles de prueba se plantea un procedimiento genérico

para la realización de las mismas:

Preparación del
Entorno
Ejecución de la
Prueba o
Verificación
Analizar
Resultados
Aceptación de
Desviaciones
Realización de los
la Prueba
ajustes necesarios
Donde:
 El equipo del contratista preparará el entorno de pruebas con los requisitos

del sistema.
 La ejecución de las pruebas se realizará por el equipo responsable

dependiendo de la prueba que se trate, tal y como se define en el apartado
2. Niveles de Pruebas
 Tras su ejecución se analizarán los resultados obtenidos respecto a lo

esperado.
o Si se producen desviaciones respecto a lo esperado será necesario

realizar ajustes oportunos y se volverá a comenzar el proceso.
 Una vez confirmado que los resultados obtenidos son los mismos que los
esperados se da la prueba por aprobada
Para que el desarrollo del plan de pruebas pueda realizarse correctamente en los
diferentes entornos existentes en Metro, será necesario tener acceso al servidor
del sistema SAP en dichos entornos. Asimismo, será necesaria una carga inicial

de datos, que supondrá la carga de perfiles y usuarios de prueba en dichos
entornos.
2. NIVELES DE PRUEBAS
Los diferentes niveles de pruebas a realizar son los siguientes:
 Pruebas unitarias
En el proceso de desarrollo del Sistema UEAO-PE se considera imprescindible,

el diseño e implementación de pruebas unitarias.
Estas pruebas tienen como principales objetivos comprobar que cada uno de
los componentes del sistema se comporta de la manera esperada y prevenir la
aparición de errores inesperados al modificar dicho componente.
Se verificará que cada uno de los componentes constituyentes del sistema
funcione correctamente diseñando un caso de prueba para cada caso de uso
identificado y definido en el documento de diseño.
Por otro lado, si se desarrollaran componentes con código a media, se
realizarán pruebas estructurales o de “caja blanca” sobre los mismos,
revisándolos para verificar la correcta estructura, complejidad no excesiva y
frecuencia de comentarios, obteniendo en su caso las Métricas Técnicas
correspondientes y quedando constancia de estas revisiones en las Plantillas
de Pruebas que se preparen para cada componente.
Estas pruebas se deberán ejecutar a lo largo de la fase de construcción por el
equipo de trabajo del contratista que implante la solución y deberán realizarse
en el entorno de desarrollo.
 Pruebas de Integración
Mediante estas pruebas se verificará, la consistencia de los distintos

componentes de cada subsistema entre sí y el cumplimiento de los requisitos
establecidos:
o Validación de la consistencia y correcto funcionamiento integrado de
todos los componentes de la solución.

o Comprobación de que los cambios substanciales sobre algún
componente no introducen un comportamiento no deseado o errores
adicionales en otros componentes no modificados.
Las pruebas de Integración deben ser realizadas y finalizadas por el equipo de

trabajo de la empresa implantadora en el entorno de desarrollo. Posteriormente
la Gerencia de Desarrollo e Integración de Soluciones será encargada de la
validación de las mismas, pudiendo repetirlas, dentro del nivel de pruebas de
Sistema, en el entorno de pre-producción.
 Pruebas de Sistema
Estas pruebas están encaminadas a asegurar la consistencia entre los

distintos subsistemas y que todos los requisitos son satisfechos de la forma y
en el alcance descritos en la documentación de referencia, así como que el
sistema está preparado para la realización de las pruebas de aceptación del
sistema. Estas pruebas serán realizadas por el equipo de analistas del
contratista junto con los responsables de Metro de Madrid, S.A en el entorno
de pre-producción.
Se distinguen dos grupos de pruebas:
 Pruebas de funcionalidad para verificar que se cumplen los requisitos

funcionales.
 Pruebas técnicas para verificar que se cumplen los requisitos no
funcionales. Además dentro de este grupo de pruebas, se realizarán:
o Pruebas de Volumen y de Automatización:
El equipo contratista debería proporcionar a la Gerencia de Desarrollo

una estimación del volumen de datos a manejar, dichas pruebas serán
responsabilidad de la mencionada gerencia.
El objetivo es asegurar que tanto el acceso a los datos como el tiempo

de respuesta de la aplicación es el óptimo en condiciones normales.
Serán de vital importancia para garantizar que la instalación actual
puede cubrir las necesidades de la nueva implantación o en su caso
emitir las correspondientes recomendaciones de posible ampliación.

METRO se reserva el derecho de comprobar, revisar, repetir y verificar
por si mismo o por medio de un tercero las pruebas que se realicen.
También Metro se reserva el derecho a que esas pruebas se realicen

por medio de mecanismos o herramientas automatizados.
o Pruebas de operatividad de puestos cliente:
Basadas en verificar la correcta implementación de los mismos. Estas

pruebas serán realizadas por el equipo de analistas del contratista junto
con el Área de Atención al Cliente (Microinformática) de Metro de
Madrid, S.A.
 Pruebas de Implantación y Aceptación
Estas pruebas se desarrollarán en el entorno de pre-producción, simulando

con una mayor exactitud el entorno de explotación, por el equipo de la
Gerencia de Formación, la Gerencia de Desarrollo e Integración de
Soluciones, la Gerencia I+D y Explotación de Sistemas y los Usuarios en este
nivel de pruebas apoyados por el equipo implementador de la solución.
Definimos dos tipos de pruebas que se pueden realizar sobre el sistema para
la aceptación del mismo:
Pruebas de funcionalidad: Consiste en realizar las pruebas de todas aquellas
funcionalidades que debe cumplir la aplicación y que han sido solicitadas por
el usuario y recogidas en el catálogo de requisitos. Estas pruebas quedan
definidas en la matriz de trazabilidad de requisitos que se encuentra en:
\\colonia\Proyectos\UEAO-PE\08 - COMUN EQUIPO DE TRABAJO\07-
Gestion de Proyecto\01-Calidad\UEAO-PE_28042006_RC_Registros de
Calidad_V1.0.xls
Pruebas de autorizaciones: Consiste en realizar las pruebas de todas las

autorizaciones que han sido definidas.
Tanto las pruebas de funcionalidad como de autorizaciones se deberán realizar

para todos y cada uno de los actores del sistema.

Metro de Madrid se reserva el derecho de participar en todos los ciclos de
pruebas que considere oportuno.
3 . V O L UM E N , E S T I M A C I O N E S Y P O N D E R A C I O N E S D E
CASOS DE PRUEBAS
Cada uno de los elementos de prueba tendrá una o más plantillas en función de la
complejidad de la funcionalidad del elemento (Apartado 14. Plantilla de Prueba)
Las pruebas unitarias deberán realizarse al finalizar la construcción de cada

elemento. La duración de estas pruebas se debe incluir en la estimación de
esfuerzo de construcción del componente con un incremento estimado del 10%.
Durante la fase de análisis se han estimado 122 casos de uso que podrán ser
ampliados en las fases de Diseño y Construcción.
Para las pruebas de Integración, de Volumen y de Sistemas se estima una

volumen del 30% del total empleado en la construcción del sistema.
4 . C I CL O S D E P R U E B A S
Los ciclos de pruebas permiten repetir pruebas relacionadas con incidencias

resueltas y aseguran la calidad del producto que pasará a la próxima etapa, fase,
o actividad del proyecto.
Se definirán ciclos de prueba para las fases de integración y aceptación de la

aplicación. El procedimiento a seguir será el siguiente:
 Se realizarán las pruebas definidas en el Plan de Pruebas.

 Si el resultado de todas las pruebas a realizar es correcto, o las incidencias
surgidas se determinan como no críticas por la Gerencia del Proyecto, se
pasará al siguiente nivel de pruebas.
 Si se encuentran errores en las pruebas a realizar en la aplicación, se
considerarán las pruebas como incorrectas y se procederá a la corrección de
los fallos encontrados. Si estos errores no suponen más del 20% de las
pruebas indicadas en el Plan de Pruebas, la repetición de las pruebas se
limitará a aquellas que no concluyeron satisfactoriamente y aquellas que sean

necesarias para repetir las pruebas fallidas. En caso de superar el 20% del
total de las pruebas con resultado erróneo, se parará la ejecución de las
pruebas y se repetirá toda la ejecución definida en el Plan de Pruebas.
5. PRUEBAS MANUALES Y A U TO M AT I Z A C I Ó N DE
PRUEBAS
Todos los niveles de pruebas identificados salvo las de volumen se van a realizar
manualmente por el equipo de trabajo correspondiente a cada nivel de pruebas.
Las pruebas de volumen o de stress, basadas en sobrecargar el sistema para

probar el rendimiento y los límites de funcionamiento hasta conseguir que el
sistema falle se realizarán con pruebas automatizadas utilizando herramientas
existentes en Metro.
El equipo contratista proporcionará a la Gerencia de Desarrollo una estimación del

volumen de datos a manejar y dichas pruebas serán responsabilidad de la
mencionada gerencia.
6. PLANIFICACIÓN DE LAS PRUEBAS Y ESTIMACIÓN

DE RIESGOS
6.1. Planificación de pruebas
La Planificación de Pruebas se irá alimentando en las fases posteriores del

Sistema.
La realización de las pruebas ejecutadas por el equipo del contratista, es decir,
pruebas de integración, de volumen y de sistema que se llevará a cabo una vez
finalizada la construcción y la realización de las pruebas unitarias será de 15 a 20
días de forma simultánea o progresiva, teniendo en cuenta que el entorno de pre-
producción tiene unas limitaciones en cuanto a tiempo de permanencia y duración
de las pruebas de Sistema de 5 días.
Las pruebas a realizar abarcarán tanto el sistema de gestión y visor de contenidos

como los propios contenidos de la UEAO-PE.

La realización de las pruebas de Implantación y Aceptación llevadas a cabo por el
equipo de la gerencia de Formación y la Gerencia de Desarrollo e Integración de
Soluciones de Metro de Madrid, S.A. será de 5 días de forma simultánea o
progresiva. El equipo contratista se comprometerá a que el nivel de pruebas
unitarias y de integración sea lo suficientemente eficaz para que los componentes
software no produzcan fallos de funcionamiento cuando pasen al entorno de pre-
producción y por tanto las pruebas de Implantación y Aceptación no se demoren
más tiempo del anteriormente citado, debido a la limitación existente del entorno
de pre-producción en cuanto al tiempo de permanencia y duración de éstas
pruebas.
La ejecución en el tiempo de estas pruebas se realizará siguiendo la planificación
siguiente, que podrá verse modificada en la fase de diseño del sistema:
\\colonia\Proyectos\UEAO-PE\08 - COMUN EQUIPO DE TRABAJO\02-
Análisis\Pendiente de Aprobar\UEAO-PE_07092006_Pp_Planificación
Pruebas_v0.2.mpp
Se aconseja que se ejecuten los diferentes niveles de pruebas establecidos en los

entornos de desarrollo y pre-producción según se indica:
 Pruebas unitarias y pruebas de integración: entorno de desarrollo.

 Pruebas de integración, pruebas de sistema, pruebas de
volumen/automatización y pruebas de aceptación: entorno de pre-
producción (Pruebas).
6.2. Productos entregables
Los productos entregables son los siguientes:
 Planificación de pruebas: basado en la matriz específica de requisitos de

usuario, detallando requisito, tipo de prueba, nivel de prueba, fecha
descripción y resultado.
 Ficha de la Prueba: Documento actualizable y detallado para cada

prueba, siguiendo el modelo proporcionado por Metro.
Plantilla de Prueba

 Documento Resumen del resultado de pruebas: Documento que
recogerá el total de las pruebas realizadas para cada nivel de prueba con
su correspondiente valoración y resultado real.
6.3. Estimación de riesgos
Los riesgos existentes para la realización de las pruebas son la indisponibilidad de

los requerimientos personales, de entorno y de datos, descritos en los apartados
7, 8 y 9 respectivamente del presente documento.
7 . R E Q U E R I M I E N TO S D E P E R S O N A L
A continuación se describe el personal necesario para cada uno de los diferentes

niveles de pruebas de la aplicación:
 Pruebas unitarias: equipo de trabajo de desarrollo del contratista. El tiempo

destinado a la ejecución de estas pruebas debe ser incluido en el tiempo
estimado para la construcción de cada componente.
Posteriormente la Gerencia de Desarrollo e Integración de Soluciones será

encargada de la validación.
 Integración: equipo de trabajo contratista y Jefe de Proyecto.

Posteriormente la Gerencia de Desarrollo e Integración de Soluciones será
encargada de la validación.
 Sistema: equipo de trabajo contratista y Jefe de Proyecto. Posteriormente

la Gerencia de Desarrollo e Integración de Soluciones será encargada de
la validación.
 Volumen y Automatización: equipo de Metro de Madrid formado por

Gerencia de Desarrollo e Integración de Soluciones: técnicos de desarrollo,
técnicos de explotación/administración del sistema.
 Aceptación:
o Usuarios pertenecientes a la Gerencia de Formación: usuarios

participantes en el Proyecto e integrantes del Comité de Seguimiento.

o Gerencia Desarrollo e Integración de Soluciones.
8 . R E Q U E R I M I E N TO S Y P R O C E D I M I E N TO S DE
P R E PA R A C I Ó N Y RECUPERACIÓN DE CADA
E N TO R N O
Teniendo en cuenta que nos encontramos en la fase de Análisis del Proyecto, el

requerimiento necesario, por el momento, para llevar a cabo el plan de pruebas
es:
 Acceso al sistema SAP en el entorno de desarrollo e integración.

 Códigos de usuarios con su correspondiente perfil de autorización y sus
objetos de autorización definidos.
 Licencias operativas de todos los productos de terceros necesarios:
sistemas operativos, sistemas gestores de bases de datos...
 Implantación del sistema UEAO-PE en entorno de preproducción
(integración)
9 . R E Q U E R I M I E N TO S Y P R O C E D I M I E N TO S DE
P R E PA R A C I Ó N Y R E C U P E R A C I Ó N D E D ATO S D E
P R U E B A S E N C A D A E N TO R N O
Se establece la necesidad de disponer de un conjunto de datos de pruebas

fácilmente recuperable que permita la repetición de los ciclos de pruebas en cada
entorno y en las mismas condiciones en que se realizaron.
Los datos necesarios para realizar las diferentes pruebas deben ser introducidos
en el sistema por el contratista.
1 0 . P R O C E D I M I E N TO S DE RECOPILACIÓN Y
C R I T E R I O S D E E VA L U A C I Ó N D E R E S U LTA D O S
10.1. Procedimiento de recopilación de resultados

Para el procedimiento de recopilación se aconseja la utilización una hoja Excel
con el detalle de Plan de Pruebas.
Los usuarios y el equipo de trabajo podrán realizar las pruebas necesarias en el

sistema basándose en los siguientes puntos:
 Realización de cada una de las pruebas (unitarias, integración y de
aceptación de usuario) descritas en las plantillas que proporcionará el
equipo de trabajo del contratista.
 El resultado de las mismas se irá anotando en la plantilla de prueba hasta
completar cada uno de los ciclos establecidos.
 Se calificará con un SI (correcto) o un NO (incorrecto) cada tarea de las
plantillas de prueba.
 Una vez realizadas y calificadas todas las pruebas de una plantilla, esta
será enviada junto a un informe con el resumen de los resultados
añadiendo los errores corregidos frente a cada caso de prueba y números
de casos de prueba al Jefe de Proyecto de Metro de Madrid, S.A. para su
evaluación.
En el caso de que alguna de las pruebas no termine de la forma esperada, el

equipo de analistas del contratista estudiará el caso y rellenará un formulario que
contiene los siguientes campos:
 Numero de Prueba: numero que identifica la prueba.

 Usuario: Usuario que ha realizado la prueba
 Fecha: fecha en la que se ejecuto la prueba.
 Grado del error: se evaluará el error mediante el siguiente baremo:
o 1-Alto: error que impide la continuación de la prueba
o 2-Medio: error de resultado o de comportamiento incorrecto, pero no
impide continuar la prueba ni pone en riesgo la estabilidad del
Sistema
o 3-Leve error salvable, es decir, que no impide continuar y puede
corregirse o hacerse igual de otra manera o por otra vía.
 Comentario: en este campo se puede escribir cualquier comentario que
aclare el motivo de la incidencia
 Tipo incidencia: se evaluará el tipo de incidencia según los siguientes
criterios
 defecto es cuando algo no esta bien o no permite alcanzar el
resultado esperado por mala implementación, mal diseño o mal
análisis.
 fallo es cuando algo no da el resultado esperado.

 error es cuando lo que no funciona escapa de todo lo esperado o lo
predispuesto (ejemplo: excepciones inesperadas)
10.2. Criterio de evaluación de resultados
Para dar por válida la realización de todas las pruebas definidas en el Plan de
Pruebas no debe existir ningún tipo de incidencia. En caso de que fuera así, la
Gerencia del Proyecto evaluará el resultado, y decidirá si la incidencia es motivo
suficiente para la repetición del ciclo de pruebas o si puede pasarse al siguiente
nivel de pruebas.
11 . P R O C E D I M I E N TO D E E S T I M A C I Ó N Y C R I T E R I O D E
S E L E C C I Ó N D E I N C I D E N C I A S A R E S O LV E R
El procedimiento de estimación de incidencias a resolver vendrá dado por el tipo

de incidencia a tratar, siendo las más costosas las incidencias tipificadas como
error, seguidas de las de tipo defecto y por ultimo las incidencias tipificadas como
fallo.
A continuación se describen los pasos a seguir:
 Una vez recibida la incidencia por parte del equipo de trabajo de la

empresa contratista, el personal encargado de la resolución definirá el tipo
de la incidencia según el criterio establecido.
 Se estudiará el impacto que tiene la incidencia sobre la aplicación.
 Se asignará un valor de prioridad a la incidencia, siendo más prioritarias
las de valor 1.
 Se acordará un plazo máximo de resolución de las incidencias con la
aprobación de la Gerencia del proyecto. Este plazo no debería influir en las
fechas de entrega de otros productos.
La selección de incidencias se realizará dependiendo de un valor de prioridad que
vendrá dado por la fecha de entrada de la incidencia y el tipo de incidencia.

1 2 . P R O C E D I M I E N TO DE RESOLUCIÓN Y
S E G U I M I E N TO D E I N C I D E N C I A
Estados propuestos de una incidencia:
1. Por asignar: en espera de ser asignada a una persona que la resuelva.

2. Por resolver: ya asignada, se espera a que acabe de ser resuelta.
3. Por probar: ya resuelta, debe ser probada en el próximo ciclo (si hay
alguno planificado). Si la prueba fracasa, vuelve al estado “por resolver”.
4. Cerrada: resuelta y probada satisfactoriamente.
5. Rechazada: el Equipo de Proyecto considera que una incidencia por
asignar realmente no es una incidencia, e indica las razones para ello. El
Comité de Seguimiento formado por personal de Metro de Madrid, S.A. y
del contratista decide si la cierra o si realmente debe ser resuelta, pasando
de nuevo al estado “por asignar”.
6. Pospuesta: la incidencia no tiene prioridad para ser asignada, por lo cual se
pospone su resolución o se planifica para un momento posterior. Luego
puede pasar a rechazada, retomada (para asignar) o abandonada de
acuerdo al momento en que se analice nuevamente.
7. Abandonada: el Equipo de Proyecto considera que resolver la incidencia ya
no aporta ningún beneficio o que no tiene objeto. El Comité de Seguimiento
decide si cerrarla o cambiarla al estado “por asignar” nuevamente. Este
estado es opcional ya que sólo es un caso especial de incidencia
rechazada.
Esquema propuesto de estados de una incidencia

Rechazar
1-Por 5-
asignar No-rechazar Rechazada Cerrar
Asignar
Posponer Rechazar
2-Por Retomar 6-
resolver Pospuesta
Abandonar Abandonar
Reasignar Resolver
No-abandonar
3-Por 7-
probar Abandonad
a
Cerrar
Cerrar
4-Cerrada
1 3 . C R I T E R I O S D E I N I C I O , F I N AL I Z A C I Ó N , PA R A D A Y
RECUPERACIÓN DE LAS PRUEBAS
Criterio de inicio:
Antes de comenzar las pruebas se ha de comprobar que los requisitos listados en
los puntos 7, 8 y 9 del presente documento se encuentran disponibles, que el
desarrollo del sistema esté finalizado y que estén detalladas las pruebas en el
Plan de Pruebas de la fase de Diseño (fase DSM).
Criterio de finalización:
Las pruebas se dan por finalizadas cuando todas las pruebas se han desarrollado
de forma correcta o en su defecto por decisión de la Gerencia del Proyecto.
Criterio de parada:
Se considera un criterio de parada de la realización de las pruebas cuando el
número de pruebas consideradas no correctas en una plantilla de Prueba supera
el 20% del total.

Criterio de recuperación de las pruebas:
El criterio de recuperación debe ser definido y acordado en las siguientes fases
del Proyecto.

1 4 . P L A NT I L L A D E P R U E B A
Prueba 1
Autor de la prueba:
Fecha de la prueba:
Entorno de la prueba:
Transacción / programa:
Campos obligatorios de informar:
Datos reutilizables:
Condiciones iniciales para las pruebas.

Número Condiciones Iniciales
Plan de Pruebas
Nº Prueba Valor Resultado Resultado Observaciones
Esperado Real


UEAO-PE 07092006-Plan de Pruebas v0.4

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UEAO-PE 07092006-Plan de Pruebas v0.4

Загружено:

Авторское право:

Доступные форматы

PLAN DE PRUEBAS

Análisis Unidad de Enseñanza Asistida por Ordenador

Revisado por: Fecha:

Versión Fecha Descripción

Fecha: Autor: Revisor: Código Documento: Versión: Página:

Fecha: Autor: Revisor: Código Documento: Versión: Página:

El objeto de este documento es definir el plan de pruebas del sistema, el cual

El plan de pruebas es un producto formal que define los objetivos de la prueba de

Fecha: Autor: Revisor: Código Documento: Versión: Página:

ASM: Análisis del Sistema de Información de Metro de Madrid.

Atos: Atos Origin, Sae.

ERS: Especificación de Requisitos Software.

Metro: Metro de Madrid, S.A.

SAP: Software ERP (Enterprise Resource Planning).

UEAO: Unidad de Enseñanza Asistida por Ordenador.

UEAO-PE: Unidad de Enseñanza Asistida por Ordenador del Plan de Emergencia

\\colonia\proyectos\UEAO-PE\08 - COMUN EQUIPO DE TRABAJO\01-Plan

Especificación de Requisitos Software

Fecha: Autor: Revisor: Código Documento: Versión: Página:

1. ALCANCE DE LAS PRUEBAS.....................................................................8

3. VOLUMEN, ESTIMACIONES Y PONDERACIONES DE CASOS DE

5. PRUEBAS MANUALES Y AUTOMATIZACIÓN DE PRUEBAS................14

6. PLANIFICACIÓN DE LAS PRUEBAS Y ESTIMACIÓN DE RIESGOS.....14

8. REQUERIMIENTOS Y PROCEDIMIENTOS DE PREPARACIÓN Y

9. REQUERIMIENTOS Y PROCEDIMIENTOS DE PREPARACIÓN Y

10. PROCEDIMIENTOS DE RECOPILACIÓN Y CRITERIOS DE

11. PROCEDIMIENTO DE ESTIMACIÓN Y CRITERIO DE SELECCIÓN DE

Fecha: Autor: Revisor: Código Documento: Versión: Página:

13. CRITERIOS DE INICIO, FINALIZACIÓN, PARADA Y RECUPERACIÓN

14. Plantilla de Prueba.......................................................................................23

Fecha: Autor: Revisor: Código Documento: Versión: Página:

Este documento describe la forma en que se deben realizar las pruebas

El plan de pruebas se centrará en los procesos de gestión y visualización de

Los distintos niveles de prueba que se plantean son los siguientes:

Para cada uno de estos niveles de prueba se plantea un procedimiento genérico

Fecha: Autor: Revisor: Código Documento: Versión: Página:

 El equipo del contratista preparará el entorno de pruebas con los requisitos

 La ejecución de las pruebas se realizará por el equipo responsable

 Tras su ejecución se analizarán los resultados obtenidos respecto a lo

o Si se producen desviaciones respecto a lo esperado será necesario

Fecha: Autor: Revisor: Código Documento: Versión: Página:

Los diferentes niveles de pruebas a realizar son los siguientes:

En el proceso de desarrollo del Sistema UEAO-PE se considera imprescindible,

Mediante estas pruebas se verificará, la consistencia de los distintos

Fecha: Autor: Revisor: Código Documento: Versión: Página:

Las pruebas de Integración deben ser realizadas y finalizadas por el equipo de

Estas pruebas están encaminadas a asegurar la consistencia entre los

Se distinguen dos grupos de pruebas:

 Pruebas de funcionalidad para verificar que se cumplen los requisitos

o Pruebas de Volumen y de Automatización:

El equipo contratista debería proporcionar a la Gerencia de Desarrollo

El objetivo es asegurar que tanto el acceso a los datos como el tiempo

Fecha: Autor: Revisor: Código Documento: Versión: Página:

También Metro se reserva el derecho a que esas pruebas se realicen

o Pruebas de operatividad de puestos cliente:

Basadas en verificar la correcta implementación de los mismos. Estas

 Pruebas de Implantación y Aceptación

Estas pruebas se desarrollarán en el entorno de pre-producción, simulando

Pruebas de autorizaciones: Consiste en realizar las pruebas de todas las

Tanto las pruebas de funcionalidad como de autorizaciones se deberán realizar

Fecha: Autor: Revisor: Código Documento: Versión: Página:

Las pruebas unitarias deberán realizarse al finalizar la construcción de cada

Para las pruebas de Integración, de Volumen y de Sistemas se estima una

Los ciclos de pruebas permiten repetir pruebas relacionadas con incidencias