METODOLOGIA DE PRUEBAS

Actualizacin: 2.1
Autor: OdP Calidad de Metodologa

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 1 de 18

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

1.0
1.1
1.2
1.3
2.0

CCA
EFS
CAC
CAC
CAC y JRA

31/Oct/07
Marzo 2009
Julio 2009
Noviembre 2011

2.1

CdM

19/04/2012

Direccin de Sistemas de Informacin

Descripcin del cambio

Primera versin del documento
Apartado de Mtricas.
Actualizacion Puntos 2 y 4.1
Adaptacin MGD 3.3
Reformulacin Metodolgica (Taller Metodologa de
Pruebas)
Atributos en la definicin de escenarios de prueba.

Metodologa de Pruebas v2.1.doc

Pg. 2 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 3 de 18

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:

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 4 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 5 de 18

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.
Las actividades de esta fase son las siguientes:

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

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 6 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 7 de 18

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

Alta

Media

Baja

Descripcin

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.
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.
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
Identifica al escenario de prueba como no reutilizable para la actividad de pruebas de
regresin.

No

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 8 de 18

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.
Las actividades de esta fase son las siguientes:

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 9 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 10 de 18

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
xito
Falla
No Completado
No Ejecutado
N/A

Descripcin
El caso de prueba fue ejecutado con xito. Coincide con el resultado esperado.
El caso de prueba fue ejecutado y se encontraron fallos. El resultado no coincide con
lo esperado.
El caso de prueba fue ejecutado parcialmente pero no completado.
El caso de prueba no ha sido ejecutado. Es el estado inicial para todos los casos de
prueba.
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
Hallado
Asignado
Corregido

Descripcin
El equipo de pruebas reporta un incidente. El incidente se encuentra pendiente de
solucin.
El incidente ha sido asignado a desarrollo, se encuentra pendiente de solucin.
Desarrollo corrige el incidente y notifica al equipo de pruebas. La correccin est

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 11 de 18

Cerrado

Rechazado

Re abierto
Descartado
Paso a
Correctivo

disponible en el entorno de pruebas.

El equipo de pruebas corrobora que el incidente fue corregido por desarrollo y la
incidencia es cerrada.
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.
Un incidente fue corregido por desarrollo pero este todava se manifiesta. La
incidencia vuelve a pasar por el ciclo normal.
Queda descartada la resolucin del incidente para el Mantenimiento posterior
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

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 12 de 18

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

Invalidante

Alta

Media

Baja

Mejora

Descripcin
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.
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.
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.
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.
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
No reproducible
No aplica desarrollo
Repetido

Descripcin
Desarrollo informa que no pudo reproducir la incidencia por falta de informacin
o bien el incidente ha sido solucionado al corregir otro incidente.
Desarrollo considera que no es un incidente.
El incidente es una rplica de otro incidente reportado anteriormente. Se
recomienda poner un enlace a dicha incidencia.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 13 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 14 de 18

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.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 15 de 18

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

Requisito

Caso de
Prueba

Escenario de
Negocio

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
Densidad de Defectos

Definicin
La densidad de defectos
ofrece una medida sobre
la proporcin de
defectos con respecto a
la cantidad de casos de
prueba.

Direccin de Sistemas de Informacin

Objetivo
Nos permite realizar
anlisis comparativos de
la cantidad de defectos,
entre las distintas
funcionalidades que lo
componen.

Metodologa de Pruebas v2.1.doc

Cmo Calcular
La densidad de
defectos se calcula
para cada
funcionalidad como:

Pg. 16 de 18

Donde:

Cobertura de Pruebas
contra definicin

Avance en ejecucin
de pruebas

Acumulado Apertura
vs cierre de defectos

5.2.

Define el grado de
cobertura de las
pruebas definidas en
relacin a la
funcionalidad total del
software.
ndice que mide el nivel
de ejecucin de las
pruebas que han sido
definidas
Comparativa de defectos
abiertos vs cerrados

DD: densidad
de defectos.
TD: nmero
de defectos
encontrados
durante las
pruebas, en la
funcionalidad
definida.
CCP: Cantidad
casos de
prueba en
dicha
Funcionalidad

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.

Saber qu cantidad del

total de casos de pruebas
definidos, ha sido
ejecutado y cuanto falta
por ejecutar
Permite comprobar que al
final de la prueba el
acumulado de defectos
cerrados converge hacia
el acumulado de abiertos

Cantidad de casos de
prueba ejecutados /
Cantidad de casos
totales a ejecutar
Cantidad de defectos
cerrados / Cantidad de
defectos abiertos

GLOSARIO

Termino
Aseguramiento de
Calidad
Calidad

Descripcin
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.
Conjunto de propiedades y de caractersticas de un producto o servicio, que
le confieren su aptitud para satisfacer unas necesidades explcitas e

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 17 de 18

Escenario
Caso de Prueba
Defecto

implcitas.
Secuencia de eventos y/o actividades que simulan la aplicacin del proceso
de negocio definido en condiciones reales.
Conjunto de condiciones o variables que tienen por objetivo, validar si el
requisito de una aplicacin / producto se ha cubierto satisfactoriamente.
Una manifestacin de un error.

Direccin de Sistemas de Informacin

Metodologa de Pruebas v2.1.doc

Pg. 18 de 18