Metodologia de Pruebas V2

Direccin de Sistemas de Informacin Metodologa de Pruebas v2.1.doc Pg. 1 de 18

METODOLOGIA DE PRUEBAS Actualizacin: 2.1 Autor: OdP Calidad de Metodologa


Contenido

1. OBJETIVOS Y ALCANCE .................................................................................................... 3

2. METODOLOGA DE PRUEBAS ........................................................................................... 4

2.1. FASE DE PLANIFICACIN............................................................................................................ 5

2.2. FASE DE ESPECIFICACIN ......................................................................................................... 6

2.2.1 Atributos de la Definicion de Casos de Prueba ........................................................................ 7

2.2.2 Atributos de la Definicion de Escenarios de Prueba ................................................................. 8

FASE DE EJECUCIN............................................................................................................................. 9

2.2.3 Modelo de Ejecucin de Pruebas .......................................................................................... 10 2.2.4 Atributos del Registro de Ejecucion de Pruebas .................................................................... 11

2.2.5 Atributos del Registro de Incidencias de Pruebas .................................................................. 11

3. CLASIFICACION DE LAS PRUEBAS ................................................................................ 14

3.1. ACTIVIDADES DE PRUEBAS...................................................................................................... 14

3.2. TIPOS DE PRUEBAS .................................................................................................................. 15

4. TRAZABILIDAD ................................................................................................................. 16

5. ANEXO .............................................................................................................................. 16

5.1. MTRICAS DURANTE CICLO DE PRUEBAS ............................................................................. 16

5.2. GLOSARIO .................................................................................................................................. 17

Versin Responsable Fecha Descripcin del cambio 1.0 CCA Primera versin del documento

1.1 EFS 31/Oct/07 Apartado de Mtricas.

1.2 CAC Marzo 2009 Actualizacion Puntos 2 y 4.1

1.3 CAC Julio 2009 Adaptacin MGD 3.3

2.0 CAC y JRA Noviembre 2011 Reformulacin Metodolgica (Taller Metodologa de Pruebas)

2.1 CdM 19/04/2012 Atributos en la definicin de escenarios de prueba.


1. OBJETIVOS Y ALCANCE

El objetivo del presente documento es establecer una metodologa para la realizacin de Pruebas en los

procesos de implementacin de Sistemas de Informacin (Proyectos y Mantenimiento), que pueda ser

tomada como referencia para la definicin y ejecucin de pruebas para los sistemas de Repsol.

Los procesos aqu descritos son independientes del uso de herramientas. Sin embargo, se mencionar su

uso dentro de la metodologa, pues la utilizacin de una herramienta de gestin de pruebas es altamente

recomendada.

Est ampliamente probado que la ejecucin de actividades estructuradas de pruebas es una de las mejores

prcticas de aseguramiento de la calidad y cuando se encuentra bien implementada puede significar un

importante ahorro en costes ligados a la implementacin de Sistemas de Informacin.


2. METODOLOGA DE PRUEBAS

La Metodologa de Pruebas est integrada dentro de la Metodologa General de Desarrollo y est definida

como parte independiente de esta, para establecer una mayor claridad en los procedimientos que se

describen a continuacin. Si bien, debe de tenerse en cuenta en todo momento su integracin.

La Metodologa de Pruebas, se basa principalmente en el concepto de caja negra, es decir, el elemento es

estudiado desde el punto de vista de las entradas que recibe y las salidas que produce, sin tener en cuenta

el funcionamiento interno. Se centran en probar funcionalidad.

El ciclo de vida, en la Metodologa de Pruebas tiene tres fases:

Planificacin, Especificacin y Ejecucin.

En la Planificacin, se establece la estrategia a seguir para llevar a cabo la ejecucin de las pruebas. En la

fase de Especificacin, se disean las pruebas y finalmente, en la fase de Ejecucin, se ejecutan las

pruebas.

Las Fases de la Metodologa de Pruebas se integran en la Metodologa General de Desarrollo (MGD) de la

siguiente forma:

A continuacin, se describen las fases:


2.1. FASE DE PLANIFICACIN

Objetivo: Formular una estrategia de cmo se realizaran las pruebas. Esta actividad sirve para informar al

