Guia de Metodologia de Pruebas

GUA METODOLOGA DE PRUEBAS
Versin: v1.1
Autor: ODP-CALIDAD de Metodologa
Direccin de Sistemas de Informacin
Gua de Metodologa de Pruebas v1.1.doc
Pg. 1 de 29
Contenido
1. OBJETIVO........................................................................................................................... 4
2. PROYECTOS DE DESARROLLO ........................................................................................ 4
2.1.
PLANIFICACIN ........................................................................................................................... 4
2.2.
ESPECIFICACIN......................................................................................................................... 5
2.3. EJECUCIN .................................................................................................................................. 8

2.3.1
Pruebas Unitarias Bsicas ...................................................................................................... 9
2.3.2
Pruebas Unitarias ................................................................................................................. 10
2.3.3
Pruebas Integradas ............................................................................................................... 10
2.3.4
Pruebas de Aceptacin ......................................................................................................... 11
2.3.5
Pruebas de Regresin........................................................................................................... 12
2.3.6
Registro de Incidencias ......................................................................................................... 12
2.4.
ESTABILIZACIN........................................................................................................................ 12
2.5.
CIERRE DE LA ACTIVIDAD ........................................................................................................ 12
2.6. SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 14

2.6.1
Informe de Avance de Ejecucin de Pruebas ........................................................................ 14
2.6.2
Informe de Seguimiento de Defectos ..................................................................................... 14
3. ACTIVIDAD DE MANTENIMIENTO DE APLICACIONES .................................................... 15

3.1.
PLANIFICACIN ......................................................................................................................... 15
3.2.
ESPECIFICACIN....................................................................................................................... 16
3.3. EJECUCIN ................................................................................................................................ 16

3.3.1
Pruebas Unitarias Bsicas .................................................................................................... 18
3.3.2
Pruebas Unitarias ................................................................................................................. 18
3.3.3
Pruebas Integradas ............................................................................................................... 18
3.3.4
Pruebas de Aceptacin ......................................................................................................... 18
3.3.5
Pruebas de Regresin........................................................................................................... 18
3.3.6
Registro de Incidencias ......................................................................................................... 18
3.4.
3.5. SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 19

3.5.1
Informe de Escenarios .......................................................................................................... 19
3.5.2
Informe de Estado de Defectos por Peticin .......................................................................... 19
4. PROYECTOS DE LABORATORIO..................................................................................... 20
4.1.
PLANIFICACIN ......................................................................................................................... 21
4.2.
ESPECIFICACIN....................................................................................................................... 21
4.3.
EJECUCIN ................................................................................................................................ 22
Pg. 2 de 29
4.4.
4.5.
SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 22
5. PROYECTOS DE INFRAESTRUCTURA ............................................................................ 22

5.1.
PLANIFICACIN ......................................................................................................................... 23
5.2.
ESPECIFICACIN....................................................................................................................... 24
5.3.
EJECUCIN ................................................................................................................................ 24
5.4.
5.5.
SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 25
6. OTRAS ACTIVIDADES ...................................................................................................... 25

6.1. PRUEBAS DE RENDIMIENTO .................................................................................................... 25
6.1.1
Planificacin.......................................................................................................................... 25
6.1.2
Especificacin ....................................................................................................................... 26
6.1.3
Ejecucin .............................................................................................................................. 26
6.2.
PRUEBAS DE SEGURIDAD ........................................................................................................ 26
6.3.
PARADAS Y/O REARRANQUES DEL SISTEMA ......................................................................... 27
6.4.
DISPONIBILIDAD DEL ENTORNO DE PRUEBAS Y JUEGOS DE DATOS.................................. 27
6.5.
AUTOMATIZACIN DE PRUEBAS.............................................................................................. 28
Control de Versiones
Versin
V1.0
V1.1
Responsable
JRA
CdM
Fecha
25/11/11
19/04/2012
Descripcin del cambio

Creacin del Documento
Informacin adicional para los escenarios de prueba.
Pg. 3 de 29
1.
OBJETIVO
El objetivo de este documento es establecer una gua de trabajo para la realizacin de Pruebas en las
distintas actividades de Sistemas en las que son de aplicacin.
Para ello, se han tenido en cuenta las siguientes actividades:
2.
Proyectos de Desarrollo
Mantenimiento de Aplicaciones
Proyectos de Laboratorio
Proyectos de Infraestructura
Pruebas de Rendimiento
Pruebas de Seguridad
Paradas y/o Rearranques del Sistema
Disponibilidad del Entorno de Pruebas y Juegos de Datos
Automatizacin de Pruebas
PROYECTOS DE DESARROLLO
Se consideran Proyectos de Desarrollo a aquellos proyectos que contienen en mayor o menor medida el
desarrollo y/o parametrizacin de Software que ser utilizado por los usuarios finales.
La instalacin de Software de terceros de forma directa, es decir, sin parametrizacin, lleva el tratamiento de
Proyecto de Infraestructura.
2.1.
PLANIFICACIN
El documento del Plan de Pruebas es de carcter obligatorio para todos los proyectos de Desarrollo
Para la confeccin del Plan de Pruebas hay que tener en cuenta los siguientes aspectos:
Definicin de los Escenarios de Pruebas que han sido elegidos por el Negocio como Criterios de
Aceptacin del Sistema.
Preparacin del entorno de pruebas a utilizar y su conveniente segregacin del entorno de
Desarrollo para que las pruebas sean fiables y que su configuracin sea lo ms cercana posible al
entorno de Produccin.
Se debe prestar especial inters en la calidad de los juegos de datos disponibles para la realizacin
de las pruebas.
Identificar si se realizarn Pruebas especficas de Seguridad o Rendimiento que sean de aplicacin
en el Proyecto.
Considerar la automatizacin de escenarios de prueba que puedan ser reutilizados como Pruebas
de Regresin en las labores de Mantenimiento.
Herramientas: Preparacin del Entorno de Trabajo Definicin del Proyecto
Pg. 4 de 29
Es necesario realizar la preparacin del entorno de trabajo en la Herramienta Quality Center (QC) y decidir
si el proyecto se realizar en un proyecto independiente de QC o, si se realizar en el repositorio comn
de pruebas para el Negocio.
En el caso en que sea el desarrollo de una aplicacin nueva, se partir de la estructura vaca, predefinida
por el marco metodolgico.
En el caso de que el proyecto conlleve modificaciones a una aplicacin existente, se deber de tener en
cuenta la definicin de requisitos y casos de prueba prexistentes para dicha aplicacin, al igual que los
escenarios de ejecucin de pruebas existentes para ser reutilizados y modificados. En este caso, tambin
se deben considerar aquellos escenarios que debern de ser ejecutados en el mbito de las Pruebas de
Regresin.
2.2.
ESPECIFICACIN
Dentro de un Proyecto de Desarrollo la mayora de las pruebas que se definen son Pruebas Funcionales,
que son las encaminadas a probar los Requisitos Funcionales. Debe de considerarse la reutilizacin de
pruebas funcionales existentes.
Adicionalmente, se debern de definir las pruebas a realizar para probar los Requisitos No Funcionales que
se hayan definido. Por ejemplo, la consulta de un Sistema externo a la aplicacin desarrollada puede servir
de comprobacin de un requisito de integracin entre sistemas, la prueba de la entrada al sistema con
distintos usuarios puede servir como comprobacin de un requisito de seguridad, etc.
Hay otro tipo de pruebas que son de carcter no funcional. Por ejemplo, verificacin de que existe un log de
auditora del sistema para poder cumplir la ley SAROX, anlisis del tiempo de respuesta en escenarios de
estrs para la realizacin de pruebas de rendimiento, etc.
Todo proyecto que tenga un componente de instalacin de nuevas Infraestructuras (HW y/o SW), debern
tener definidas las Pruebas de Infraestructura necesarias para comprobar los nuevos componentes de
arquitectura implementados. Estas sern realizadas por el equipo de P&I y son de carcter tcnico, si bien
al probar funcionalmente la aplicacin se est comprobando que la infraestructura est resolviendo las
necesidades para las que ha sido prevista. Por ejemplo: Pruebas de encendido y apagado de mquinas,
levantamiento de servicios, comunicacin entre elementos de infraestructura, etc.
A la hora de la definicin de los Escenarios de Prueba a ejecutar en el proyecto, se debe de tener en cuenta
su futura reutilizacin por parte del equipo de Mantenimiento y, sobre todo, en la realizacin de Pruebas de
Regresin. As mismo, se elegirn aquellos escenarios de prueba que vayan a ser automatizados.
Herramientas: Carga de Requisitos, Definicin de Casos de Prueba y de Escenarios de Prueba
Carga de Requisitos
Pg. 5 de 29
Antes de realizar la definicin de los casos de prueba se deben de cargar los Requisitos desde la
herramienta Enterprise Architect (EA) en el mdulo Requirements. Para ello, existe una funcin destinada a
este cometido que se ejecuta desde EA.
Los Requisitos se organizarn en QC de forma idntica a como estn organizados en EA, es decir,
organizados por Aplicaciones y Grupos de Funcionalidades. Esto permitir una mayor facilidad de uso y
transportabilidad.
Definicin de Casos de Prueba

