[Nombre del proyecto]

Plan de Verificacin y Validacin

Versin [1.0]
[Este documento es la plantilla base para elaborar el documento Plan de
Verificacin. Los textos que aparecen entre parntesis rectos son explicaciones de
que debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por
el contenido que corresponda. Para actualizar la tabla de ontenido! ha"a clic con el
botn derecho del ratn sobre cualquier l#nea del contenido de la misma y
seleccione Actualizar campos! en el cuadro que aparece seleccione Actualizar toda
la tabla y ha"a clic en el botn $ceptar%
Historia de revisiones
&echa Versin Descripcin $utor
[dd'mm'aaaa% [x.x% [detalles% [nombre%



Plan de Verificacin y Validacin P("ina ) de )*
Contenido
1.INTRODUCCIN....................................................................................................................................3
1.1.PROPSITO............................................................................................................................................3
1.2.PUNTO DE PARTIDA..............................................................................................................................3
1.3.ALCANCE..............................................................................................................................................3
1.4.IDENTIFICACIN DEL PROYECTO..........................................................................................................3
1.5.ESTRATEGIA DE EVOLUCIN DEL PLAN...............................................................................................3
2.REQUERIMIENTOS PARA VERIFICAR...........................................................................................3
3.ESTRATEGIA DE VERIFICACIN.....................................................................................................4
3.1.TIPOS DE PRUEBAS................................................................................................................................4
3.1.1.Prueba de integridad de los datos y la base de datos..................................................................4
3.1.2.Prueba de Funcionalidad.............................................................................................................4
3.1.3.Prueba de Ciclo del Negocio........................................................................................................5
3.1.4.Prueba de Interfase de Usuario....................................................................................................5
3.1.5.Prueba de Performance................................................................................................................6
3.1.6.Prueba de Carga..........................................................................................................................
3.1..Prueba de !sfuer"o #stress$ com%etencia %or recursos$ ba&os recursos'.....................................
3.1.(.Prueba de )olumen......................................................................................................................(
3.1.*.Prueba de +eguridad y Control de ,cceso...................................................................................*
3.1.1-.Prueba de Fallas y .ecu%eraci/n..............................................................................................*
3.1.11.Prueba de Configuraci/n.........................................................................................................11
3.1.12.Prueba de Instalaci/n...............................................................................................................11
3.1.13.Prueba de 0ocumentos.............................................................................................................12
3.2.HERRAMIENTAS..................................................................................................................................13
4.RECURSOS.............................................................................................................................................13
4.1.ROLES.................................................................................................................................................13
4.2.SISTEMA.............................................................................................................................................14
5.HITOS DEL PROYECTO DE VERIFICACIN...............................................................................14
6.ENTREGABLES.....................................................................................................................................14
6.1.MODELO DE CASOS DE PRUEBA ........................................................................................................15
6.2.INFORMES DE VERIFICACIN..............................................................................................................15
6.3.EVALUACIN DE LA VERIFICACIN....................................................................................................16
6.4.INFORME FINAL DE VERIFICACIN......................................................................................................16
7.DEPENDENCIAS OPCIONAL!..........................................................................................................16
7.1.DEPENDENCIA DE PERSONAL [OPCIONAL..........................................................................................16
7.2.DEPENDENCIA DE SOFT!ARE [OPCIONAL.........................................................................................16
7.3.DEPENDENCIA DE HARD!ARE [OPCIONAL........................................................................................16
7.4.DEPENDENCIA DE DATOS Y BASE DE DATOS DE PRUEBA [OPCIONAL................................................16
".RIESGOS OPCIONAL!........................................................................................................................17
".1.PLANIFICACIN [OPCIONAL...............................................................................................................17
".2.T#CNICO [OPCIONAL.........................................................................................................................17
".3.GESTIN [OPCIONAL.........................................................................................................................17
#.AP$NDICE..............................................................................................................................................1#
$.1.NIVELES DE GRAVEDAD DE ERROR.....................................................................................................1$
$.2.NIVELES DE ACEPTACIN PARA LO ELEMENTOS VERIFICADOS..........................................................1$
Plan de Verificacin y Validacin P("ina + de )*
1. Introduccin
1.1. Propsito
Este Plan de Verificacin para el proyecto [,ombre del proyecto% soporta los
si"uientes ob-eti.os/
[0dentificar la informacin de proyecto existente y los componentes de
soft1are que deben ser .erificados.%
[Enumerar los requerimientos recomendados para .erificar.%
[2ecomendar y describir las estrate"ias de .erificacin que ser(n usadas.%
[0dentificar los recursos necesarios y proporcionar una estimacin de esfuerzo
para realizar la .erificacin.%
[Enumerar los entre"ables del proyecto de .erificacin.%
1.. Punto de partida
[Esta seccin contiene una bre.e descripcin del destino de la .erificacin
3componentes! aplicacin! sistema! etc.4 y sus ob-eti.os. 5e debe incluir
informacin como sus caracter#sticas m(s importantes! su arquitectura y una
bre.e historia del proyecto.%
1.!. "lcance
[En esta seccin describa las fases o estados de la .erificacin! 6nitaria!
0nte"racin! 5istema y los tipos de pruebas que se har(n en este plan! como
son &uncional o Performance.
Proporcione una lista bre.e de las caracter#sticas que ser(n ob-eto de
.erificacin y cuales no lo ser(n.
Enumere cualquier supuesto hecho durante el desarrollo que pueda impactar
el dise7o! desarrollo o implementacin de la .erificacin.
Enumere cualquier ries"o o contin"encia que pueda afectar el dise7o!
desarrollo o implementacin de la .erificacin.
Enumere cualquier restriccin que pueda afectar el dise7o! desarrollo o
implementacin de la .erificacin.%
1.#. Identificacin del proyecto
Los documentos usados para elaborar el Plan de Verificacin son los
si"uientes/
[En esta seccin enumere la documentacin usada para elaborar el plan de
.erificacin y la disponibilidad de la misma.%
1.$. %strate&ia de evolucin del Plan
[Especificacin de la estrate"ia para realizar cambios a"endados y no
a"endados al Plan de Verificacin y Validacin.
Debe contener/
8uien es responsable de monitorear el Plan de Verificacin y Validacin.
on cuanta frecuencia se realizar(n modificaciones al Plan.
omo ser(n e.aluados y aprobados los cambios al Plan.
omo ser(n realizados y comunicados los cambios al Plan.%
. 'e(uerimientos para verificar
En la lista a continuacin se presentan los elementos! casos de uso!
requerimientos funcionales y requerimientos no funcionales! que ser(n
.erificados.
Plan de Verificacin y Validacin P("ina 9 de )*
[Lista de los requerimientos m(s importantes a ser .erificados. En esta
seccin indique qu elementos ser(n .erificados.%
!. %strate&ia de Verificacin
[Esta seccin presenta el enfoque recomendado para la .erificacin. Describe
como se .erificar(n los elementos.
Para cada tipo de prueba! proporcione una descripcin de la prueba y porque
ser( implementada y e-ecutada.
5i un tipo de prueba no ser( implementada y e-ecutada! indique bre.emente
cual es la prueba que no se implementar( o e-ecutar( y una -ustificacin de
ello.
5e indicar(n las tcnicas usadas y el criterio para saber cuando una prueba se
complet 3criterio de aceptacin4.
Las pruebas se deben e-ecutar usando bases de datos conocidas y controladas
en un ambiente se"uro.%
!.1. )ipos de pruebas
[En las secciones a continuacin! que son los tipos de pruebas a realizar! para
cada tipo de prueba en lu"ar de explicar el contenido de cada seccin y
subseccin se incluyen e-emplos.%
!.1.1. Prueba de inte&ridad de los datos y la base de datos
3.1.1.1. Objetivo de la prueba
[$se"urar que los mtodos y procesos de acceso a la base de datos funcionan
correctamente y sin corromper datos.%
3.1.1.2. Tcnica
[0n.oque cada mtodo o proceso de acceso a la base de datos con datos
.(lidos y no .(lidos.%
[0nspeccione la base de datos para ase"urarse de que se han "uardado los
datos correctos! que todos los e.entos de la base de datos ocurrieron
correctamente! o repase los datos de.ueltos para ase"urar que se
recuperaron datos correctos por la .#a correcta.%
3.1.1.3. Criterio de aceptacin
[:odos los mtodos y procesos de acceso a la base de datos funcionan como
fueron dise7ados y sin datos corruptos.%
3.1.1.4. Consideraciones especiales
[La prueba requiere un entorno de administracin de D;<5 o controladores
para in"resar o modificar informacin directamente en la base de datos.
Los procesos deben ser in.ocados manualmente.
5e deben usar bases de datos peque7as para aumentar la facilidad de
inspeccin de los datos para .erificar que no sucedan e.entos no aceptables.%
!.1.. Prueba de *uncionalidad
[La prueba de funcionalidad se enfoca en requerimientos para .erificar que se
corresponden directamente a casos de usos o funciones y re"las del ne"ocio.
Los ob-eti.os de estas pruebas son .erificar la aceptacin de los datos! el
proceso! la recuperacin y la implementacin correcta de las re"las del
ne"ocio. Este tipo de prueba se basa en tcnicas de ca-a ne"ra! que consisten
en .erificar la aplicacin y sus procesos interactuando con la aplicacin por
medio de la interfase de usuario y analizar los resultados obtenidos.%
3.1.2.1. Objetivo de la prueba
Plan de Verificacin y Validacin P("ina = de )*
[$se"urar la funcionalidad apropiada del ob-eto de prueba! incluyendo la
na.e"acin! entrada de datos! proceso y recuperacin.%
3.1.2.2. Tcnica
[E-ecute cada caso de uso! flu-o de caso de uso! o funcin usando datos
.(lidos y no .(lidos! para .erificar lo si"uiente/
5e obtienen los resultados esperados cuando se usan datos .(lidos.
uando se usan datos no .(lidos se desplie"an los mensa-es de error o
ad.ertencia apropiados.
5e aplica apropiadamente cada re"la del ne"ocio.%
3.1.2.3. Criterio de aceptacin
[:odas las pruebas planificadas se realizaron. :odos los defectos encontrados
han sido debidamente identificados.%
3.1.2.4. Consideraciones especiales
[0dentificar o describir aquellos elementos o problemas 3internos o externos4
que impactaron en la implementacin y e-ecucin de las pruebas de
funcionalidad.%
!.1.!. Prueba de Ciclo del Ne&ocio
[Esta prueba debe simular las acti.idades realizadas en el proyecto en el
tiempo. 5e debe identificar un per#odo! que puede ser un a7o! y se deben
e-ecutar las transacciones y acti.idades que ocurrir#an en el per#odo de un
a7o. Esto incluye todos los ciclos diarios! semanales y mensuales y e.entos
que son sensibles a la fecha.%
3.1.3.1. Objetivo de la prueba
[$se"urar que la aplicacin funciona de acuerdo a los requerimientos del
ne"ocio.%
3.1.3.2. Tcnica
[La prueba debe simular ciclos de ne"ocios realizando lo si"uiente/
Las pruebas de funcionalidad se deben modificar para aumentar la cantidad
de .eces que se e-ecuta cada funcin! simulando .arios usuarios diferentes en
un per#odo determinado.
:odas las funciones sensibles a la fecha se deben e-ecutar con fechas .(lidas
y no .(lidas o per#odos de tiempo .(lidos y no .(lidos.
Para cada prueba realizada .erificar lo si"uiente/
5e obtienen los resultados esperados cuando se usan datos .(lidos.
uando se usan datos no .(lidos se desplie"an los mensa-es de error o
ad.ertencia apropiados.
5e aplica apropiadamente cada re"la del ne"ocio.%
3.1.3.3. Criterio de aceptacin
[:odas las pruebas planificadas se realizaron. :odos los defectos encontrados
han sido debidamente identificados.%
3.1.3.4. Consideraciones especiales
[Las fechas del sistema y e.entos requieren acti.idades de soporte especiales.
5e requieren las re"las del ne"ocio para identificar apropiadamente los
requerimientos y procedimientos a ser .erificados.%
!.1.#. Prueba de Interfase de +suario
Plan de Verificacin y Validacin P("ina > de )*
[Esta prueba .erifica que la interfase de usuario proporcione al usuario el
acceso y na.e"acin a tra.s de las funciones apropiada. $dem(s ase"ura
que los ob-etos presentes en la interfase de usuario se muestren como se
espera y conforme a los est(ndares establecidos por la empresa o de la
industria.%
3.1.4.1. Objetivo de la prueba
[Verificar que/ la na.e"acin a tra.s de los elementos que se est(n probando
refle-en las funciones del ne"ocio y los requerimientos! incluyendo mane-o de
.entanas! campos y mtodos de acceso? los ob-etos de las .entanas y
caracter#sticas! como men@es! tama7o! posicin! estado funcionen de acuerdo
a los est(ndares.%
3.1.4.2. Tcnica
[rear o modificar pruebas para cada .entana .erificando la na.e"acin y los
estados de los ob-etos para cada .entana de la aplicacin y cada ob-eto
dentro de la .entana.%
3.1.4.3. Criterio de aceptacin
[ada .entana ha sido .erificada exitosamente siendo consistente con una
.ersin de referencia o est(ndar establecido.%
3.1.4.4. Consideraciones especiales
[,o todas las propiedades de los ob-etos se pueden acceder.%
!.1.$. Prueba de Performance
[En esta prueba se miden y e.al@an los tiempos de respuesta! los tiempos de
transaccin y otros requerimientos sensiti.os al tiempo. El ob-eti.o de la
prueba es .erificar que se lo"ren los requerimientos de performance. La
prueba de performance es implementada y e-ecutada para poner a punto los
destinos de pruebas de performance como funcin de condiciones de traba-o o
confi"uraciones de hard1are.%
3.1.5.1. Objetivo de la prueba
[Verificar la performance de determinadas transacciones o funciones de
ne"ocio ba-o ciertas condiciones/
condiciones de traba-o normales conocidas.
peores casos de condiciones de traba-o conocidas.%
3.1.5.2. Tcnica
[6sar procedimientos de prueba desarrollados para .erificar funciones
o ciclos de ne"ocio.
<odificar archi.os de datos para aumentar el n@mero de transacciones
o los procedimientos de prueba para aumentar el n@mero de
iteraciones de ocurrencia de transacciones.
Las pruebas se deben e-ecutar en una m(quina 3me-or caso de prueba
un solo usuario! una sola transaccin4 y se debe repetir con m@ltiples
usuarios 3.irtuales o reales4.%
3.1.5.3. Criterio de aceptacin
[on una transaccin o un usuario/ Axito completo de la prueba sin fallas y
dentro del tiempo esperado o requerido.
on m@ltiples transacciones y .arios usuarios/ Axito completo de la prueba sin
fallas y dentro de un tiempo aceptable.%
3.1.5.4. Consideraciones especiales
Plan de Verificacin y Validacin P("ina B de )*
[Las pruebas de performance deben incluir un traba-o de fondo en el ser.idor.
Esto se puede realizar de distintas formas/
En.iar transacciones directamente al ser.idor! "eneralmente en la
forma de consultas 358L4.
rear usuarios .irtuales para simular muchos clientes! "eneralmente
.arios cientos. 5e pueden usar herramientas de Emulacin de :erminar
2emota para lo"rar este ob-eti.o. Esta tcnica tambin se usa para
car"ar la red con CtraficoD.
6sar muchos clientes f#sicos! cada uno corriendo procedimientos de
prueba.
La prueba de performance se debe realizar en una m(quina dedicada para
permitir control total y medicin exacta.
Las bases de datos usadas para las pruebas de performance deben tener un
tama7o similar a las reales.%
!.1.,. Prueba de Car&a
[La prueba de car"a somete los ob-etos a .erificar a diferentes car"as de
traba-o para medir y e.aluar los comportamientos de performance y la
habilidad de los ob-etos de continuar funcionando apropiadamente ba-o
diferentes car"as de traba-o. El ob-eti.o es determinar y ase"urar que el
sistema funciona apropiadamente en circunstancias de m(xima car"a de
traba-o esperada. $dem(s e.aluar las caracter#sticas de performance! como
tiempos de respuesta! tiempos de transacciones y otros elementos sensiti.os
al tiempo.%
3.1..1. Objetivo de la prueba
[Verificar el comportamiento de performance de determinados componentes
del soft1are ba-o condiciones de traba-o diferentes.%
3.1..2. Tcnica
[6sar pruebas desarrolladas para funciones o ciclos de ne"ocios y modificar
archi.os de datos para aumentar el n@mero de transacciones o las pruebas
para aumentar la cantidad de ocurrencia de transacciones.%
3.1..3. Criterio de aceptacin
[Para m@ltiples transacciones y m@ltiples usuarios/ 2ealizacin exitosa de las
pruebas sin fallas y dentro del tiempo aceptable.%
3.1..4. Consideraciones especiales
[La prueba de car"a debe realizarse en una m(quina dedicada para tener
control total y exactitud de mediciones.
Las bases de datos usadas para la prueba deben tener un tama7o similar a las
reales.%
!.1.-. Prueba de %sfuer.o /stress0 competencia por recursos0 ba1os
recursos2
[La prueba de esfuerzo en un tipo de prueba de performance implementada y
e-ecutada para encontrar errores cuando hay pocos recursos o cuando hay
competencia por recursos. Poca memoria o poco espacio de disco pueden
re.elar fallas en el soft1are que no aparecen ba-o condiciones normales de
cantidad de recursos. Etras fallas pueden resultar al competir por recursos
compartidos como bloqueos de bases de datos o ancho de banda de red. La
prueba de esfuerzo tambin puede usarse para identificar el traba-o m(ximo
que el soft1are puede mane-ar.%
3.1.!.1. Objetivo de la prueba
Plan de Verificacin y Validacin P("ina F de )*
[Verificar que el soft1are funciona apropiadamente y sin error ba-o
condiciones de esfuerzo! como son/
poca memoria o sin disponibilidad de memoria en el ser.idor
cantidad m(xima de clientes conectados
m@ltiples usuarios realizando la misma operacin sobre los mismos
datos
peor caso de .olumen de operaciones.
El ob-eti.o de la prueba de esfuerzo es tambin identificar y documentar las
condiciones ba-o las cuales el sistema falla y no continua funcionando
apropiadamente.%
3.1.!.2. Tcnica
[6sar las pruebas desarrolladas para Performance y Prueba de ar"a.
Para probar recursos limitados! las pruebas se deben e-ecutar en una sola
m(quina! y se debe reducir o limitar la memoria en el ser.idor.
Para las pruebas de esfuerzo restantes! deber usarse m@ltiples clientes!
cualquiera que e-ecute las mismas pruebas o pruebas complementarias para
producir el peor caso de .olumen de operaciones.%
3.1.!.3. Criterio de aceptacin
[:odas las pruebas planeadas se e-ecutaron y se alcanzaron o excedieron los
l#mites del sistema sin que el soft1are fallara o las condiciones ba-o las que
ocurre una falla en el soft1are est(n fuera de las condiciones especificadas.%
3.1.!.4. Consideraciones especiales
[Las pruebas de esfuerzo de red pueden requerir herramientas de red para
car"ar la red con mensa-es o paquetes.
La cantidad de disco del ser.idor usada por el sistema debe ser reducida
temporalmente para restrin"ir el espacio disponible para crecimiento de la
base de datos.
5incronizar el acceso simult(neo de .arios clientes accediendo a los mismos
datos.%
!.1.3. Prueba de Volumen
[La Prueba de Volumen somete el soft1are a "randes cantidades de datos
para determinar si se alcanzan l#mites que causen la falla del soft1are. La
Prueba de Volumen identifica la car"a m(xima continua que puede mane-ar el
soft1are a prueba en un per#odo dado.%
3.1.".1. Objetivo de la prueba
[Verificar que el soft1are funciona correctamente con .ol@menes de datos
"randes/
<(ximo 3real o f#sicamente posible4 n@mero de clientes conectados! o
simulados! todos realizando la misma operacin 3peor caso de
operacin4 por un per#odo de tiempo extenso.
<(ximo tama7o de base de datos y m@ltiples consultas e-ecutadas
simult(neamente.%
3.1.".2. Tcnica
[6sar pruebas desarrolladas para Prueba de Performance y Prueba de ar"a.
5e deben usar m@ltiples clientes! e-ecutando las mismas pruebas o
pruebas complementarias para producir el peor caso de .olumen de
operaciones o mezcla en un per#odo de tiempo extenso.
Plan de Verificacin y Validacin P("ina G de )*
5e debe crear el tama7o m(ximo de base de datos 3real! escalado o
con datos representati.os4 y m@ltiples clientes e-ecutando consultas
simult(neamente por un per#odo de tiempo extenso.%
3.1.".3. Criterio de aceptacin
[:odas las pruebas planificadas se e-ecutaron y se han alcanzado o excedido
los l#mites especificados sin que el soft1are falle.%
3.1.".4. Consideraciones especiales
[H8u per#odo de tiempo se considera aceptable para condiciones de "ran
.olumenI%
!.1.4. Prueba de 5e&uridad y Control de "cceso
[La Prueba de 5e"uridad y ontrol de $cceso se enfoca en dos (reas de
se"uridad/
5e"uridad en el (mbito de aplicacin! incluyendo el acceso a los datos
y a las funciones de ne"ocios.
5e"uridad en el (mbito de sistema! incluyendo conexin! o acceso
remoto al sistema.
La se"uridad en el (mbito de aplicacin ase"ura que! basado en la se"uridad
deseada los actores est(n restrin"idos a funciones o casos de uso espec#ficos
o limitados en los datos que est(n disponibles para ellos.
La se"uridad en el (mbito de sistema ase"ura que! solo los usuarios con
derecho a acceder al sistema son capaces de acceder a las aplicaciones y solo
a tra.s de los puntos de in"resos apropiados.%
3.1.#.1. Objetivo de la prueba
5e"uridad en el (mbito de aplicacin/[Verificar que un actor pueda acceder
solo a las funciones o datos para los cuales su tipo de usuario tiene permiso.%
5e"uridad en el (mbito de sistema/ [Verificar que solo los actores con acceso
al sistema y a las aplicaciones! puedan acceder a ellos.%
3.1.#.2. Tcnica
5e"uridad en el (mbito de aplicacin/ [0dentificar y hacer una lista de cada
tipo de usuario y las funciones y datos sobre las que cada tipo tiene permiso.%
[rear pruebas para cada tipo de usuario y .erificar cada permiso creando
operaciones espec#ficas para cada tipo de usuario.%
[<odificar el tipo de usuario y .ol.er a e-ecutar las pruebas para los mismos
usuarios. En cada caso! .erificar que las funciones o datos adicionales est(n
correctamente disponibles o son dene"ados.
$cceso en el (mbito de sistema/ [Ver consideraciones especiales m(s aba-o.%
3.1.#.3. Criterio de aceptacin
[Para cada tipo de actor conocido las funciones y datos apropiados est(n
disponibles! y todas las operaciones funcionan como se espera y e-ecutan las
pruebas de &uncionalidad de la aplicacin.%
3.1.#.4. Consideraciones especiales
[El acceso al sistema debe ser discutido con el administrador del sistema o la
red. Esta prueba no puede requerirse como tal! es una funcin del
administrador del sistema o de la red.%
!.1.10. Prueba de *allas y 'ecuperacin
Plan de Verificacin y Validacin P("ina * de )*
[Las Pruebas de &allas y 2ecuperacin ase"uran que el soft1are puede
recuperarse de fallas de hard1are! soft1are o mal funcionamiento de la red
sin prdida de datos o de inte"ridad de los datos.
La Prueba de 2ecuperacin es un proceso en el cual la aplicacin o sistema se
expone a condiciones extremas! o condiciones simuladas! para causar falla!
como fallas en dispositi.os de Entrada'5alida o punteros a la base de datos
in.(lidos. Los procedimientos de recuperacin se in.ocan y la aplicacin o
sistema es monitoreado e inspeccionado para .erificar que se recupera
apropiadamente la aplicacin o sistema y se lo"re la recuperacin de datos.%
3.1.1$.1. Objetivo de la prueba
[Verificar que los procesos de recuperacin 3manual o autom(ticos4 recuperen
apropiadamente la base de datos! aplicaciones y sistema a un estado conocido
y deseado. En la prueba se incluyen los si"uientes tipos de condiciones/
interrupcin de ener"#a al cliente
interrupcin de ener"#a al ser.idor
interrupcin de comunicaciones mediante los ser.idores de la red
interrupcin de comunicacin o prdida de ener"#a de los discos del
ser.idor o con los controladores
ciclos incompletos 3procesos de filtro de datos interrumpidos! procesos
de sincronizacin de datos interrumpidos4
punteros a la base de datos o cla.es in.(lidos
elementos de datos en la base de datos in.(lidos o corruptos.%
3.1.1$.2. Tcnica
[5e deben usar las pruebas creadas para probar &uncionalidad y iclos de
ne"ocio para crear una serie de operaciones. 6na .ez lo"rado el punto de
comienzo deseado! se deben realizar o simular las si"uientes acciones!
indi.idualmente/
0nterrumpir la ener"#a del cliente/ apa"ar el P.
0nterrumpir la ener"#a del ser.idor/ simular o iniciar el proceso de
apa"ado del ser.idor.
0nterrupcin por medio de los ser.idores de red/ simular o iniciar la
prdida de comunicacin con la red 3desconectar f#sicamente la
comunicacin o apa"ar el ser.idor de red o router
0nterrumpir la comunicacin o quitar la ener"#a de los discos del
ser.idor o sus controladores/ simular o eliminar f#sicamente al
comunicacin con uno o m(s controladores de disco o los discos.%
6na .ez que se lo"raron o simularon estas condiciones! se deben
in.ocar los procedimientos de recuperacin.
Las pruebas de ciclos incompletos utilizan la misma tcnica excepto
que los procesos de bases de datos deben ser abortados a s# mismos o
terminados prematuramente.
Las @ltimas dos pruebas requieren que se lo"re un estado conocido de
la base de datos. 5e deben corromper manualmente campos de la
base de datos! punteros y cla.es traba-ando directamente sobre la
base de datos 3utilizando herramientas para la base de datos4. 5e
deben e-ecutar las pruebas de &uncionalidad y iclo de ne"ocio y
.erificar que los ciclos se completen.%
3.1.1$.3. Criterio de aceptacin
Plan de Verificacin y Validacin P("ina )J de )*
[En todos los casos! la aplicacin! la base de datos y el sistema deben! en la
realizacin procedimientos de recuperacin! .ol.er a un estado conocido y
deseable. Este estado incluye corrupcin de datos limitada al los campos!
punteros o cla.es corruptos conocidos! y reportes indicando los procesos u
operaciones que no se completaron debido a las interrupciones.%
3.1.1$.4. Consideraciones especiales
[Los procedimientos para desconectar cables 3simulando falta de ener"#a o
prdida de comunicacin4 no son deseables o factibles. 5e pueden requerir
mtodos alternati.os! como soft1are de dia"nstico. 5e requieren los "rupos
de recursos de 5istemas! ;ases de datos y 2ed.
Estas pruebas deben e-ecutarse fuera del horario de traba-o normal o en una
m(quina aislada.%
!.1.11. Prueba de Confi&uracin
[La Prueba de onfi"uracin .erifica el funcionamiento del soft1are con
diferentes confi"uraciones de soft1are y hard1are. %
3.1.11.1. Objetivo de la prueba
[Verificar que el soft1are funcione apropiadamente en las confi"uraciones
requeridas de hard1are y soft1are.%
3.1.11.2. Tcnica
[6sar las pruebas de &uncionalidad.
$brir y cerrar .arias sesiones de soft1are que no son ob-eto de
prueba! como parte de la prueba o antes de comenzar la prueba.
E-ecutar operaciones seleccionadas para simular la interaccin del
actor con el soft1are ob-eto de prueba y con el soft1are que no es
ob-eto de prueba.
2epetir los procedimientos anteriores minimizando la memoria
con.encional disponible en la m(quina cliente.%
3.1.11.3. Criterio de aceptacin
[Por cada combinacin de soft1are ob-eto de prueba y soft1are que no es
ob-eto de prueba! todas las operaciones son completadas exitosamente sin
fallas.%
3.1.11.4. Consideraciones especiales
[:odo el soft1are que no es ob-eto de prueba que es necesario y debe estar
accesible.
H8u aplicaciones se usan normalmenteI
H8u informacin se mane-a en las aplicaciones que se usan normalmente! y
que tama7o de informacinI
Los sistemas! red! ser.idores de red! bases de datos! etc.! deben ser
documentados como parte de esta prueba.%
!.1.1. Prueba de Instalacin
[La Prueba de 0nstalacin tiene dos propsitos. 6no es ase"urar que el
soft1are puede ser instalado en diferentes condiciones 3como una nue.a
instalacin! una actualizacin! y una instalacin completa o personalizada4
ba-o condiciones normales y anormales. ondiciones anormales pueden ser
insuficiente espacio en disco! falta de pri.ile"ios para crear directorios! etc. El
otro propsito es .erificar que! una .ez instalado! el soft1are opera
correctamente. Esto si"nifica normalmente e-ecutar un con-unto de pruebas
que fueron desarrolladas para Prueba de &uncionalidad.%
Plan de Verificacin y Validacin P("ina )) de )*
3.1.12.1. Objetivo de la prueba
[Verificar que el soft1are ob-eto de prueba se instala correctamente en cada
confi"uracin de hard1are requerida ba-o las si"uientes condiciones/
instalacin nue.a! una nue.a m(quina! nunca instalada pre.iamente
con [,ombre del proyecto%
actualizacin! m(quina pre.iamente instalada con [,ombre del
proyecto%! con la misma .ersin
actualizacin! m(quina pre.iamente instalada con [,ombre del
proyecto%! con una .ersin anterior.%
3.1.12.2. Tcnica
[<anualmente o desarrollando pro"ramas! para .alidar la condicin de la
m(quina destino 3nue.a! nunca instalado! misma .ersin! .ersin anterior ya
instalada4.
2ealizar la instalacin.
E-ecutar un con-unto de pruebas funcionales ya implementadas para la Prueba
de &uncionalidad.%
3.1.12.3. Criterio de aceptacin
[Las pruebas de funcionalidad de [,ombre de proyecto% se e-ecutan
exitosamente sin fallas.%
3.1.12.4. Consideraciones especiales
[H8u operaciones se deben ser seleccionar para realizar una prueba confiable
de que la aplicacin [,ombre del proyecto% ha sido exitosamente instalada sin
de-ar fuera nin"@n componente importanteI%
!.1.1!. Prueba de 6ocumentos
[La Prueba de Documentos debe ase"urar que los documentos relacionados al
soft1are que se "eneren en el proceso sean correctos! consistentes y
entendible. 5e incluyen como documentos los <ateriales para 5oporte al
6suario! Documentacin :cnica! $yuda en L#nea y todo tipo de documento
que forme parte del paquete de soft1are.%
3.1.13.1. Objetivo de la prueba
[Verificar que el documento ob-eto de prueba sea/
orrecto! esto es! que cumpla con el formato y or"anizacin para el
documento establecido en el proyecto.
onsistente! esto es! que el contenido del documento sea fiel a lo que
hace referencia. 5i el documento es Documentacin de 6suario! que la
explicacin de un procedimiento sea exactamente como se realiza el
procedimiento en el soft1are! si se muestran pantallas que sean las
correctas.
Entendible! esto es! que al leer el documento se entienda
correctamente lo que expresa y sin ambi"Kedades! adem(s que sea
f(cil de leer.%
3.1.13.2. Tcnica
[Para .erificar que el documento es correcto se debe comparar con el
est(ndar definido si existe o con las pautas de documentacin y .er que el
documento cumple con ellas.
Para .erificar que el documento es onsistente se debe e-ecutar el pro"rama
si"uiendo el documento en caso de los <ateriales de 5oporte al 6suario y
comprobar que lo que se explica en estos documentos es exactamente lo que
Plan de Verificacin y Validacin P("ina )+ de )*
se e-ecuta en el pro"rama. En caso de Documentacin :cnica se debe re.isar
el cdi"o al cual corresponde la documentacin y comprobar que dicha
describe el cdi"o.
Para .erificar que el documento es entendible! debe comprobar que se
entiende correctamente! que no tiene ambi"Kedades y que sea f(cil de leer.%
3.1.13.3. Criterio de aceptacin
[El documento expresa exactamente lo que debe expresar! no hay diferencias
entre lo que est( escrito y el ob-eto de la descripcin 3operacin de soft1are!
cdi"o de pro"rama! decisiones tcnicas4 y se entiende f(cilmente.%
3.1.13.4. Consideraciones especiales
[Enumere las consideraciones que considere importantes para la .erificacin
de documentos%
!.. Herramientas
[0n"rese una lista con las herramientas usadas en el proyecto! como son
herramientas de "estin de sistema de bases de datos 3D;<54! herramientas
para "estin de proyecto! se"uimiento de errores! monitoreo de cubrimiento
de pruebas! etc. Para cada herramienta indique la tarea para la que se usa! el
nombre de la herramienta! el ori"en 3.endedor o soft1are hecho en la
empresa4 y la .ersin.%
#. 'ecursos
[En esta seccin se presentan los recursos recomendados para el proyecto
[,ombre de proyecto%! sus principales responsabilidades y su conocimiento o
habilidades.%
#.1. 'oles
En la tabla a continuacin se muestra la composicin de personal para el
proyecto [,ombre del proyecto% en el (rea Verificacin del 5oft1are.
'ol Cantidad
m7nima de
recursos
recomendada
'esponsabilidades
2esponsable de
.erificacin
0dentifica! prioriza e implementa
los casos de prueba.
Lenera el Plan de
Verificacin.
Lenera el <odelo de
Prueba.
E.al@a el esfuerzo
necesario para .erificar.
Proporciona la direccin
tcnica.
$dquiere los recursos
apropiados.
Proporciona informes
sobre la .erificacin.
$sistente de
.erificacin
E-ecuta las pruebas
2e"istra los resultados de
las pruebas.
2ecuperar el soft1are de
Plan de Verificacin y Validacin P("ina )9 de )*
errores.
Documenta los pedidos
de cambio.
$dministrador de ;ase
de Datos
2ealiza la "estin y
mantenimiento del
entorno de los datos
3base de datos4 de
prueba y los recursos.
$dministra la base de
datos de prueba.
#.. 5istema
En la si"uiente tabla se establecen los recursos de sistema necesarios para
realizar la .erificacin.
[Es recomendable que el sistema simule el entorno de produccin! reduciendo
los accesos y los tama7os de bases de datos si fuera apropiado.%
[;orre o a"re"ue elementos a la lista%
'ecurso Nombre8)ipo
5er.idor de base de datos
2ed o subred
,ombre del ser.idor
,ombre de la base de datos
P liente para pruebas
2equerimientos especiales
2epositorio de pruebas
2ed o subred
,ombre del ser.idor
$. Hitos del proyecto de Verificacin
[La .erificacin del [,ombre de proyecto% debe incorporar acti.idades de
prueba para cada .erificacin identificada en las secciones anteriores. 5e
deben identificar los hitos del proyecto de .erificacin separados para
comunicar los lo"ros de estado de proyecto.%
"ctividad (ue determina
el 9ito
%sfuer.o *ec9a de
comien.o
*ec9a de
finali.acin
Planificar la .erificacin
Elaborar casos de prueba
$-uste y ontrol de
Verificacin
E-ecutar la .erificacin
E.aluar la .erificacin
[Las @ltimas tres acti.idades se repiten en cada iteracin. Deber#a incluir en
esta tablas los datos de todas las iteraciones del proyecto.%
,. %ntre&ables
[En esta seccin enumere los documentos! herramientas e informes que se
crear(n! por quien! para quien y cu(ndo ser(n liberados.
Plan de Verificacin y Validacin P("ina )= de )*
Para cada entre"able deber( indicar las fechas en que son liberadas todas las
.ersiones del mismo.%
,.1. :odelo de Casos de Prueba
Documento :odelo de Casos de Prueba
reado por El 2esponsable de .erificacin! [nombre del
responsable de .erificacin%.
Para quien Es la "u#a para realizar las pruebas del sistema y lo
usar(n los $sistentes de .erificacin y el 2esponsable
de .erificacin cuando se e-ecuten las pruebas del
sistema.
&echa de liberacin 5er( liberado el [fecha de primera liberacin%.
,.. Informes de Verificacin
Documento 5e "enera un documento Informe de Verificacin
+nitaria por cada prueba unitaria que se realice al
sistema.
reado por Las personas que e-ecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea de
.erificacin! que detalla los errores encontrados para
que puedan ser corre"idos.
&echa de liberacin 5er( liberado lue"o de cada .erificacin unitaria.
[0ndique la .ersin y la fecha de liberacin de todas
las .ersiones de este informe.%
Documento 5e "enera un documento Informe Consolidacin
por cada consolidacin que se realice al sistema.
reado por Las personas que e-ecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea de
consolidacin! que detalla los errores encontrados
para que puedan ser corre"idos.
&echa de liberacin 5er( liberado lue"o de cada consolidacin.
[0ndique la .ersin y la fecha de liberacin de todas
las .ersiones de este informe.%
Documento 5e "enera un documento Informe de Verificacin
de Inte&racin por cada prueba de inte"racin que
se realice al sistema.
reado por Las personas que e-ecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea de
.erificacin! que detalla los errores encontrados para
que puedan ser corre"idos.
&echa de liberacin 5er( liberado lue"o de cada .erificacin de
inte"racin. [0ndique la .ersin y la fecha de
liberacin de todas las .ersiones de este informe.%
Documento 5e "enera un documento Informe de Verificacin
de 5istema por cada prueba de sistema que se
realice.
reado por Las personas que e-ecutan las pruebas.
Plan de Verificacin y Validacin P("ina )> de )*
Para quien Es el retorno para los implementadores de la tarea de
.erificacin! que detalla los errores encontrados para
que puedan ser corre"idos.
&echa de liberacin 5er( liberado lue"o de cada .erificacin de sistema.
[0ndique la fecha de liberacin de este informe.%
,.!. %valuacin de la verificacin
Documento 5e "enera un documento %valuacin de la
verificacin por cada prueba que se realice al
sistema. Este documento contiene las fallas
encontradas en el sistema! la cobertura de la
.erificacin realizada y el estado del sistema.
reado por El 2esponsable de .erificacin! que toma como fuente
de su traba-o los 0nformes de .erificacin.
Para quien Es el resumen de la tarea de .erificacin y es el
retorno para todo el equipo de traba-o del estado del
sistema.
&echa de liberacin 5er( liberado lue"o de cada .erificacin! unitaria! de
inte"racin y de sistema.
[0ndique la .ersin y la fecha de liberacin de todas
las .ersiones de este informe.%
,.#. Informe final de verificacin
Documento El documento Informe final de verificacin es el
resumen de la .erificacin final del sistema antes de
que sea liberado al entorno del usuario.
reado por El 2esponsable de .erificacin! que toma como fuente
de su traba-o los 0nformes de .erificacin.
Para quien 0ndica el estado del sistema.
&echa de liberacin 5er( liberado lue"o de la .erificacin final del
sistema.
-. 6ependencias [opcional]
[En esta seccin se detallan las dependencias! si existen! de las acti.idades de
.erificacin respecto a otros elementos del sistema.%
-.1. 6ependencia de personal [opcional]
[En esta seccin se detallan las necesidades de personal para el equipo de
.erificacin! la cantidad y habilidades.%
-.. 6ependencia de soft;are [opcional]
[En esta seccin se detallan los requisitos que debe cumplir el soft1are a ser
.erificado para que se realice la .erificacin. Por e-emplo! que debe tener una
.erificacin pre.ia por parte del implementador! que debe estar en fecha
disponible para .erificar.%
-.!. 6ependencia de 9ard;are [opcional]
[En esta seccin se detallan las necesidades de disponibilidad de hard1are
para realizar las tareas de .erificacin. Por e-emplo! horario! cantidad de
horas que debe estar disponible para que las tareas de .erificacin se puedan
realizar dentro del crono"rama establecido.%
-.#. 6ependencia de datos y base de datos de prueba [opcional]
Plan de Verificacin y Validacin P("ina )B de )*
[En esta seccin se detallan las necesidades de disponibilidad de dato y de la
base de datos para realizar las tareas de .erificacin. Por e-emplo! con-untos
de datos necesarios para la .erificacin! horarios de acceso a la base de datos
que permitan que las tareas de .erificacin se puedan realizar dentro del
crono"rama establecido.%
3. 'ies&os [opcional]
[En esta seccin se detallan los ries"os detectados que puedan afectar la
normal realizacin de las tareas de .erificacin.%
3.1. Planificacin [opcional]
[En esta seccin se plantean los ries"os relati.os a la planificacin. Por
e-emplo! si una crono"rama es muy a-ustado un peque7o retraso en la
liberacin del soft1are para .erificar atrasa la .erificacin y por consi"uiente
las acti.idades que dependen de esta! pro.ocando un retraso en el
crono"rama de todo el proyecto.%
3.. )<cnico [opcional]
[En esta seccin se plantean los ries"os tcnicos que afectan a la .erificacin.
Por e-emplo! si existe un sistema anterior se deber( hacer una .erificacin en
paralelo con el anterior en lu"ar de liberar la .ersin en un punto de traba-o a
modo de prueba del sistema.%
3.!. =estin [opcional]
[En esta seccin se plantea como mediante la "estin se pueden miti"ar los
ries"os en las tareas de .erificacin.%
Plan de Verificacin y Validacin P("ina )F de )*
4. "p<ndice
4.1. Niveles de &ravedad de error
En muchas acti.idades del proceso de .erificacin se deben clasificar los
errores se"@n su ni.el de "ra.edad. 5e asi"na un ni.el de "ra.edad a los
errores para poder capturar de al"una manera su impacto en el sistema.
$dem(s para poder e.aluar la .erificacin y el sistema.
$ continuacin se da una su"erencia de cuatro ni.eles diferentes de "ra.edad
de error/
Catastrfico/ un error cuya presencia impide el uso del sistema.
Cr7tico/ un error cuya presencia causa la prdida de una funcionalidad
cr#tica del sistema. 5i no se corri"e el sistema no satisfar( las
necesidades del cliente.
:ar&inal/ un error que causa un da7o menor! produciendo prdida de
efecti.idad! prdida de disponibilidad o de"radacin de una
funcionalidad que no se realiza f(cilmente de otra manera.
:enor/ un error que no causa per-uicio al sistema! pero que requiere
mantenimiento o reparacin. ,o causa prdida de funcionalidades que
no se puedan realizar de otra manera.
4.. Niveles de aceptacin para lo elementos verificados
[5e debe establecer un ni.el de aceptacin para los elementos .erificados
para poder establecer el estado en el que se encuentra el proyecto.
En esta seccin defina ni.eles de aceptacin y los criterios de pertenencia a
cada ni.el.
omo e-emplo de ni.eles de aceptacin/
No aprobado/ el elemento .erificado tiene errores catastrficos 3uno
o .arios4 que impiden su uso o tiene errores cr#ticos 3uno o .arios4 que
hacen que el elemento .erificado no sea confiable. El usuario no puede
depender de l para realizar el traba-o.
"probado con >bservaciones/ el elemento .erificado no tiene
errores catastrficos! ni errores cr#ticos! pero tiene errores mar"inales
3uno o .arios4 que hacen que el elemento de soft1are se de"rade en
al"unas situaciones.
"probado/ el elemento .erificado no tiene errores o tiene errores
menores que no afectan el normal funcionamiento del elemento.%
Plan de Verificacin y Validacin P("ina )* de )*