Cliente las actividades y tipos de pruebas a realizar durante el proceso de las pruebas y para acordar cules

son los Escenarios de Negocio que se habrn de considerar en las Pruebas de Aceptacin como

imprescindibles para aprobar la Puesta en Produccin del Sistema.

En esta fase se realizan las tareas relacionadas con el comienzo de la actividad, encuadrndose en la Fase

de Anlisis Funcional de la MGD.

Las actividades de esta fase son las siguientes:

Definicin de las actividades y tipos de pruebas a realizar

Establecer el entorno de trabajo donde se realizarn las pruebas y los juegos de datos necesarios

para la realizacin de las mismas

Acordar el Modelo de Gestin de la actividad de Pruebas, Uso de Herramientas, etc. Se determinar

el modo de registrar las pruebas, el levantamiento de incidencias y el modelo de trabajo para

resolver las mismas

Descripcin y Priorizacin de los Escenarios de Negocio para las Pruebas de Aceptacin

Planificacin de necesidades para realizar las pruebas de aceptacin

Definicin de los Criterios de aceptacin del Sistema y finalizacin de la Prueba

Se deben de tener en cuenta la posibilidad ideal de tener un entorno de prueba independiente, de manera

que no se vea afectado por las labores habituales de desarrollo con el fin de preservar la fiabilidad de la

prueba. Esto es especialmente indicado en la realizacin de las Pruebas de Aceptacin del Usuario.

Por otro lado, puede ser til confeccionar un conjunto de datos de prueba genrico que sirva como punto de

partida en las distintas actividades de pruebas (ya sea generndolos manualmente o importando un

subconjunto de datos de produccin).

Es importante la definicin del Criterio de Aceptacin del Sistema, de tal modo que no existan incidencias

con criticidad Invalidante, Alta o Media pendientes de correccin, una vez que hayan sido ejecutados

aquellos Escenarios de Prueba acordados con el Negocio para obtener la aceptacin del Sistema.

Esta actividad se soporta con la descripcin de un Plan de Pruebas. Este documento debe ser aprobado

por el Cliente y es la base de la Aceptacin del Sistema.


2.2. FASE DE ESPECIFICACIN

Objetivo: Las pruebas requeridas deben estar especificadas. Se trata de hacer los trabajos preparatorios

para la ejecucin de las pruebas, lo que incluye la definicin de las mismas, la preparacin de los juegos de

datos y asegurar que el sistema y los entornos estn disponibles para la realizacin de la actividad

planificada.

En esta fase se realizan las tareas relacionadas con la preparacin de la ejecucin, encuadrndose en la

Fase de Diseo Tcnico de la MGD.


Definir los casos de prueba a realizar con sus resultados esperados

Detallar los escenarios de prueba que dirigirn la ejecucin de los casos de prueba

Establecer prioridades para los casos de prueba

Preparar y validar los datos de prueba a ser usados por los casos de prueba

Preparar y verificar que el entorno de pruebas est en condiciones para la ejecucin de pruebas

A partir de la elaboracin de la estrategia, se comienza con la definicin de los casos de prueba. Se

recomienda el uso de alguna herramienta para especificar los casos de prueba. En esta etapa se generan

conjuntos de casos de prueba clasificados por prioridad para cada funcionalidad.

La definicin de casos de prueba constituye el primer paso a la hora de realizar las pruebas de un sistema.

Es recomendable realizar la definicin de casos de prueba, para todo el sistema, al comienzo para luego

dedicarse a la ejecucin (el conocimiento adquirido ser mayor), en determinadas situaciones, este

esquema puede no ser practicable. Por ejemplo debido a que ciertos requerimientos del sistema no estn

disponibles todava al momento de definir casos de prueba. En este tipo de situaciones, un esquema

alternativo es realizar la definicin seguida de la ejecucin para los requerimientos disponibles solamente.

La cantidad de informacin disponible como entrada para esta actividad vara mucho de acuerdo al

Proyecto. En general los casos de prueba se derivan de las siguientes fuentes:

Documentacin general del sistema u objeto a probar

Documento de especificacin funcional (EDRF)