Es posible, cargar los Casos de Prueba desde la plantilla Excel definida en la Metodologa, si bien, esta
solamente se podr utilizar para cargar nuevos casos de prueba, y, a ser posible, esta accin debera de
realizarse una nica vez en cada proyecto con el objeto de optimizar el trabajo de los administradores de la
herramienta.
La definicin de los Casos de Prueba se realiza dentro del mdulo Test Plan y su estructura debe ser similar
a la estructura de Requisitos existente, para facilitar su bsqueda y trazabilidad.
Pg. 6 de 29
Todo caso de Prueba Funcional debe estar trazado con al menos un Requisito Funcional y todos los
Requisitos Funcionales debern de ser probados con al menos tantos casos de Prueba como Flujos
contengan (Normal y Alternativos).
Una correcta priorizacin de los casos de prueba permitir la optimizacin de la ejecucin de los mismos, ya
que, en caso de falta de tiempo, se podr recortar la ejecucin de los menos prioritarios.
Se debe tener especial cuidado en no duplicar casos de prueba. Un caso de prueba puede ser ejecutado
distintas veces con diferentes datos de ejecucin, dependiendo del escenario de prueba que se requiera
probar.
La definicin de los Casos de Prueba debe realizarse teniendo en cuenta que estas definiciones van a ser
reutilizadas en la Actividad de Mantenimiento.
A cada caso de prueba se le puede asignar un Grupo Funcional que permite distribuir las pruebas entre los
usuarios responsables de realizarlas.
Definicin de Escenarios de Prueba

Los nuevos escenarios de prueba que vayan a quedar para la actividad de mantenimiento debern definirse
en el catlogo de escenarios para su posterior uso en la fase de ejecucin en el mdulo Test Lab.
Algunos de estos escenarios de prueba sern calificados para su uso en las pruebas de regresin, estos
debern ser tenidos en cuenta para una posible automatizacin de pruebas.
A cada escenario de prueba se le puede asignar la siguiente informacin:
Regresin. Identifica al escenario de prueba como candidato para su ejecucin en la actividad de

