Guia_de_Metodologia_de_Pruebas

Direccin de Sistemas de Informacin Gua de Metodologa de Pruebas v1.1.doc Pg. 1 de 29

GUA METODOLOGA DE PRUEBAS

Versin: v1.1

Autor: ODP-CALIDAD de Metodologa


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.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




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

5.1. PLANIFICACIN ......................................................................................................................... 23

5.2. ESPECIFICACIN ....................................................................................................................... 24

5.3. EJECUCIN ................................................................................................................................ 24



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 Responsable Fecha Descripcin del cambio

V1.0 JRA 25/11/11 Creacin del Documento

V1.1 CdM 19/04/2012 Informacin adicional para los escenarios de prueba.


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:

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

2. 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


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


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.


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


catlogo de escenarios, as como, en un futuro abordar la actividad de automatizar todos los casos

de prueba que lo componen.

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.

2.3. 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:


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


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.


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.


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.


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.


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

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.

Avance en Ejecucin de Pruebas


t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15

Abiertas 3 5 8 5 3 8 9 6 5 3 2 0

Acum. Abiertas 3 8 16 21 24 32 41 47 52 55 57 57

Cerradas 1 2 3 3 4 3 3 3 3 4 5 7

Acum. Cerradas 1 3 6 9 13 16 19 22 25 29 34 41

0

10

20

30

40

50

60N

In

cid

en

cias

Defectos Abiertos vs Cerrados

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

Acumulado Apertura Vs Cierre de Defectos


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


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.


3.3.1 PRUEBAS UNITARIAS BSICAS


3.3.2 PRUEBAS UNITARIAS

No hay diferencia con la actividad en Proyectos de Desarrollo. 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




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.


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 Nivel Prueba

Usuario Clave Peticin EstadoEscenarioPruebas Cuenta Pruebas Usuario Total general

CONSTRUCCION

INSTALACIONES 252486 - Editar importes pedido CRG obras MUN act AVN,PPP,AVE Fin OK 2 2 4

252487 - Gestin de errores en contabilizacin de certificaciones Fin OK 6 6

En Curso 1 1

Pendiente 5 5

252488 - N de actuacin/oferta en las certificaciones de obra de GEOSFin OK 2 2

Pendiente 2 2

252489 - Gestin de certificacin de supervisin en granel Fin OK 2 2

Pendiente 2 2

261464 - Correccin de errores en la creacin de solicitudes de equiposFin OK 2 2

Pendiente 3 3

253742 - Perfil de fabricante de equipos en BP5 Fin OK 1 1

En Curso 1 1

262657 - ZB_PM_LUGARES Fin OK 1 1

Pendiente 1 1

252490 - Fecha de Alta / Baja en la seleccin de interlocutores Fin OK 4 4

En Curso 2 2

Pendiente 3 3

Revisar 1 1

257763 - Modificacin de la longitud del nmero de orden de las acometidas en el libro de tubosFin OK 4 4

Pendiente 4 4

253744 - Informe de autofctura. Fin OK 1 1

Pendiente 1 1

255478 - Identificacin de contratos fuera de periodo de vigencia Fin OK 3 3

Pendiente 3 3

272779 - Correctivo problema en certificaciones OT Fin OK 1 1 2

267123 - Segunda Inspeccin para Granel en GEOS Fin OK 1 1

Pendiente 1 1

Total CONSTRUCCION INSTALACIONES 32 31 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


Defectos ESTADO

Usuario Clave Peticin Nivel Prueba CRITICIDAD Hallado Asignado Corregido Rechazado Cerrado Total

CONSTRUCCION

INSTALACIONES

252486 - Editar importes pedido CRG

obras MUN act AVN,PPP,AVE

Pruebas Usuario 3. Media 1 1

2. Alta 1 1

252490 - Fecha de Alta / Baja en la

seleccin de interlocutores


Total CONSTRUCCION INSTALACIONES 1 2 3

MANTENIMIENTO

INSTALACIONES DE

CLIENTES

253465 - Visualizacin mdulos

contrato de granel


260992 - CGLP-SRG: Visualizacin

de los pedidos de TLM-TLG en la

pantalla de SRG:Datos Instalaciones

Pruebas Usuario 4. Baja 1 1

258252 - CGLP-BP5: Programa carga

masiva pedidos de gas de


267416 - Volcado masivo de ssdd de

sustitucin de contador

Pruebas Cuenta 3. Media 1 1

2. Alta 1 1

Total MANTENIMIENTO INSTALACIONES DE CLIENTES 3 2 5

MANTENIMIENTO Y

ASISTENCIA TECNICA

257762 - Adaptacin pantallas

solicitud de revisin


257759 - Adaptacin pantallas revisin Pruebas Usuario 3. Media 1 1 2

Total MANTENIMIENTO Y ASISTENCIA TECNICA 2 1 3

PRODUCTO

ENVASADO

256871 - Rectificacin ticket

suministro PPVV


Total PRODUCTO ENVASADO 1 1

Total 5 1 6 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.


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.


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.





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.



5. PROYECTOS DE INFRAESTRUCTURA


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


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.






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.



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.


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

6.1.2 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


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.


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.


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.

Guia_de_Metodologia_de_Pruebas

Documents

Transcript of Guia_de_Metodologia_de_Pruebas