Modelo de datos del sistema

Prototipo o pantallas del sistema

Una vez escritos los casos de prueba y el resultado esperado, es importante validarlos. El objetivo es

reducir al mximo la brecha existente entre lo implementado y lo requerido o especificado. Es importante

validar tanto la completitud en la definicin como la especificacin del resultado esperado de cada uno, as

como tambin la prioridad de ejecucin asignada.

Todos los Requisitos del Sistema deben estar cubiertos al menos con un Caso de Prueba y en el caso de

ser descritos como Casos de Uso, deber de tener al menos tantos casos de Prueba como Flujos contenga

(Normal y Alternativos).


Esta actividad se soporta mediante el documento de Definicin de Pruebas, si bien se identificarn dos

formatos dependiendo de la naturaleza de la prueba: Las Pruebas Funcionales se debern de trazar con

los Casos de Uso de la aplicacin y se describen los pasos para la definicin de la Prueba. El Resto de

Pruebas sern meramente descriptivas para facilitar su definicin. (Ver Captulo Clasificacin de Pruebas

para ver los distintos Tipos de Prueba que se han contemplado y su definicin). Este documento tambin

servir para realizar la carga automtica inicial de la Definicin de Pruebas en la herramienta de Gestin.

Una vez definidos los casos de prueba, debern de definirse los escenarios de prueba, tanto los que se han

previsto en el Plan de Pruebas para la aceptacin del sistema, como aquellos adicionales que se considere

oportuno crear.

Los Escenarios de Prueba deben de detallarse mediante la composicin de los distintos casos de prueba,

de manera que permitan ejecutar un Proceso de Negocio completo o una parte del mismo. Normalmente los

escenarios de prueba contienen casos de prueba que pueden ser de distintas aplicaciones, ya que permiten

validar la integracin del Sistema construido dentro del mbito funcional existente.

Con el objeto de asegurar un correcto mantenimiento futuro del sistema, se debe de identificar si el

Escenario de Prueba pasar a Mantenimiento y si este deber ser ejecutado en la actividad de Pruebas de

Regresin. Esta actividad debe ser verificada nicamente al final del proyecto.

2.2.1 ATRIBUTOS DE LA DEFINICION DE CASOS DE PRUEBA

Prioridad de Casos de Prueba

A continuacin se dan las reglas bsicas para la priorizacin de los Casos de Prueba:

Prioridad

Caso de

Prueba

Descripcin

Alta

Funcionalidades bsicas que permiten probar rpidamente y a lo ancho el sistema. Estos casos permiten detectar tempranamente funcionalidades bsicas no implementadas o que no funcionan (ej: no se puede ingresar a una pantalla, al presionar el botn de alta se produce un error, etc.) No se incluyen en esta categora casos negativos o de pruebas de seguridad, ya que no deberan superar el 20% de los casos definidos.

Media

Estos casos permiten probar con mayor profundidad las funcionalidades ms crticas del sistema. Se plantean distintas variaciones y situaciones incluyendo las principales pruebas de seguridad. Se corresponden con situaciones cuya probabilidad de ocurrencia es alta o media. Se incluyen en esta categora todos los casos cuya ejecucin no puede ser pospuesta hasta la puesta en produccin. La falla de estos casos generara incidentes que impediran el pasaje a produccin del sistema o de alguna de sus funcionalidades.

Baja

Dentro de esta categora se incluyen los casos cuya probabilidad de ocurrencia es baja y cuyo impacto en caso de falla no se supone invalidante para la aceptacin de una funcionalidad o su pasaje a produccin. Si bien la ejecucin de estos casos es importante para garantizar el correcto funcionamiento de la aplicacin, se podr posponer o suspender la ejecucin de los mismos en caso de tener que recortar el alcance de las pruebas previas a la fecha de una puesta en produccin. La clasificacin de estos casos tambin depender mucho del usuario final del sistema y de las opciones de contingencia en caso de fallar determinadas funcionalidades o situaciones particulares.


2.2.2 ATRIBUTOS DE LA DEFINICION DE ESCENARIOS DE PRUEBA

Prioridad de Escenarios de Prueba