pruebas de regresin dentro del alcance de un mantenimiento y para ser utilizado dentro del
Pg. 7 de 29
catlogo de escenarios, as como, en un futuro abordar la actividad de automatizar todos los casos
de prueba que lo componen.
2.3.
Prioridad. Permite dotar al escenario de un nivel importancia / criticidad para focalizar el esfuerzo en
aquellos ms prioritarios para el xito de la prueba. Por ejemplo, aquellos escenarios que deben
finalizar satisfactoriamente para que el usuario acepte el sistema. Esta prioridad est directamente
asociada al ciclo de prueba, por eso se asigna en cada escenario, y puede variar entre diferentes
ciclos de prueba.
EJECUCIN
La ejecucin de las pruebas deber de llevarse a cabo a travs de las distintas actividades de ejecucin
definidas, organizadas por Ciclos de Ejecucin.
Los Ciclos que estn definidos en la Metodologa para todos los proyectos son:
Unitarias Bsicas
Unitarias
Integradas
Aceptacin de Usuario
Opcionalmente, segn las necesidades de cada proyecto podra haber un Ciclo de Regresin.
Una forma sencilla de identificar las distintas actividades de prueba a realizar es enfrentndolo con el
entorno de trabajo donde son ejecutadas.
Unitarias Bsicas Entorno Local y/o Desarrollo
Unitarias Entorno de Desarrollo
Integradas Entorno de Desarrollo (las que sean posibles en este entorno) y Entorno de Preproduccin /
Pruebas
Aceptacin Entorno de Preproduccin
Herramientas: Organizacin de las Pruebas en Ciclos de Ejecucin, Seguimiento de la actividad de
Ejecucin y Registro de Incidencias
La organizacin de la ejecucin de las pruebas en Ciclos es fundamental para poder obtener mtricas de
cobertura y completitud y, as poder determinar la finalizacin de cada Ciclo. Para ello, la organizacin por
Ciclos de Ejecucin debe de reflejarse en los dos mdulos de la herramienta Management, donde se refleja
la organizacin de las ejecuciones:
Pg. 8 de 29
Y el mdulo Test Lab donde se almacenan los resultados de las ejecuciones, estos Ciclos deben estar
relacionados con los Ciclos de Management:
Dentro de cada Ciclo se pueden generar los ciclos secundarios que se consideren oportunos con el objeto
de tener un control mucho ms preciso de cada actividad.
Las Pruebas No funcionales, es decir, de Seguridad, Rendimiento o de Infraestructura tendrn un Ciclo
especfico para poder llevar el tratamiento en la herramienta de forma diferenciada y, de este modo, no se
tendrn en cuenta para la elaboracin de informes que correspondan a los ciclos de Unitarias, Integracin y
Aceptacin, con el objeto de no distorsionar el anlisis del seguimiento de la actividad.
Durante la ejecucin de las actividades de pruebas y cuando se producen fallos en la ejecucin de las
pruebas se debe de generar una incidencia en el mdulo Defects, la cual sigue un workflow predefinido (ver
Metodologa) para gestionar el arreglo de la misma. La herramienta QC tiene un workflow predefinido que
puede ser adaptado segn las necesidades de cada Proyecto.
2.3.1
PRUEBAS UNITARIAS BSICAS
Pg. 9 de 29
Las pruebas unitarias bsicas son responsabilidad del Equipo de Desarrollo, esta actividad normalmente es
realizada por el equipo del Proveedor del Proyecto cerrado contratado al efecto, en otro caso, lo realiza
Desarrollo.
Son pruebas tcnicas de bajo nivel o de carcter funcional limitado, de cada uno de los componentes.
En el caso de entornos de desarrollo en tecnologa Web conllevan la construccin de scripts de prueba que
permitan realizar estas pruebas unitarias bsicas y deben ser registradas en Team Foundation Server
(TFS). Por ejemplo, la prueba de un mtodo dentro de cada clase en entornos Web, genera una clase
paralela para probarla.
En entorno SAP, tambin se podra hablar, en este caso, de la prueba individual de un componente que
compone una envolvente, etc. en este caso, no es comn la realizacin de programas de prueba y
normalmente se prueban directamente con pruebas de carcter funcional que son registradas en la
actividad de pruebas unitarias.
En aquellos casos donde se tiene un repositorio de pruebas tcnicas, tal como se hace en tecnologa Web,
es obligatorio el registro de las pruebas unitarias bsicas. En otro caso, la Prueba Unitaria, al ser de
carcter funcional, es suficiente para garantizar el funcionamiento del sistema y, por tanto, no es obligatorio
su registro, ya que se tendr un registro mucho ms amplio en la actividad de pruebas unitarias y el
responsable de esta actividad y de la de pruebas unitarias coinciden.
Las Pruebas de Infraestructura para certificar el entorno de Desarrollo deben de realizarse antes de su
utilizacin por los equipos de Desarrollo, no es obligatorio realizar el registro de estas pruebas en QC. Ser
de aplicacin en aquellos proyectos en donde haya algn componente de instalacin Hardware y/o Software
en el que se vea afectado dicho entorno.
2.3.2
PRUEBAS UNITARIAS
Las pruebas unitarias son responsabilidad del Equipo de Desarrollo, esta actividad normalmente es
realizada por el equipo del Proveedor del Proyecto cerrado contratado al efecto, en otro caso, lo realiza
Desarrollo.
Son pruebas sobre la funcionalidad del Sistema. La ejecucin de las Pruebas Funcionales del Sistema es la
mayor parte de esta actividad de pruebas. Para que se haya cubierto con xito esta etapa, se debe de
haber cubierto el 100% de la funcionalidad del sistema, y al menos debern de haberse ejecutado los casos
de prueba de prioridad alta y media.
2.3.3
PRUEBAS INTEGRADAS
Las Pruebas Integradas son responsabilidad de la Cuenta, si bien esta actividad normalmente es realizada
por el equipo del Proveedor del proyecto cerrado contratado al efecto, en otro caso, lo realiza la Cuenta
siendo normalmente apoyado por Desarrollo, todo depender del grado de conocimiento de cada rea en
cada caso. De todos modos, se deber de producir una aceptacin de las pruebas integradas por parte de
la Cuenta con el objeto de permitir dar el paso a la siguiente actividad de ejecucin de las Pruebas de
Aceptacin por parte del Usuario.
Pg. 10 de 29
Esta ejecucin se realiza mediante la composicin de Escenarios de Pruebas que resuelven un conjunto de
actividades del Proceso de Negocio. En este escenario se combina la funcionalidad de distintos Casos de
Uso, que pueden pertenecer incluso a distintas aplicaciones. Esto se hace de este modo, con el fin de
asegurar un correcto funcionamiento del Sistema una vez integrado su funcionamiento con los distintos
aplicativos que se puedan ver afectados.
Es importante, para ello, tener un buen entorno de Integracin donde se pueda simular correctamente el
modelo de ejecucin en Produccin y un juego de datos lo ms parecido ha dicho entorno.
Las Pruebas de Rendimiento deben de realizarse en el entorno de Integracin como parte de la actividad de
Pruebas de Integracin en aquellos proyectos donde se hayan prescrito. Normalmente no es necesario su
registro en QC y realizndose con el apoyo de la herramienta LoadRunner. En el caso de tecnologa BI,
existe un documento especfico para la documentacin de estas pruebas.
Las Pruebas de Infraestructura para certificar el entorno de Integracin deben de realizarse antes de su
utilizacin por los equipos del Proyecto. As mismo, previo al despliegue de la aplicacin en Produccin
debern de realizarse tambin las pruebas del entorno de Produccin. Estas pruebas no es obligatorio su
registro bajo QC y sern de aplicacin en aquellos proyectos en donde haya algn componente de
instalacin Hardware y/o Software en el que se vea afectado alguno de los entornos.
Las Pruebas de Seguridad se realizarn normalmente mediante la ejecucin de casos de prueba
especficos, en el que se ejecuta la aplicacin para comprobar los accesos del usuario. Estos casos de
prueba se identificarn en un apartado especfico para ello y no es necesario alimentar su trazabilidad con
los requisitos. Este tipo de pruebas es un escenario tpico para proceder a su automatizacin.
De otro modo, la prueba se puede realizar de forma tcnica, como podra ser el anlisis de cdigo para
verificar los estndares de seguridad en entornos Web. En este caso, no es obligatorio su registro en HP
QC.
2.3.4
PRUEBAS DE ACEPTACIN
Las Pruebas de Aceptacin son responsabilidad del Negocio, la Cuenta guiar al Negocio para su correcta
ejecucin. Normalmente el Negocio registrar el resultado de las pruebas en la herramienta QC, no
obstante, en el caso en el que el Negocio no realice este registro, deber ser la Cuenta quien deba de
realizar su registro en la herramienta.
El registro de las Pruebas de Aceptacin por parte del Negocio en QC proporciona la evidencia necesaria
para la ejecucin de las pruebas ante controles de auditora, ya que en ella se guarda registro del usuario
que las realiz y el momento en que fueron realizadas. El Negocio deber de enviar un correo de
aceptacin del paso a produccin adjuntando la evidencia de las pruebas realizadas, basta con un link a la
herramienta identificando el Ciclo de Ejecucin de Pruebas donde se haya ejecutado. En el caso en que la
Cuenta sea quien las hubiera registrado en la herramienta, el usuario deber de manifestar en el correo de
aceptacin, que el mismo las ha realizado.
Pg. 11 de 29
2.3.5
PRUEBAS DE REGRESIN
Las Pruebas de Regresin son de aplicacin en proyectos en los que se realice un evolutivo de una
aplicacin existente, se est realizando una implantacin por fases dentro de una misma aplicacin, o bien
que la implantacin realizada pudiera afectar al funcionamiento de otra aplicacin. El objetivo es obtener
garanta de que la implantacin que se vaya a realizar no impacte en las funcionalidades que ya est
usando el Negocio en productivo.
Deben de identificarse los escenarios de prueba de regresin con el objeto de ser utilizados en
mantenimiento. Estos escenarios sern los mximos candidatos para la realizacin de automatizacin de
pruebas.
2.3.6
REGISTRO DE INCIDENCIAS
El registro de incidencias durante la ejecucin de las actividades de pruebas origina un flujo de trabajo con
el objeto de poder realizar un seguimiento de las mismas.
Por este motivo, es obligatorio realizar el registro de incidencias cuando haya un equipo de trabajo que deba
de arreglar un defecto distinto a quien ha levantado el mismo. Tpicamente el registro de incidencias surge
en las actividades de Integracin y Aceptacin. Sin embargo, en la actividad de pruebas unitarias es
opcional, pues el equipo de Desarrollo encargado de ejecutarlas puede ser el mismo que deba de reparar el
defecto y, por tanto, aadira una sobrecarga de gestin que no es necesaria dentro de esta actividad.
2.4.
ESTABILIZACIN
El periodo de estabilizacin comienza una vez realizada la implantacin en Produccin y termina en el plazo
en que se haya acordado entre Cuenta y Negocio en el plan del proyecto. En definitiva, se trata de un
periodo de garanta para resolver las incidencias que se presenten por el uso de la aplicacin en
Produccin, antes de ser traspasada a la actividad de Mantenimiento.
Durante este periodo se debern de registrar las incidencias que se produzcan, con el fin de resolverlas. Si
se considera necesario, es posible cargar las incidencias en QC desde la plantilla de registro de incidencias
provista por la Metodologa, sin embargo se recomienda realizar esta actividad dentro de la herramienta ya
que esto permite seguir el flujo de trabajo definido para la resolucin de incidencias.
2.5.
CIERRE DE LA ACTIVIDAD
En la finalizacin del proyecto se debe de realizar la actividad de traspaso a Mantenimiento de aquellos

elementos que vayan a ser necesarios para dicha actividad.
La informacin que deber de utilizarse en la actividad de Mantenimiento es la Definicin de los Casos de
Prueba y la definicin de los Escenarios de Prueba.
Todos los defectos que hayan quedado pendientes a lo largo del proyecto debern ser cerrados, es decir,
se tomar la decisin de que defectos se descartarn para su posterior arreglo o cuales deben ser tenidos
en cuenta para su arreglo en la actividad de mantenimiento.
Pg. 12 de 29
Herramienta:
Desde el rea de trabajo destinada para el proyecto se deber de consolidar la definicin de Casos de
Prueba al rea de Mantenimiento, en el caso de haber utilizado reas separadas de trabajo para ello.
Del mismo modo, se deber de consolidar la definicin de Escenarios de Prueba dentro del apartado
especfico habilitado para su reutilizacin Catlogo de Escenarios.
Los defectos que estn abiertos se debern de pasar al estado Paso a Correctivo o Descartado.
Pg. 13 de 29
Hay que tener en cuenta que se deben de cargar los casos de prueba y su relacin con los requisitos sobre
la herramienta EA.
2.6.
SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS
Para realizar el seguimiento de la actividad de pruebas se dispone de las mtricas definidas en la

Metodologa.
Se pueden obtener las siguientes grficas para los distintos ciclos de ejecucin que se realicen:
2.6.1
INFORME DE AVANCE DE EJECUCIN DE PRUEBAS
Avance en Ejecucin de Pruebas
La grafica nos muestra la cantidad de casos de prueba ejecutados y su estado resultante, es decir, si el
estado es: Fin OK, Fin con Incidencias, En Curso, Pendiente o Fin con Mejoras.
2.6.2
INFORME DE SEGUIMIENTO DE DEFECTOS
Este informe permite comprobar que al final de la prueba el acumulado de defectos cerrados converge hacia
el acumulado de los abiertos.
Tambin se registran los defectos abiertos y cerrados por da.
Pg. 14 de 29
Defectos
Abiertos
vs Cerrados
Acumulado Apertura
Vs Cierre
de Defectos
60
N Incidencias
50
40
30
20
10
0
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
Abiertas
Acum. Abiertas
16
21
24
32
41
47
52
55
57
57
Cerradas
Acum. Cerradas
13
16
19
22
25
29
34
41
t13
t14
t15
Ambas grficas debern de converger en el mismo punto una vez finalizado el proyecto. Es importante
establecer el punto de inicio del periodo de estabilizacin, pues si no decrece el hallazgo de incidencias,
podra poner en riesgo su pase a Mantenimiento.
3.
ACTIVIDAD DE MANTENIMIENTO DE APLICACIONES
Para la realizacin de Mantenimiento de Aplicaciones se deben de realizar las mismas actividades definidas
para los Proyectos de Desarrollo comentadas en el captulo anterior. Si bien, al ser trabajos menores
evolutivos o correctivos, implica que haya una serie de pautas especficas de trabajo ms simplificadas que
en un Proyecto completo.
La actividad de Mantenimiento se organiza en base a Peticiones y estas son el elemento organizativo a
travs del que se realiza la actividad de Pruebas.
En el desarrollo del captulo se comentan las actividades diferenciales propias del proceso de
mantenimiento.
3.1.
PLANIFICACIN
No es obligatoria la realizacin de un documento de Planificacin de Pruebas, ya que la infraestructura

necesaria para la realizacin de pruebas debe de existir previamente, as como los juegos de datos
disponibles para la actividad.
Sin embargo, se debern de identificar los escenarios de pruebas que van a ser probados para conseguir la
aceptacin del usuario, tanto si son prexistentes como si son nuevos escenarios que se deban de construir
Pg. 15 de 29
como consecuencia de un mantenimiento evolutivo. En el caso de mantenimiento correctivo suele ser

suficiente con probar la funcionalidad afectada de forma unitaria.
Es una buena prctica identificar los casos de prueba y escenarios que se van a usar en la actividad de
pruebas que estn previamente definidos y disponibles para su utilizacin y analizar el volumen de trabajo a
realizar para la definicin de nuevos elementos con el objeto de planificar la actividad de forma correcta.
Herramienta:
En el caso de Mantenimiento Evolutivo se proceder a dar de alta un nuevo Ciclo dentro del mdulo de
Management que permita gestionar la actividad de pruebas de la peticin correspondiente.
En el caso de Mantenimiento Correctivo se puede optar por utilizar el Ciclo de Peticiones de Gestin Menor
habilitado especficamente. La Cuenta decidir si una peticin externa debe gestionarse mediante un ciclo
independiente, o bien, si se gestiona dentro del Ciclo de Peticiones de Gestin Menor.
3.2.
ESPECIFICACIN
No hay diferencia con la actividad en Proyectos de Desarrollo.

En el caso en que haya nuevos requisitos, estos debern de cargarse en QC para que quede
completamente actualizado el mdulo de Requeriments. Se debe poner especial cuidado en el caso en que
haya baja de requisitos, esta no es automtica y debern de eliminarse manualmente. Esto conllevar el
anlisis de ver si es necesario eliminar los casos de prueba que estn relacionados con estos requisitos.
La definicin de los casos de prueba y escenarios de prueba se debe de realizar poniendo especial cuidado
en no duplicar las definiciones existentes y reutilizar al mximo las mismas, esto simplificar mucho el
trabajo en la actividad de mantenimiento actual y futura.
3.3.
EJECUCIN
Pg. 16 de 29
Los ciclos de ejecucin son exactamente los mismos que en un Proyecto de Desarrollo, si bien,
normalmente no es necesario establecer ciclos diferenciados para esta actividad, ya que esto podra gravar
el tiempo de ejecucin de la implantacin de la peticin.
Para esta actividad, los ciclos de ejecucin estn organizados de manera distinta a la actividad de
Proyectos. En este caso, se diferencia claramente la actividad del rea de Desarrollo de la del rea de la
Cuenta (Integracin y Aceptacin) manteniendo cada una de ellas una organizacin vinculada a la forma de
actuar de cada rea operativa.
Para el rea de Desarrollo se mantiene una organizacin vinculada a los grupos de Desarrollo en los que
est subdividida: Mdulos de SAP, Portal, Gestin Documental, BI, etc. Dentro de cada organizacin se
darn de alta las Peticiones Externas correspondientes y colgando de esta, las Peticiones Internas de las
que cada grupo de Desarrollo es responsable si as fuera necesario para la operativa de la actividad. Los
ciclos de ejecucin podrn ser nicos o aquellos que considere oportunos cada grupo. En esta rea se
realizar principalmente la actividad de pruebas unitarias, aunque dependiendo de cada caso concreto
podrn realizarse tambin pruebas de integracin.
Para el rea de Cuenta se ha definido una carpeta donde se realizarn las actividades de Integracin y
Aceptacin, a su vez esta carpeta se subdivide mediante criterios organizativos del Negocio, es decir, por
grupos de usuarios. Dentro de cada grupo estarn las peticiones de su responsabilidad.
Esto facilitar la actividad de pruebas de aceptacin, ya que el usuario de Negocio cuando acceda a la
herramienta para la realizacin de pruebas solo tendr que buscar su propia carpeta y, dentro de esta, la
peticin externa que debe ser probada.
Las Peticiones externas en ambas reas de trabajo debern estar vinculadas a la correspondiente peticin
dentro del mdulo Management, para poder gestionar la actividad completa a dicha peticin.
Las peticiones externas dentro del Ciclo de Peticiones de Gestin Menor debern de darse de alta para
poder establecer las pruebas realizadas dentro de la misma, si bien no van relacionadas con un ciclo de
prueba especfico para la peticin.
Pg. 17 de 29
3.3.1
PRUEBAS UNITARIAS BSICAS