A continuacin se dan las reglas bsicas para la priorizacin de los Escenarios de Prueba:

Prioridad

Escenario

de

Prueba

Descripcin

Alta

Identifica aquellos escenarios de prueba que deben finalizar satisfactoriamente para que el software pueda ser aceptado por el negocio. Es decir, deber acordarse e identificar entre negocio y cuenta aquellos escenarios que cumplen esta prioridad y establecer el porcentaje de ejecuciones correctas de los mismos para aceptar el software. Se recomienda para esta prioridad establecer el 100% de los mismos.

Media

Identifica aquellos escenarios de prueba que deben finalizar satisfactoriamente para que el software pueda ser aceptado por el negocio. Es decir, deber acordarse e identificar entre negocio y cuenta aquellos escenarios que cumplen esta prioridad y establecer el porcentaje de ejecuciones correctas de los mismos para aceptar el software. Se recomienda para esta prioridad establecer el 50% de los mismos.

Baja

Identifica aquellos escenarios de prueba que deben finalizar satisfactoriamente para que el software pueda ser aceptado por el negocio. Es decir, deber acordarse e identificar entre negocio y cuenta aquellos escenarios que cumplen esta prioridad y establecer el porcentaje de ejecuciones correctas de los mismos para aceptar el software. Se recomienda para esta prioridad establecer un porcentaje inferior al 50% de los mismos.

Regresin de Escenarios de Prueba

A continuacin se dan las reglas bsicas para los grupos funcionales de los Escenarios de Prueba:

Regresin

Escenario

de Prueba

Descripcin

No

Identifica al escenario de prueba como no reutilizable para la actividad de pruebas de regresin.

Si

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.


FASE DE EJECUCIN

Objetivo: Obtener la validacin de los requisitos que se prueban, por medio de las ejecuciones de

escenarios y/o casos de prueba que se han acordado.

En esta fase se realizan las tareas relacionadas con la ejecucin de las pruebas, encuadrndose en la Fase

de Construccin y Pruebas de la MGD.


Ejecutar los escenarios y/o casos de prueba y registrar sus resultados

Registrar las incidencias en el caso de que se producen fallos en las ejecuciones

Realizar el seguimiento de las incidencias hasta su resolucin

Realizar el seguimiento del progreso de las ejecuciones e informar del mismo

Establecer el cese de a actividad cuando se den las condiciones de aceptacin por el Cliente

Una vez definidos los escenarios y/ocasos de prueba, comienza la etapa de ejecucin de la prueba. En esta

etapa se realiza la ejecucin de todos los escenarios y/o casos de prueba definidos, se reportan los

problemas encontrados y se realiza el seguimiento de los problemas. No es necesario esperar a que el

producto est completamente desarrollado para comenzar con la ejecucin. Este puede iniciarse y continuar

a medida que se vayan liberando los diferentes mdulos del producto.

A lo largo de cada prueba o ciclo de ejecucin se irn actualizando los estados de ejecucin de los casos de

prueba, notificando los incidentes encontrados y actualizando los estados de las incidencias encontradas.

La modalidad y frecuencia de notificacin de los incidentes depender en gran medida del proyecto que se

est llevando a cabo y de lo acordado durante la planificacin o ejecucin del proyecto.

Una vez que se hayan cumplido los criterios de terminacin de las pruebas, se procede a concluir la

actividad de Pruebas y se realiza el Paso a Produccin del Sistema.

Esta actividad se soporta mediante los documentos Registro de Ejecucin de Pruebas y Registro de

Incidencias de Pruebas.

En el Registro de Ejecucin de Pruebas se deben de registrar de manera independiente la ejecucin de

las distintas actividades que deban ser observadas en todo el proceso. (Ver captulo Clasificacin de

Pruebas para ver las distintas Actividades de Prueba que se han contemplado y su definicin).

En el Registro de Incidencias de Pruebas se registrarn todas las incidencias que se produzcan a lo largo

de todo el proceso, independientemente de la actividad donde se hayan detectado.

El Registro de la ejecucin de las Pruebas en una herramienta y la identificacin del usuario que hace la

misma hace innecesario el registro de evidencias de la actividad de forma manual. El usuario responsable