3.3.2
PRUEBAS UNITARIAS

3.3.3
PRUEBAS INTEGRADAS

3.3.4
PRUEBAS DE ACEPTACIN

3.3.5
PRUEBAS DE REGRESIN
En la actividad normal de Mantenimiento, deben de realizarse las pruebas de regresin necesarias para
garantizar que el resto de los sistemas que pudieran verse afectados por la peticin no hayan sido
afectados.
3.3.6
REGISTRO DE INCIDENCIAS
Pg. 18 de 29
3.4.
No hay diferencia con la actividad en Proyectos de Desarrollo. nicamente hay que tener en cuenta que se
deben de volver a recargar los casos de prueba y su relacin con los requisitos sobre la herramienta EA,
esta informacin sustituir la que exista previamente en dicha herramienta.
3.5.
Para realizar el seguimiento de la actividad de pruebas de una actividad de mantenimiento individual se

pueden obtener los informes descritos en el apartado de Proyectos.
Adicionalmente a esto, tambin se pueden obtener los siguientes informes que analizan de forma global la
actividad de mantenimiento para un rea de negocio determinada:
3.5.1
INFORME DE ESCENARIOS
Cant.Escenarios
Usuario Clave
CONSTRUCCION
INSTALACIONES
Nivel Prueba
EstadoEscenario
Pruebas Cuenta Pruebas Usuario Total general
Peticin
252486 - Editar importes pedido CRG obras MUN act AVN,PPP,AVE Fin OK
2
252487 - Gestin de errores en contabilizacin de certificaciones
Fin OK
En Curso
1
Pendiente
5
252488 - N de actuacin/oferta en las certificaciones de obra de GEOS
Fin OK
Pendiente
2
252489 - Gestin de certificacin de supervisin en granel
Fin OK
Pendiente
2
261464 - Correccin de errores en la creacin de solicitudes de equipos
Fin OK
Pendiente
3
253742 - Perfil de fabricante de equipos en BP5
Fin OK
1
En Curso
262657 - ZB_PM_LUGARES
Fin OK
1
Pendiente
252490 - Fecha de Alta / Baja en la seleccin de interlocutores
Fin OK
En Curso
2
Pendiente
3
Revisar
257763 - Modificacin de la longitud del nmero de orden de las acometidas
Fin OKen el libro de tubos
Pendiente
4
253744 - Informe de autofctura.
Fin OK
Pendiente
1
255478 - Identificacin de contratos fuera de periodo de vigencia
Fin OK
Pendiente
3
272779 - Correctivo problema en certificaciones OT
Fin OK
1
267123 - Segunda Inspeccin para Granel en GEOS
Fin OK
Pendiente
1
Total CONSTRUCCION INSTALACIONES
32
2
6
2
2
2
1
1
4
1
4
1
3
1
1
31
4
6
1
5
2
2
2
2
2
3
1
1
1
1
4
2
3
1
4
4
1
1
3
3
2
1
1
63
Este informe permite establecer el nmero de escenarios ejecutados en cada peticin y su estado final, con
lo que nos da una visin de la finalizacin de las pruebas en cada una de las peticiones en curso.
3.5.2
INFORME DE ESTADO DE DEFECTOS POR PETICIN
Pg. 19 de 29
Defectos
Usuario Clave
CONSTRUCCION
INSTALACIONES
ESTADO
Peticin
Nivel Prueba
252486 - Editar importes pedido CRG
Pruebas Usuario
obras MUN act AVN,PPP,AVE
252490 - Fecha de Alta / Baja en la

seleccin de interlocutores
Total CONSTRUCCION INSTALACIONES
MANTENIMIENTO
253465 - Visualizacin mdulos
INSTALACIONES DE
contrato de granel
CLIENTES
260992 - CGLP-SRG: Visualizacin
de los pedidos de TLM-TLG en la
pantalla de SRG:Datos Instalaciones
258252 - CGLP-BP5: Programa carga
masiva pedidos de gas de
267416 - Volcado masivo de ssdd de
sustitucin de contador
Total MANTENIMIENTO INSTALACIONES DE CLIENTES
MANTENIMIENTO Y
257762 - Adaptacin pantallas
ASISTENCIA TECNICA
solicitud de revisin
257759 - Adaptacin pantallas revisin
Total MANTENIMIENTO Y ASISTENCIA TECNICA
PRODUCTO
256871 - Rectificacin ticket
ENVASADO
suministro PPVV
Total PRODUCTO ENVASADO
Total
CRITICIDAD
3. Media
Pruebas Usuario
2. Alta
3. Media
Pruebas Usuario
Hallado
Asignado
Corregido
Rechazado
Cerrado
Total
1
1
1
3. Media
2
1
3
1
Pruebas Usuario
4. Baja
Pruebas Usuario
3. Media
Pruebas Cuenta
3. Media
2. Alta
1
3
1
1
1
Pruebas Cuenta
3. Media
Pruebas Usuario
3. Media
Pruebas Cuenta
3. Media
1
2
1
5
1
1
1
1
2
3
1
1
6
1
12
Este informe nos da una visin de los defectos hallados y su situacin por cada una de las peticiones de
Mantenimiento.
4.
PROYECTOS DE LABORATORIO
Se consideran Proyectos de Laboratorio a aquellos proyectos en los que se prueba que una determinada
plataforma tecnolgica dada puede soportar un conjunto de procesos de Negocio en un entorno productivo.
Hay distintos tipos de proyectos de laboratorio, dependiendo de las actividades a realizar dentro del mismo,
en este caso, conviene distinguir los Proyectos de Investigacin los cuales se efectan para probar una
determinada plataforma con el fin de conocer sus posibilidad; o bien Proyectos Piloto, en los que una vez
elegida una plataforma se trata de estudiar la configuracin necesaria para su puesta en marcha en
productivo, y probar que cubre las necesidades objetivo del proyecto, estos ltimos proyectos habitualmente
derivan en la ejecucin inmediata de un proyecto de implantacin..
En los Proyectos de Investigacin interviene casi exclusivamente Arquitectura y, al ser un trabajo de
investigacin no es necesario registrar formalmente la actividad de Pruebas, opcionalmente se registrar el
Plan de Pruebas y las Pruebas de Aceptacin.
En los Proyectos Piloto, al ser orientados de forma directa al Negocio, suele intervenir la Cuenta con el
objeto de solucionar un problema de Negocio concreto, por ello debe haber un Plan de Pruebas y el resto
de actividades de pruebas debern ser acordada su realizacin entre Cuenta y Arquitectura. Una vez
finalizado el proyecto debern de realizar las pruebas de aceptacin y deber de haber una aprobacin
formal del resultado del proyecto que permita abordar la futura instalacin de la nueva plataforma.
En cualquier caso, se deben realizar Pruebas de Infraestructura para probar el funcionamiento correcto de
la plataforma a instalar, Pruebas de Rendimiento que permitan establecer el correcto dimensionamiento de
la plataforma para el volumen estimado de actividad que se necesite y Pruebas Funcionales que permitan
establecer si cubre los escenarios de negocio que se hayan planteado como requisitos del proyecto de
laboratorio.
Pg. 20 de 29
Las Pruebas de Rendimiento en Proyectos de Laboratorio se deben orientar en minimizar el impacto del
primer proyecto en produccin, esta se considera una prueba parcial ya que el entorno donde se ejecuta la
prueba no est en las mismas condiciones que el futuro entorno productivo, sin embargo esta prueba debe
ser lo ms completa posible.
Si la actividad a realizar permite su reutilizacin en el proyecto de implantacin, la documentacin de las
pruebas debe ser registrada. Sin embargo, en la mayora de los casos, no es necesario documentar la
definicin de Pruebas.
En el desarrollo del captulo se comentan las actividades diferenciales propias de la actividad de Pruebas en
Proyectos de Laboratorio.
4.1.
PLANIFICACIN
El documento del Plan de Pruebas es de carcter obligatorio para todos los proyectos de Laboratorio de tipo
Piloto, en el caso en que haya Cliente, normalmente la Cuenta es responsable de atender al Negocio
objetivo para este proyecto, este documento debe ser aceptado formalmente. En otro caso, no es necesaria
su aprobacin.
Definicin de los Escenarios de Pruebas que han sido elegidos por la Cuenta como Criterios de
Aceptacin del Laboratorio.
Preparacin del entorno de pruebas a utilizar para que las pruebas sean fiables y que su
configuracin sea lo ms cercana posible al futuro entorno de Produccin.
en el Proyecto.
Herramientas: Preparacin del Entorno de Trabajo