debe de realizar la actividad para que quede registrado, si se hace delegacin en un tercero, esta

delegacin debe estar documentada. nicamente se requiere el correo de aceptacin del Usuario para el

paso a productivo de la aplicacin, siendo innecesario adjuntar las pruebas realizadas.


2.2.3 MODELO DE EJECUCIN DE PRUEBAS

Como regla general, la realizacin de las distintas actividades de Pruebas es obligatoria, siempre y cuando

sean de aplicacin. En la hoja Excel adjunta se puede ver de forma resumida el Modelo de Ejecucin de

Pruebas que se explica a continuacin:

Modelo de Ejecucin de Pruebas.xlsx

No es obligatorio realizar el registro de las pruebas cuando se realicen las Pruebas Unitarias Bsicas y en

Proyectos de Laboratorio.

La Actividad de Pruebas de Regresin no se registra de manera independiente, pues esta estar incluida

en el registro del resto de Actividades.

Siempre que haya implantacin de software, deben de realizarse Pruebas de Tipo Funcional orientadas a

validar la funcionalidad del sistema en las condiciones definidas por los Requisitos, tanto funcionales como

no funcionales.

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 el proyecto necesite de la instalacin de un nuevo Hardware en Produccin o, en el

caso en que la implantacin de Software pudiera tener impacto en la plataforma existente debern de

realizarse de manera obligatoria Pruebas de Rendimiento.

Se deber de identificar, la necesidad de realizar cualquier actividad de prueba que no est validada a

travs de una Prueba Funcional en la Definicin de Requisitos del proyecto de forma especfica, o en su

defecto, por Arquitectura a travs del Convenio. Normalmente esto se deber de especificar cuando haya

necesidad de realizar pruebas de Rendimiento, Seguridad externa, Portabilidad, y otras susceptibles de ser

identificadas de forma independiente.

En Pruebas de Infraestructura debe registrarse la actividad de Pruebas Integradas por parte de la Cuenta

y las Pruebas de Aceptacin por parte del Negocio. En este caso, normalmente son pruebas de tipo

funcional, si bien las hay tambin de carcter no funcional (EJ: prueba de conexin a la red).

El registro de las Pruebas Unitarias en Pruebas de Infraestructura ser obligatorio en caso de implantacin

de nuevos componentes de Hardware o Software de Base.


Para Tecnologa Business Intelligence se exige realizar Pruebas de Rendimiento con carcter obligatorio, 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.

Para la realizacin del PRD las pruebas que deben realizarse son las que estn catalogadas como Pruebas

de Regresin en cada una de las aplicaciones donde sea de aplicacin el mismo.

2.2.4 ATRIBUTOS DEL REGISTRO DE EJECUCION DE PRUEBAS

Para poder gestionar la ejecucin de las pruebas de una manera homognea se deben respetar las siguientes definiciones: Estado del Caso de Prueba

A cada caso de prueba que es ejecutado se le debe asociar un Estado de ejecucin. Los posibles estados

de ejecucin para un caso de prueba son:

Estado

Ejecucin

Descripcin

xito El caso de prueba fue ejecutado con xito. Coincide con el resultado esperado.

Falla El caso de prueba fue ejecutado y se encontraron fallos. El resultado no coincide con

lo esperado.

No Completado El caso de prueba fue ejecutado parcialmente pero no completado.

No Ejecutado El caso de prueba no ha sido ejecutado. Es el estado inicial para todos los casos de

prueba.

N/A No aplica. Por ejemplo porque est en diseo, pendiente datos en el entorno, etc.

Como norma general si el estado de ejecucin es Falla quiere decir que hay una incidencia asociada al

caso de prueba.

2.2.5 ATRIBUTOS DEL REGISTRO DE INCIDENCIAS DE PRUEBAS

Para poder gestionar las incidencias de las pruebas de una manera homognea se deben respetar las siguientes definiciones: Estado de la Incidencia

A cada Incidencia se le debe asociar un Estado. Los posibles estados de incidencias son:

Estado

Incidencia

Descripcin

Hallado El equipo de pruebas reporta un incidente. El incidente se encuentra pendiente de

solucin.

Asignado El incidente ha sido asignado a desarrollo, se encuentra pendiente de solucin.

Corregido Desarrollo corrige el incidente y notifica al equipo de pruebas. La correccin est


disponible en el entorno de pruebas.

Cerrado El equipo de pruebas corrobora que el incidente fue corregido por desarrollo y la

incidencia es cerrada.

Rechazado

Desarrollo o responsable de proyecto informa que el incidente ha sido rechazado. Los

motivos del rechazo pueden ser: No reproducible, No aplica desarrollo, Repetido. Ver

tabla Motivo Rechazo para mayor detalle.

Re abierto Un incidente fue corregido por desarrollo pero este todava se manifiesta. La

incidencia vuelve a pasar por el ciclo normal.

Descartado Queda descartada la resolucin del incidente para el Mantenimiento posterior

Paso a

Correctivo

El incidente deber ser corregido en accin independiente de Mantenimiento a la

actividad donde se ha hallado el mismo

Diagrama de Flujo de Estado de una Incidencia

Prioridad de la Incidencia

A cada Incidencia se le puede asociar una Prioridad que permita establecer criterios de urgencia para su

resolucin. Las posibles prioridades de incidencias son: Alta. Media o Baja

Criticidad de la Incidencia


A cada Incidencia se le puede asociar una Criticidad que permita establecer el impacto que provoca en el

Negocio en el caso de no estar resuelta. Las posibles Criticidades de incidencias son:

Criticidad

Incidencia

Descripcin

Invalidante

El incidente impide la prueba de una funcionalidad. Debe ser solucionado

inmediatamente para poder testear la funcionalidad, no hay otra alternativa para

ejecutar la funcionalidad. Ejemplos: no es posible acceder a una pantalla o se

produce un error al presionar un botn clave en una pantalla, opcin del men no

disponible, etc.

Alta

Implica un funcionamiento incorrecto grave en situaciones con probabilidad de

ocurrencia alta o media. El incidente debe ser solucionado para poder realizar la

puesta en produccin de la funcionalidad. Ejemplos: calculo incorrecto, actualizacin

de campo errneo, etc.

Media

El impacto del incidente es medio y su probabilidad de ocurrencia tambin o existe

alguna contingencia que permita evitar el incidente. Tambin se incluyen incidentes

con baja probabilidad de ocurrencia pero cuyo impacto es muy alto o viceversa.

Segn el tipo de proyecto y los tiempos disponibles para la correccin de incidentes

se decidir si se puede realizar un pasaje a produccin sin solucionar incidentes

dentro de esta categora.

Baja

La probabilidad de ocurrencia del incidente es relativamente baja y su impacto no es

alto. Suelen estar relacionados a mal uso del sistema (validaciones de longitudes o

tipos de campo), mensajes incorrectos no importantes, mejoras que pueden esperar,

errores cosmticos, etc. Si bien es posible coexistir con estos incidentes, la correccin

de los mismos ayuda a tener un sistema de mayor calidad, robustez y usabilidad.

Mejora Para indicar una mejora a ser planteada en la prxima versin del software.

Motivo de Rechazo de la Incidencia

Si una Incidencia es rechazada, se le debe de indicar el Motivo de su Rechazo. Los posibles Motivos de

Rechazo de incidencias son:

Motivo de Rechazo

de la Incidencia

Descripcin

No reproducible Desarrollo informa que no pudo reproducir la incidencia por falta de informacin

o bien el incidente ha sido solucionado al corregir otro incidente.

No aplica desarrollo Desarrollo considera que no es un incidente.

Repetido El incidente es una rplica de otro incidente reportado anteriormente. Se

recomienda poner un enlace a dicha incidencia.


3. CLASIFICACION DE LAS PRUEBAS

3.1. ACTIVIDADES DE PRUEBAS

Para realizar la ejecucin de las pruebas se deben realizar distintas actividades que deben ser observadas

en todo proceso de pruebas:

Unitaria Bsica: Conjunto de Pruebas dirigido a validar el correcto funcionamiento de cada uno los

componentes individuales del Sistema.

Son las pruebas de mayor nivel de detalle realizadas por los desarrolladores, en las que se asla