En el caso en el que sea necesario realizar la preparacin del entorno de trabajo en la Herramienta Quality
Center (QC). Este proyecto se realizar en un proyecto independiente de QC destinado nicamente para
este cometido.
El modelo de trabajo en la herramienta es igual al de un proyecto de Desarrollo.
4.2.
ESPECIFICACIN
Dentro de un Proyecto de Laboratorio se tiene una versin preliminar de requisitos, ya que en muchas
ocasiones se produce una experimentacin del nuevo software que permite aclarar las propias necesidades
del cliente, dependiendo de las posibilidades que permita la herramienta que se despliegue.
Por este motivo, el punto de partida deben ser estos requisitos preliminares, los cuales debern ser
probados mediante la definicin de casos de prueba y escenarios de prueba.
Pg. 21 de 29
Deben de contemplarse especialmente Requisitos no Funcionales que deba de cumplir la nueva plataforma,
tales como rendimiento y seguridad.
La carga de requisitos, en este caso, podr realizarse manualmente, ya que no es necesario que estos
requisitos existan en EA.
La organizacin de los mismos ser libre y no tiene por qu estar organizada por aplicaciones. En cualquier
caso, debern de utilizarse segn criterios operativos.
La estructura en Test Plan de los Casos de Prueba se aconseja que sea similar a la estructura de
Requisitos que se haya contemplado, para facilitar su bsqueda y trazabilidad.
Todo caso de Prueba debe estar trazado con al menos un Requisito. Una correcta priorizacin de los casos
de prueba permitir la optimizacin de la ejecucin de los mismos, ya que, en casos de falta de tiempo, se
podr recortar la ejecucin de los casos de prueba menos prioritarios.
Se deben de definir los escenarios de prueba que han de ser probados y especialmente aquellos que
pudieran invalidar el uso posterior de la plataforma.
4.3.
EJECUCIN
La ejecucin de las pruebas no tiene diferencia alguna con la de cualquier proyecto de Desarrollo, si bien
hay que tener en cuenta que las pruebas de aceptacin sern realizadas por la Cuenta, en el caso en que
esta sea el Cliente del proyecto. Con ello, se dara paso a la viabilidad de la realizacin de un proyecto de
implantacin sobre la nueva plataforma tecnolgica.
4.4.
Deber de plantearse si cualquier documentacin que se haya generado de la actividad de Pruebas durante
la ejecucin del proyecto de Laboratorio, pudiera ser usada en beneficio del primer proyecto de implantacin
y, por tanto, utilizar los casos de prueba y escenarios de prueba definidos en dicho proyecto.
4.5.
5.
PROYECTOS DE INFRAESTRUCTURA
Pg. 22 de 29
Se consideran Proyectos de Infraestructura a aquellos proyectos en los que se realiza la instalacin de

algn componente Hardware y/o Software, que no implique actividad alguna de Desarrollo de Software. En
otro caso, se considera parte de un proyecto de Desarrollo, ya que este tipo de proyectos tiene una serie de
actividades ms completa, incluyendo las actividades de un proyecto puro de Infraestructura.
Hay distintos tipos de proyectos de infraestructura, dependiendo de las actividades a realizar dentro del
mismo. Con respecto a la actividad de pruebas, se distinguen los proyectos dependiendo de las reas de
inters que han de participar en el proyecto.
Proyectos en los que interviene principalmente Infraestructura y/o que tienen muy baja afectacin al negocio
y a la infraestructura existente. En este caso, al tener un impacto limitado en el Negocio, la actividad de
Pruebas queda completamente reflejada en lo descrito en el captulo de Proyectos de Desarrollo y, por
tanto, no es necesario registrar la actividad de pruebas.
Proyectos en los que est directamente afectado el Negocio y, por tanto, tienen participacin de la Cuenta.
El registro de las pruebas integradas y de aceptacin se realizar en el caso en que sea previamente
acordado por Cuenta e Infraestructura antes de su puesta en Produccin. Este registro se realizar sobre la
herramienta QC en un proyecto independiente creado a tal efecto.
Deben de considerarse de manera especial aquellos proyectos que conllevan la implantacin de un mismo
producto en distintas sedes (Roll-Out) y, por tanto, hay que realizar siempre las mismas pruebas, lo cual
contiene un alto grado de reutilizacin y, por este motivo, es recomendable que se tenga un proyecto de
ejecucin de pruebas sobre QC reutilizable para todas las implantaciones, ya que es una tarea repetitiva.
En el desarrollo del captulo se comentan las actividades diferenciales propias de la actividad de Pruebas en
los Proyectos de Infraestructura.
5.1.
PLANIFICACIN
El documento del Plan de Pruebas es de carcter obligatorio en aquellos proyectos en los que el Cliente sea
el Negocio y/o la Cuenta, este documento debe ser aceptado por el Cliente del proyecto. En el caso de
proyectos de perfil muy tcnico el Negocio puede delegar la aceptacin del Plan de Pruebas en la Cuenta.
Definicin de los Escenarios de Pruebas que han sido elegidos por el Negocio como Criterios de
Aceptacin.
Preparacin del entorno de pruebas a utilizar para que las pruebas sean fiables y que su
configuracin sea lo ms cercana posible al futuro entorno de Produccin.
en el Proyecto.
Herramientas: Preparacin del Entorno de Trabajo
Pg. 23 de 29
En el caso en que se acuerde como necesario el registro de pruebas para el proyecto de infraestructura,
ser necesario realizar la preparacin del entorno de trabajo en la Herramienta Quality Center (QC). Este
proyecto se realizar en un proyecto independiente de QC destinado nicamente para este cometido.
El modelo de trabajo en la herramienta es igual al de un proyecto de Desarrollo.
5.2.
ESPECIFICACIN
Se debern realizar las Pruebas de Infraestructura necesarias para comprobar los nuevos componentes de
arquitectura implementados por el equipo de P&I siendo de carcter tcnico, no es obligatorio el registro de
estas pruebas.
La carga de requisitos, en este caso, podr realizarse manualmente, ya que no es necesario que estos
requisitos existan en EA.
La organizacin de los mismos ser libre y no tiene por qu estar organizada por aplicaciones. En cualquier
caso, debern de utilizarse segn criterios operativos.
La estructura en Test Plan de los Casos de Prueba se aconseja que sea similar a la estructura de
Requisitos que se haya contemplado, para facilitar su bsqueda y trazabilidad.
Todo caso de Prueba debe estar trazado con al menos un Requisito. Una correcta priorizacin de los casos
de prueba permitir la optimizacin de la ejecucin de las mismas, ya que, en casos de falta de tiempo, se
podr recortar la ejecucin de los casos de prueba menos prioritarios.
Se deben de definir los escenarios de prueba que han de ser probados, estos escenarios normalmente
estarn definidos en las reas de pruebas para el Mantenimiento de Aplicaciones y deben ser copiados al
proyecto con el objeto de ser utilizados.
5.3.
EJECUCIN
La ejecucin de las pruebas no tiene diferencia alguna con la de cualquier proyecto de Desarrollo.
La responsabilidad de la ejecucin de las pruebas unitarias es de Produccin e Infraestructuras no es
obligatorio registrarlas en QC, las pruebas integradas tambin las realiza P&I, debiendo ser registradas
siempre y cuando lo as lo acuerden Cuenta y P&I y las pruebas de aceptacin el Negocio / Cuenta deben
ser registradas segn se acuerde entre Cuenta y P&I.
Pg. 24 de 29
5.4.
En el caso de que los casos de prueba y escenarios de prueba pudieran ser usados en otros proyectos de
Infraestructura futuros, estas deberan de ser consolidadas en un proyecto modelo para ser reutilizado
posteriormente. Por ejemplo, Roll-out de infraestructura similar en Pases.
5.5.
6.
OTRAS ACTIVIDADES
6.1.
PRUEBAS DE RENDIMIENTO
Las Pruebas de Rendimiento se ejecutarn segn el tipo de proyecto y/o aplicacin afectada.
Para implantacin de Nuevas Tecnologas deben de realizarse de manera obligatoria. En Proyectos de
Laboratorio se deben de realizar dichas pruebas para minimizar el impacto del primer proyecto en
produccin, se considera una prueba parcial ya que el entorno donde se ejecuta la prueba no est en las
mismas condiciones que el futuro entorno productivo, sin embargo, esta prueba debe ser lo ms completa
posible.
As mismo, siempre que un proyecto necesite de la instalacin de un nuevo Hardware y/o la implantacin de
Software en Produccin pudiera tener impacto en el rendimiento de la plataforma existente debern de
realizarse de manera obligatoria Pruebas de Rendimiento.
Se deber de identificar, la necesidad de realizar Pruebas de Rendimiento en la Definicin de Requisitos del
proyecto de forma especfica, o en su defecto, por Arquitectura a travs del Convenio.
Para Tecnologa Business Intelligence es obligatorio realizar Pruebas de Rendimiento, si bien para la
realizacin de estas pruebas no es necesario utilizar la herramienta LoadRunner, bastar con una toma de
tiempos de ejecucin, tal y como se determina en la plantilla existente para su cumplimentacin.
Herramientas:
La herramienta para realizar pruebas de Rendimiento es HP-LoadRunner (LR).
6.1.1
PLANIFICACIN
Para el uso de LR se debe planificar la actividad con suficiente antelacin, lo cual debe reflejarse en el
documento de planificacin de pruebas del proyecto.
Deben tenerse en cuenta los siguientes aspectos:
Existencia de un tester experto en Pruebas de Rendimiento con experiencia en LR. Es muy