cada componente del Sistema y se prueba por separado. Tambin son realizadas por los equipos

de P&I en lo relativo a instalacin de infraestructuras.

Unitaria: Conjunto de Pruebas dirigido a validar que los Requisitos del Sistema se han cubierto

satisfactoriamente.

Son las pruebas que realizan los desarrolladores/testers del sistema para poder realizar su entrega

a la Cuenta. Se denomina Unitaria porque principalmente se prueba cada uno de los Requisitos del

Sistema, si bien, puede que se ejecuten algunas pruebas integradas para validar la funcionalidad

del sistema en su completitud. Su ejecucin se realiza en los entornos de Desarrollo, aunque, a

menudo es necesario ejecutarlas en el entorno de integracin por cuestiones de aislamiento de las

pruebas del trabajo de desarrollo y por la calidad de los datos existentes.

Integrada: Conjunto de Pruebas dirigido a validar que el Sistema est en condiciones de ser entregado al

Negocio.

Son las pruebas de aceptacin que realiza la Cuenta antes de su entrega al Negocio. Se denomina

Integrada por que el Sistema debe ser visto de forma integrada tanto de manera interna, como con

el resto de Sistemas con los cuales tiene interrelacin, que dan soporte al Negocio. Bsicamente

se ejecutan pruebas de integracin orientadas a Escenarios de Negocio, si bien tambin pueden

ejecutarse pruebas de carcter unitario. Su ejecucin se realiza normalmente en el entorno de

Integracin.

Aceptacin de Usuario: Conjunto de pruebas dirigido a validar que el Sistema est en condiciones de ser

puesto en Produccin.

Son las pruebas de aceptacin que realiza el cliente. Se prueban las funcionalidades del Sistema

segn los criterios de aceptacin previamente establecidos con el cliente. Son pruebas orientadas a

Escenarios de Negocio y se suelen ejecutar en el entorno de Integracin. En el caso de peticiones

de mantenimiento, las pruebas de aceptacin pueden estar definidas individualmente sin estar

orientadas a Escenarios de Negocio.

Regresin: Conjunto de Pruebas dirigido a validar que el Sistema en funcionamiento sigue estando en

condiciones de ser usado con normalidad.


Se realizan despus de haber hecho cambios en el Sistema para asegurar que no se han

introducido defectos. Deben de realizarse cuando se produzca una instalacin de software que

pueda impactar sobre la funcionalidad existente, aplicando a todas las actividades de pruebas:

Unitarias, Integracin y Aceptacin de Usuario.

Deben de identificarse los casos de prueba que servirn para realizar las pruebas de regresin, para

facilitar su uso en Mantenimiento. Estos casos de prueba deberan de ser considerados como

candidatos para realizar su automatizacin.

3.2. TIPOS DE PRUEBAS

Atendiendo a la Naturaleza de lo que se quiere probar pueden ser:

Funcionales: Orientadas a validar los requisitos funcionales de la aplicacin.

Deben de contemplarse en todos los tipos de actividades de pruebas definidos.

No Funcionales: Orientadas a validar los requisitos no funcionales de la aplicacin.

Las pruebas No Funcionales pueden ser, a su vez, de distintos tipos dependiendo del requisito que

se deba de probar en cada caso, tales como Portabilidad o Configuracin (Pruebas bajo diferentes

configuraciones de hardware, sistemas operativos, GUIs, BBDD, etc.,), Legales (Prueban que un

sistema cumple con los requisitos legales existentes), y, por su especial relevancia, caben

destacarse, las pruebas de Seguridad y las pruebas de Rendimiento.

La validacin de los Requisitos No Funcionales se realiza normalmente a travs de probar el

funcionamiento del sistema.

Seguridad: Son pruebas que validan la seguridad a nivel interno (roles) y externo (intrusiones).

Las pruebas de seguridad interna se validan a travs de pruebas especficas entrando en la

aplicacin con distintos roles.

Las pruebas de seguridad externa se pueden validar comprobando el acceso de los usuarios a

travs de una red externa o bien ejecutando un software automtico de inspeccin de cdigo

especfico para buscar vulnerabilidades.

Rendimiento: Pruebas del comportamiento del sistema para determinar lo rpido que realiza una tarea un

sistema en condiciones particulares de trabajo

Hay tres variables fundamentales que hay que tener en cuenta para realizar pruebas de Rendimiento:

Datos: El volumen de datos puede influir negativamente segn que tipo de transacciones se

realicen en el sistema.

Usuarios: En este caso hay que tener en cuenta el nmero de usuarios concurrentes que

pueden acceder al sistema.

Tiempo de Respuesta: Esta variable normalmente viene condicionada por las expectativas del

cliente a la hora de usar el sistema, el cual podra invalidar su uso.


Mediante las pruebas de Rendimiento se comprueba si un Sistema con una carga de Datos y Usuarios

determinada, es capaz de dar un Tiempo de Respuesta asumible para el Cliente y, as mismo, sirven

para establecer la capacidad lmite del sistema en cuanto al almacenamiento de Datos y acceso

concurrente de Usuarios

Pruebas de Infraestructura: Orientadas a validar los componentes de Infraestructura (Software y

Hardware).

La mayora de estas pruebas son realizadas durante la actividad de Pruebas Unitarias Bsicas y,

por tanto, no es necesario su registro.

4. TRAZABILIDAD

Las pruebas, tienen la trazabilidad que a continuacin se detalla:

Proceso de Negocio

Escenario de Negocio

Requisito

Caso de Prueba

5. ANEXO

5.1. MTRICAS DURANTE CICLO DE PRUEBAS

Es importante establecer algn tipo de mtrica a colectar para poder informar avances y hacer un

seguimiento apropiado del proyecto. A seguir algunas mtricas relevantes para colectar durante el ciclo de

pruebas.

Mtrica Definicin Objetivo Cmo Calcular

Densidad de Defectos

La densidad de defectos

ofrece una medida sobre

la proporcin de

defectos con respecto a

la cantidad de casos de

prueba.

Nos permite realizar

anlisis comparativos de

la cantidad de defectos,

entre las distintas

funcionalidades que lo

componen.

La densidad de

defectos se calcula

para cada

funcionalidad como:


Donde:

DD: densidad de defectos.

TD: nmero de defectos encontrados durante las pruebas, en la funcionalidad definida.

CCP: Cantidad casos de prueba en dicha Funcionalidad

Cobertura de Pruebas

contra definicin

Define el grado de

cobertura de las

pruebas definidas en

relacin a la

funcionalidad total del

software.

Esta mtrica permite

detectar si hay

funcionalidad que no esta

cubierta por ningn caso

de pruebas

Cantidad de Casos de

de uso con prueba

asociada / Total de

casos de uso.

Avance en ejecucin

de pruebas

ndice que mide el nivel

de ejecucin de las

pruebas que han sido

definidas

Saber qu cantidad del

total de casos de pruebas

definidos, ha sido

ejecutado y cuanto falta

por ejecutar

Cantidad de casos de

prueba ejecutados /

Cantidad de casos

totales a ejecutar

Acumulado Apertura

vs cierre de defectos

Comparativa de defectos

abiertos vs cerrados

Permite comprobar que al

final de la prueba el

acumulado de defectos

cerrados converge hacia

el acumulado de abiertos

Cantidad de defectos

cerrados / Cantidad de

defectos abiertos

5.2. GLOSARIO

Termino Descripcin

Aseguramiento de

Calidad

Todas las actividades planificadas y sistemticas necesarias para aportar la

confianza suficiente en que un producto o servicio cumplir con unos

requisitos dados de calidad.

Calidad Conjunto de propiedades y de caractersticas de un producto o servicio, que

le confieren su aptitud para satisfacer unas necesidades explcitas e


implcitas.

Escenario Secuencia de eventos y/o actividades que simulan la aplicacin del proceso

de negocio definido en condiciones reales.

Caso de Prueba Conjunto de condiciones o variables que tienen por objetivo, validar si el

requisito de una aplicacin / producto se ha cubierto satisfactoriamente.

Defecto Una manifestacin de un error.

Metodologia de Pruebas V2

Documents

Transcript of Metodologia de Pruebas V2