importante saber interpretar los resultados de las pruebas.
Pg. 25 de 29
6.1.2
Generalmente son pruebas End to End, por lo que es importante la coordinacin con las reas de
Infraestructura para asegurar los accesos necesarios.
Reserva del periodo de ejecucin de trabajo sobre la plataforma LR para la ejecucin del modelo al
administrador del Sistema, ya que solo puede haber un proyecto en ejecucin cada vez
Definicin de los objetivos de la prueba de rendimiento. Por ejemplo: comparacin de tiempos entre
dos plataformas, verificar el nivel de concurrencia de uso en produccin, etc.
Definicin de los escenarios de prueba que debern ejecutarse en la prueba
ESPECIFICACIN
En esta fase se deben de definir de forma detallada el escenario de pruebas a realizar y la orquestacin
combinada de los mismos que debern ser ejecutados por el sistema.
Se ejecutarn los distintos escenarios de prueba por separado con la herramienta de LR Vugen que permite
registrar los scripts de trabajo en los que se basa la herramienta, y estableciendo las modificaciones
necesarias a los scripts para establecer rupturas de tomas de tiempo, incorporacin de bateras de datos de
pruebas, etc.
Debern de preverse usuarios de ejecucin de las pruebas y los distintos permisos que deban de
acreditarse para poder realizar la ejecucin de la prueba.
6.1.3
EJECUCIN
Para realizar la ejecucin de pruebas en LR se utiliza la plataforma centralizada dedicada en exclusivo para
una determinada ejecucin ya que se dispone nicamente de una licencia de ejecucin. Si bien se pueden
simular hasta un mximo de 250 usuarios concurrentes.
Una vez realizadas las distintas ejecuciones, mediante el mdulo de anlisis se analiza la informacin
obtenida y se podrn realizar nuevas ejecuciones para profundizar en el problema existente hasta emitir el
informe de conclusiones.
6.2.
PRUEBAS DE SEGURIDAD
Las pruebas de Seguridad pueden ser de dos tipos:

Seguridad interna es la que permite que un usuario de la organizacin con permiso de acceso a la
aplicacin acceda nicamente a las partes de la aplicacin para las que se le ha autorizado. La verificacin
de la seguridad interna se realiza mediante la ejecucin de casos de prueba especficos de acceso con
distintos usuarios y verificando los accesos que tiene disponibles dentro de la aplicacin examinada. Estas
pruebas son registradas en QC en el apartado de Pruebas de Seguridad. Se recomienda automatizar este
tipo de pruebas, pues permite reiterarse la prueba tantas veces como se necesite y se garantiza que el
acceso a las aplicaciones es el que est previsto.
Seguridad externa es la que establece que solo los usuarios autorizados sean los que accedan a una
determinada aplicacin, sus datos o cualquier informacin incluida en la misma. Es decir, no hay usuarios
de la organizacin que accedan a una aplicacin a la que no estn autorizados, ni hay usuarios ajenos a la
Pg. 26 de 29
organizacin que puedan entrar en la misma (hackers). La verificacin de la seguridad externa se realiza
verificando que un usuario que no est autorizado no puede acceder a la aplicacin. Tambin son de
aplicacin en este caso software de terceros que realizan el anlisis de cdigo y que establece si este
cdigo puede ser violado por algn usuario externo, inyeccin de cdigo, etc., tpico de tecnologas Web y
en especial para aplicaciones con visibilidad al exterior.
Todas las aplicaciones que se utilicen en el portal deben ser revisadas en este sentido para garantizar la
inviolabilidad de los datos de la corporacin.
6.3.
PARADAS Y/O REARRANQUES DEL SISTEMA
Esta actividad es realizada de forma peridica cuando se realiza la simulacin del Plan de Recuperacin
ante Desastres (PRD), o bien, Paradas Planificadas Mensuales donde se aprovecha para la realizacin de
cambios de infraestructura / software que requieran que el sistema est fuera de lnea.
Para la realizacin de esta actividad las pruebas que deben ejecutarse son un conjunto restringido de las
pruebas, que estn catalogadas como Pruebas de Regresin en cada una de las aplicaciones donde sea de
aplicacin el PRD.
Los escenarios de pruebas a ejecutar son elegidos previamente a esta actividad y debern de estar
incluidos en un apartado especial de la herramienta (PRD) dentro del Catlogo de Escenarios. La carpeta
PRD estar subdividida por Procesos de Negocio o Servicios con el objeto de localizar rpidamente
aquellas ejecuciones necesarias para cada caso concreto, pues lo normal es que las Paradas no afecten a
la totalidad de los Servicios que se le proporcionan al Cliente.
Adicionalmente a esto, se tendr un proyecto PRD donde se consolidarn los escenarios de todas las reas
de mantenimiento al inicio del mismo y donde se ejecutarn las pruebas correspondientes.
Se recomienda que las aplicaciones que sean crticas para el funcionamiento del Negocio tengan una
monitorizacin automtica, la cual se realiza mediante herramientas (HP BAC), para que pueda ser
comprobado su funcionamiento de forma automtica, optimizando el nmero de pruebas a realizar.
6.4.
DISPONIBILIDAD DEL ENTORNO DE PRUEBAS Y JUEGOS DE DATOS
Uno de los aspectos que suelen ser crticos en la actividad de pruebas es la disponibilidad del entorno y su
similitud con el entorno productivo.
En lo relativo a disponibilidad, se debe de asegurar, en la medida de lo posible, su aislamiento con respecto
al entorno de desarrollo, pues la actividad de desarrollo puede influir de manera negativa en la actividad de
pruebas, generando falsos negativos o falsos positivos ante la ejecucin de las pruebas.
La similitud con el entorno productivo debe ser una caracterstica que debe ser evaluada. Si bien,
normalmente es imposible tener un entorno clonado con respecto al de produccin, por el coste que ello
supone. Se debe de tener una configuracin, en cuanto a software de base instalado y su parametrizacin ,
que permitan asegurar la fiabilidad de las pruebas que se realizan en dicho entorno.
Pg. 27 de 29
Un cambio en la configuracin de un servidor desde integracin a produccin, puede producir un fallo en el

uso de la aplicacin por parte del negocio que imposibilite su uso y es muy complicado y costoso encontrar
y resolver el fallo en cuestin. Para ello, se recomienda del uso de herramientas que permitan agilizar la
comparacin entre entornos.
Por otro lado, la existencia de un juego de datos de buena calidad para la realizacin de pruebas es crtico
para que las pruebas realizadas sean lo ms fiable posibles.
Como se ha indicado anteriormente, en la fase de planificacin es donde se debe de prever la existencia de
un juego de datos en el entorno de integracin lo ms prximo al entorno productivo.
Una de las prcticas ms extendidas es la de realizar una copia de los datos del entorno productivo al
entorno de integracin. Sin embargo, esta situacin pone en peligro la confidencialidad de los datos
utilizados y, en el caso, de que los datos deban cumplir la LOPD, esta se vera incumplida en el caso de que
hubiera accesos no autorizados expresamente por los usuarios propietarios de la informacin.
Por este motivo, una vez realizada esta copia, los datos sensibles a la confidencialidad (Nombre, Nif,
domicilio, etc.) que permitan conocer la identidad de la persona o persona jurdica debern ser encriptados
para su uso en la actividad de pruebas.
La realizacin de esta actividad es costosa y, por ello, deberan de realizarse procesos lo ms automatizado
posible, considerar el uso de herramientas para permitir automatizar esta actividad, ya que la realizacin de
la actividad de pruebas normalmente suele alterar los datos, de manera que, los hace inservibles para
volver a realizar las pruebas y, a menudo, es necesario volver a recargar el entorno de pruebas.
6.5.
AUTOMATIZACIN DE PRUEBAS
Una de las mejores prcticas recomendables en la actividad de pruebas es la automatizacin de las

mismas.
Para abordar una actividad de automatizacin de pruebas debe de tenerse en cuenta que esta actividad
tiene un coste adicional a la ejecucin manual, con lo que se debe de asegurar su rentabilidad a largo plazo.
Se estima que la automatizacin de casos de prueba es rentable en el caso de que un caso de prueba
pueda ser ejecutado reiteradamente al menos 4 veces.
Aparte de los criterios de rentabilidad descritos, para automatizar casos de prueba debe de tenerse en
cuenta que el caso de prueba debe ser estable, ya que cualquier cambio en la pantalla de introduccin de
datos derivar en que la automatizacin deba de construirse nuevamente.
Por estos motivos, los casos de prueba candidatos a su automatizacin deben ser casos de prueba
planificados en las pruebas de regresin de cada aplicacin y, en la medida de lo posible, ser estables en el
tiempo ante su uso.
Esta actividad permitir que ante la implantacin de nuevos elementos funcionales en una aplicacin dada,
la ejecucin de las pruebas de regresin, si son de manera automatizada, se realicen de una forma muy
rpida y eficiente.
Pg. 28 de 29
Herramienta:
La automatizacin de casos de prueba se realiza mediante la herramienta de HP QTPro la cual est
integrada con QC. Esta herramienta permite realizar scripts de ejecucin que luego deben ser adaptados
por el desarrollador para permitir la ejecucin automatizada y sincronizada de un determinado escenario de
pruebas.
Se debe tener especial cuidado en los juegos de datos que deban de alimentar la prueba, pues es habitual
que dichos datos se vayan quemando tras su ejecucin. Por este motivo, se debe de procurar que el
entorno de integracin pueda volver a usarse con los mismos datos una y otra vez, lo que permitir una
correcta automatizacin de las pruebas sin necesidad de una asistencia continua.
Pg. 29 de 29

Guia de Metodologia de Pruebas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia de Metodologia de Pruebas

Enviado por

Direitos autorais:

Formatos disponíveis

GUA METODOLOGA DE PRUEBAS

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

2.3. EJECUCIN .................................................................................................................................. 8

CIERRE DE LA ACTIVIDAD ........................................................................................................ 12

2.6. SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 14

3. ACTIVIDAD DE MANTENIMIENTO DE APLICACIONES .................................................... 15

3.3. EJECUCIN ................................................................................................................................ 16

CIERRE DE LA ACTIVIDAD ........................................................................................................ 19

3.5. SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 19

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

CIERRE DE LA ACTIVIDAD ........................................................................................................ 22

SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 22

5. PROYECTOS DE INFRAESTRUCTURA ............................................................................ 22

CIERRE DE LA ACTIVIDAD ........................................................................................................ 25

SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS ...................................................................... 25

6. OTRAS ACTIVIDADES ...................................................................................................... 25

PRUEBAS DE SEGURIDAD ........................................................................................................ 26

PARADAS Y/O REARRANQUES DEL SISTEMA ......................................................................... 27

DISPONIBILIDAD DEL ENTORNO DE PRUEBAS Y JUEGOS DE DATOS.................................. 27

Direccin de Sistemas de Informacin

Descripcin del cambio

Gua de Metodologa de Pruebas v1.1.doc

Herramientas: Preparacin del Entorno de Trabajo Definicin del Proyecto

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Definicin de Casos de Prueba

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Definicin de Escenarios de Prueba

A cada escenario de prueba se le puede asignar la siguiente informacin:

Regresin. Identifica al escenario de prueba como candidato para su ejecucin en la actividad de

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

PRUEBAS UNITARIAS BSICAS

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

En la finalizacin del proyecto se debe de realizar la actividad de traspaso a Mantenimiento de aquellos

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

SEGUIMIENTO DE LA ACTIVIDAD DE PRUEBAS

Para realizar el seguimiento de la actividad de pruebas se dispone de las mtricas definidas en la

INFORME DE AVANCE DE EJECUCIN DE PRUEBAS

Avance en Ejecucin de Pruebas

INFORME DE SEGUIMIENTO DE DEFECTOS

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

ACTIVIDAD DE MANTENIMIENTO DE APLICACIONES

No es obligatoria la realizacin de un documento de Planificacin de Pruebas, ya que la infraestructura

Direccin de Sistemas de Informacin

Gua de Metodologa de Pruebas v1.1.doc

como consecuencia de un mantenimiento evolutivo. En el caso de mantenimiento correctivo suele ser