Plan de Verificación y Validación

Sistema de Gestión de Becas
Plan de Verificación y Validación

Versión [1.0]
Historia de revisiones
Fecha Versión Descripción Autor
01/06/2018 1.1 Primera versión Santiago Mancebo
03/06/2018 1.2 Agustín Araujo
05/06/2018 1.3 Agregada estrategia de Agustín Araujo
verificación
06/06/2018 1.4 Agregado requerimientos a Santiago Mancebo
verificar
10/06/2018 1.5 Agregado tipo de pruebas Agustín Araujo
10/06/2018 1.5 Agregado roles Santiago Mancebo
16/06/2018 1.6 Versión Final Agustín Araujo
Santiago Mancebo
Plan de verificación y validación - Página 1 de 21

Índice de contenido
1.INTRODUCCIÓN 3
1.1.Propósito 3
1.2.Punto de partida 4
1.3.Alcance 4
1.4.Identificación del proyecto 5
1.5.Estrategia de evolución del Plan 5
2.REQUERIMIENTOS PARA VERIFICAR 6
3.ESTRATEGIA DE VERIFICACIÓN 7
3.1.Tipos de pruebas 7
3.1.1.Prueba de Funcionalidad 7
3.1.2.Prueba de Ciclo del Negocio 8
3.1.3.Prueba de Interfase de Usuario 8
3.1.4.Prueba de Performance 9
3.1.5.Prueba de Carga 9
3.1.6.Prueba de Esfuerzo (stress, competencia por recursos, bajos recursos) 10
3.1.7.Prueba de Volumen 10
3.1.8.Prueba de Seguridad y Control de Acceso 11
3.1.9.Prueba de Configuración 12
3.1.10.Prueba de Instalación 12
3.1.11.Prueba de Documentos 13
3.2.Herramientas 14
4.RECURSOS 15
4.1.Roles 15
4.2.Sistema 16
5.HITOS DEL PROYECTO DE VERIFICACIÓN 17
6.ENTREGABLES 19
6.1.Modelo de Casos de Prueba 19
6.2.Informes de Verificación 19
6.3.Evaluación de la verificación 20
6.4.Informe final de verificación 20
7.APÉNDICE 21
7.1.Niveles de gravedad de error 21
7.2.Niveles de aceptación para lo elementos verificados 21

1. Introducción
1.1 Propósito
Este Plan de Verificación para el proyecto “Sistema de gestión de becas” soporta los
siguientes objetivos:
El proyecto consiste en el desarrollo de dos aplicaciones como se describe en el
documento “Plan de Proyecto”, las cuales deberán ser verificadas. En el caso de la
aplicación para uso del MEC, la misma consta de módulos por lo cual se deberán realizar
pruebas de integración de los mismos, además de las pruebas de cada módulo.
En términos generales los requisitos que se recomiendan verificar son los siguientes:
● Registro y acceso al sistema por parte de los estudiantes.
● Acceso a información, postulación y aceptación de becas por parte de los estudiantes.
● Ayuda al usuario.
● Creación de becas con su información correspondiente y gestión de listados de
postulantes, adjudicados y suplentes por parte de los funcionarios del MEC.
● Funcionamiento y posible actualización del algoritmo de rankeo IABE.
● Acceso y modificación de listados por parte de las comisiones departamentales.
● Reportes de información relativa a los postulantes.
● Alertas tanto para estudiantes como para funcionarios.
Para las pruebas unitarias se usará una combinación de estrategias de verificación

estáticas y dinámicas:
● Estáticas (analíticas): Consisten en revisar el código sin ejecutarlo y son efectivas en
la detección temprana de defectos.
● Dinámicas (pruebas): Consisten en ejecutar el código, consideran el ambiente en que
el software será utilizado y sirven para verificar y validar características más allá de la
funcionalidad.
Dentro de las técnicas dinámicas se distinguen las técnicas de caja negra y caja blanca:
● Caja Negra: Consiste en ingresar una entrada y contrastar la salida obtenida con la
salida deseada sin disponer del código. Son pruebas que derivan sólo de la
especificación y permiten detectar errores respecto a la misma.
● Caja Blanca: Consiste en identificar casos de prueba de interés a partir del código,
teniendo en cuenta características de la implementación. Se recomienda realizarlas
luego de aplicada la técnica de Caja Negra ya que esta última implica cambios en el
código cuando se detectan errores.
Los recursos necesarios para llevar a cabo este plan de verificación y validación serán:
● Equipo de desarrollo: Llevará a cabo las pruebas unitarias y de integración de
módulos, aportando su conocimiento del desarrollo del producto.
● Equipo de verificación: Llevará a cabo las pruebas restantes, aportando su
imparcialidad respecto al producto desarrollado y una visión externa.
● Equipo especializado: Llevará a cabo la verificación de requisitos no funcionales,
aportando conocimientos específicos sobre dicha tarea.
● Servidores: Serán necesarios servidores específicos para las tareas de verificación, y
los mismos deberán ser distintos de aquellos servidores utilizados para el desarrollo.
● Capital: Tanto la adquisición de servidores como las horas de trabajo de los distintos
equipos implicarán costos importantes para el presupuesto del proyecto.

1.2 Punto de partida
El sistema a verificar es un sistema de gestión de becas para estudiantes; el mismo fue
postulado por el Ministerio de Educación y Cultura al programa eFondos que administra
AGESIC. El objetivo del software es facilitar el acceso y la comunicación entre los
postulantes a las becas y el MEC, así como optimizar todas las tareas relacionadas a la
gestión de las mismas.
El sistema consta de dos aplicaciones, y una de ellas consta de 5 módulos:
● Gestión de becas para estudiantes
● Gestión de becas
■ Módulo algoritmo para ranking de becas IABE
■ Módulo Gestión de Becas
■ Módulo comisión departamental
■ Módulo alertas
■ Módulo de reportes
El objetivo del plan es identificar de manera temprana el mayor número de defectos y así
poder entregar al cliente un producto acorde a sus especificaciones y que cumpla con sus
necesidades. También es importante para evitar los retrabajos que se puedan ocasionar
durante el proyecto.
1.3 Alcance
Durante el proceso de verificación y validación se realizarán pruebas unitarias, de
integración, funcionales, de desempeño, de aceptación e instalación:
Las pruebas unitarias serán responsabilidad del equipo de desarrollo, el cual deberá
realizar análisis de código y casos de prueba básicos en cada una de las liberaciones.
También será su responsabilidad la correcta documentación de los defectos relevantes
que fueron encontrados y su respectiva solución.
Las pruebas de integración también son responsabilidad del equipo de desarrollo. Estas
pruebas son fundamentales debido al proceso de desarrollo con liberaciones
seleccionado; el equipo debe conseguir que las liberaciones trabajen correctamente de
forma conjunta. Se debe realizar una correcta documentación de las integraciones
realizadas.
Las pruebas de función son responsabilidad del equipo de verificación. Las mismas deben
realizarse tomando como referencia el “Documento de especificación de requisitos” ya
presentado. Se utilizará el método de casos de uso para relevar los requisitos.
Las pruebas de desempeño son responsabilidad de un equipo especializado, las mismas

deben realizarse sobre todos los requerimientos no funcionales detectados y registrados
en el documento de requisitos. Se debe documentar para cada requisito el resultado
obtenido al aplicar algunas de las pruebas de desempeño.
La prueba de aceptación se realiza bajo supervisión del cliente, aquí el cliente debe
verificar que el sistema funciona de acuerdo a los requerimientos establecidos. Esta
prueba debe efectuarse en ambiente de producción. Se debe contar con documentación
que refleje la aceptación o no por parte del cliente.

Las pruebas de instalación serán realizadas por el equipo de desarrollo. Se pretende
corroborar la existencia de errores en la instalación del software. La prueba es realizada
en ambiente de producción y se debe documentar, en conformidad con el cliente, cual es
el resultado de la misma.
Una restricción importante del proyecto es el plazo de entrega, el cual puede afectar
directamente la calidad de las pruebas de verificación y/o validación, o incluso poner en
riesgo la implementación de las mismas.
Existe el riesgo de no poder verificar todos los requerimientos no funcionales en tiempo y

forma, ya que se hizo énfasis en los mismos en el momento de relevar y resultaron ser
de variadas características.
1.4 Identificación del proyecto

Los documentos usados para elaborar el Plan de Verificación son los siguientes:
1. Plan de proyecto
2. Plan de implementación
3. Documento de especificación de requisitos
1.5 Estrategia de evolución del Plan

El responsable de monitorear el Plan de Verificación y Validación será quien ocupe el
puesto de “Responsable de verificación”. Dicho puesto y su posición en la jerarquía
interna del proyecto se puede observar en el ítem 2.2 “Estructura Organizacional” del
documento “Plan de Proyecto”.
Las modificaciones al Plan de Verificación se realizarán cada vez que se finalice la

verificación y validación de una liberación, en tanto a medida que se verifican
componentes del sistema surgen cambios a realizar en el mismo. Se debe recordar que
para cada liberación se sigue un modelo V de desarrollo, por lo cual se irán encontrando
cambios a realizar a lo largo de todo proceso, los cuales deberán ser debidamente
documentados para cuando llegue el momento de modificar el plan.
Los cambios al plan serán evaluados por el Responsable de verificación, quien deberá
tomar en cuenta toda la información recibida por parte de los distintos equipos de
verificación, y a su vez deberá informar los cambios que considere apropiado realizar al
Administrador de Proyecto para su aprobación.
Los cambios se llevarán a cabo actualizando este documento, y serán comunicados vía
mail a aquellos miembros del proyecto cuyo trabajo se vea afectado por los mismos.

2. Requerimientos para verificar
En la lista a continuación se presentan los elementos, casos de uso, requerimientos

funcionales y requerimientos no funcionales, que serán verificados.
Los requisitos funcionales de las aplicaciones del sistema cuya verificación resulta de
prioridad para el cliente son los siguientes:
Aplicación “Gestión de Becas para Estudiantes”
● Registro de usuario
● Modificación de datos
● Ingreso al sistema
● Solicitud de nueva clave de acceso
● Ver información de becas
● Postulación a beca
● Visualización de estado
● Aceptación de becas
● Asignación de punto de cobro
● Ayuda en línea
● FAQ
● El MEC recibe las consultas vía formulario
Aplicación “Gestión de becas”
● Creación de una beca
● Cambiar el estado de un becario
● Modificación de la lista de suplentes y de la lista de adjudicados
● Visualizar información de una beca y de un becario
● Obtención del ranking correcto a partir de una lista de postulantes y sus datos
● Actualización del ranking a partir de modificaciones en datos de postulantes
● Actualización manual del ranking
● Generación de listados de titulares y suplentes pertenecientes a un departamento
● Acceso y modificación de listados por parte de usuarios de comisión departamental
● Alertas para estudiantes y funcionarios
● Generación de reportes de información de postulantes
Los requisitos no funcionales a verificar son:

● “Gestión de becas para estudiantes” ocupa menos de 10 megabytes en su versión móvil
● El sistema funciona correctamente con 10000 usuarios con sesión iniciada
● 100% de la información obtenida en una jornada se respalda en la base de datos
● Al realizar una modificación de listados la misma es visualizada en menos de 3
segundos
● Las funcionalidades del sistema no duran más de 5 segundos en ejecutarse
● Las FAQ evacúan al menos el 90% de las dudas de los usuarios
● La probabilidad de falla del sistema es menos o igual a 0,1%
● Descarga e instalación de la app para estudiantes en distintos sistemas operativos (iOS,
Android)
● Acceso a “Gestión de becas” denegado desde servidores fuera del lugar de trabajo

3. Estrategia de Verificación
A continuación, se describe toda la información referida a la realización de las pruebas,

antes mencionadas, durante el plan. Se establecerá las técnicas que se usarán y los
criterios de aceptación de cada prueba. En caso de no llevarse a cabo una prueba se
justificará la decisión.
3.1 Tipos de pruebas
3.1.1. Prueba de Funcionalidad

La prueba de funcionalidad se enfoca en requerimientos para verificar que se
corresponden directamente a casos de usos o funcionalidades de las aplicaciones. Los
objetivos de estas pruebas son verificar la aceptación de los datos, el proceso, la
recuperación y la implementación correcta de las aplicaciones. Este tipo de prueba se
basa en técnicas de caja negra, que consisten en verificar la aplicación y sus procesos
interactuando con la aplicación por medio de la interface de usuario y analizar los
resultados obtenidos.
3.1.1.1. Objetivo de la prueba
El objetivo de la prueba es la verificación de que el sistema ya integrado realiza las
funciones especificadas en el documento de especificación de requisitos. Esto incluye la
navegación, entrada de datos, procesos y recuperación de todos los datos pertinentes a
las aplicaciones de gestión de becas.
3.1.1.2. Técnica
En primer lugar, se divide el dominio de entrada a cada función en clases de
equivalencia. Las clases de equivalencia son conjuntos de elementos que se comportan
de “igual” forma en el sistema, por lo cual basta con tomar un elemento de cada clase
para considerar que se ha probado la totalidad de los elementos.
Luego se utilizará la técnica de casos de uso donde se reconocen los escenarios posibles
y se usan como base para las condiciones de prueba, que luego son utilizados para crear
los casos de prueba. En los casos de prueba se utilizarán datos válidos y no válidos y se
comparará la salida con el resultado esperado para cada dato de entrada; en caso de
datos no válidos o falta de algún dato relevante se prueba si el mensaje de error se
despliega y si es el correcto.
3.1.1.3. Criterio de aceptación
Se considera que la prueba se completó exitosamente cuando realizaron todos los casos
de uso planificados y se han identificado la causa de todos los defectos encontrados.
3.1.1.4. Consideraciones especiales
Dentro de las posibilidades se realizarán pruebas que sean automáticas.
3.1.2. Prueba de Ciclo del Negocio

Las pruebas de ciclo de negocio deberían emular las actividades ejecutadas en él a través
del tiempo. Debería identificarse un periodo, como por ejemplo un año, y las
transacciones y actividades que podrían ocurrir durante un periodo de un año deberían
ejecutarse. Incluyendo todos los ciclos y eventos diarios, semanales y mensuales que
sean datos sensitivos.

Asegurar que las aplicaciones funcionan de acuerdo a los requerimientos del negocio.
3.1.2.2. Técnica
La prueba debe simular ciclos de negocios realizando lo siguiente:
● Incrementando el número de veces en que una función es ejecutada para simular
diferentes usuarios sobre un periodo especificado.
● Todas las fechas o funciones que involucren tiempos serán probadas con datos válidos e
inválidos de fechas o periodos de tiempo.
● Todas las funciones que ocurren en un periodo de tiempo serán ejecutadas en el tiempo
apropiado.
● Cada regla de negocio es aplicada adecuadamente.
● Las pruebas de funcionalidad se deben modificar para aumentar la cantidad de veces
que se ejecuta cada función, simulando varios usuarios diferentes en un período
determinado.
● Para cada prueba realizada verificar lo siguiente:
➔ Se obtienen los resultados esperados cuando se usan datos válidos.
➔ Cuando se usan datos no válidos se despliegan los mensajes de error o
advertencia apropiados.
➔ Se aplica apropiadamente cada regla del negocio
Todas las pruebas planeadas han sido ejecutadas, todos los defectos que se identificaron
han sido resueltos.
Las fechas del sistema y eventos requieren actividades de soporte especiales. Esto es,
poder cambiar la fecha y hora del reloj de servidor donde correrá el sistema.
3.1.3. Prueba de Interface de Usuario

Esta prueba pretende identificar si la interfaz de usuario ha sido ajustada correctamente
para el público objetivo de cada aplicación, estudiante y funcionarios de los centros
administradores. Estas pruebas se debe prestar especial atención ya que de no ser
realizadas correctamente el programa puede ser inutilizable.
Verificar que las navegaciones a través de las aplicaciones desarrolladas demuestran una
facilidad de uso para el usuario. Principalmente comprobar que para los estudiantes el
sistema refleja la información y características (menúes, tamaño, posición y demás)
necesaria para una correcta postulación minimizando la necesidad de ayuda en línea.
3.1.3.2. Técnica
Se realizarán prototipos durante el desarrollo que se someterán a prueba de sus usuarios
objetivos (estudiante y funcionarios según el caso) y se evaluaran las consideraciones de
los mismos respecto a la interfaz probada. A partir de esto se realizarán las
modificaciones de los elementos de la interfaz para un mejor resultado. El proceso será
continuo hasta obtener un resultado considerado adecuado.
Se han obtenidos resultados satisfactorios en los prototipos, cada característica
identificada como a mejorar inicialmente, se verificó exitosamente.

Tener en cuentas consideraciones relevantes al propósito de la aplicación al momento de
relevar los resultados de los prototipos.
3.1.4. Prueba de Performance

Esta prueba es utilizada para evaluar los requerimientos sensibles al tiempo, como son
tiempos de respuesta y tiempos máximos de ejecución del sistema.
El objetivo de la prueba es enfocado esencialmente sobre los requisitos no funcional
llamados 1 y 2 en el documento de requerimientos. Se va a corroborar que
efectivamente los tiempos plasmados en dichos requisitos son alcanzados por el sistema;
y en caso contrario cuáles tiempos maneja el sistema realmente.
3.1.4.2. Técnica
Se generan casos de prueba para mostrar cuales son los tiempos de respuesta y
de ejecución del sistema. Los casos de prueba deben incluir situaciones con un número
elevado de transacciones o iteraciones por parte de los usuarios, además la misma debe
ser ejecutada desde todos los roles creados.
Se documentará de manera clara los resultados que se obtuvieron y bajo qué
condiciones de funcionamiento.
Se considerará exitosa cuando se hayan ejecutado todos los casos de prueba desde todos
los roles aplicables al caso, y el resultado de las pruebas se encuentren dentro de los
parámetros documentados en los requisitos no funcionales.
Se debe dejar registro bajo qué condiciones de carga se ejecutó cada prueba y en que
configuración del sistema.
3.1.5. Prueba de Carga

La prueba de carga somete los objetos a verificar a diferentes cargas de trabajo para
medir y evaluar los comportamientos de performance y la habilidad de los objetos de
continuar funcionando apropiadamente bajo diferentes cargas de trabajo.
El objetivo es determinar y asegurar que el sistema funciona apropiadamente en
circunstancias de máxima carga de trabajo esperada. Además, evaluar las características
de performance, como tiempos de respuesta, tiempos de transacciones y otros
elementos sensitivos al tiempo.
En este caso consiste en verificar el comportamiento de performance de los módulos bajo
distintas condiciones de trabajo, como puede ser variar la cantidad de usuarios en línea,
la cantidad de becas disponibles o la cantidad de postulantes a una misma beca.
3.1.5.2. Técnica
Se utilizarán las pruebas desarrolladas para funciones o ciclos de negocios ya
mencionadas y se modificarán archivos de datos para aumentar el número de usuarios y
becas como se mencionó anteriormente.

Para los valores límite establecidos en los requisitos no funcionales, el criterio de
aceptación consiste en realizar todas las operaciones con éxito y dentro de los límites de
tiempo estipulados.
La prueba de carga 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 tamaño similar a las reales.
3.1.6. Prueba de Esfuerzo (stress, competencia por recursos, bajos recursos)

La prueba de esfuerzo es un tipo de prueba de desempeño que implica someter al
sistema a esfuerzos considerables en un lapso corto de tiempo. Se pretende encontrar
aquellas características que limiten el funcionamiento correcto del sistema bajo
condiciones exigentes. La prueba de esfuerzo también puede usarse para identificar el
trabajo máximo que el software puede manejar.
Verificar que el software funciona apropiadamente y sin error bajo condiciones de
esfuerzo, como son:
● poca memoria o sin disponibilidad de memoria en el servidor
● cantidad máxima de usuarios conectados
● múltiples usuarios realizando la misma operación sobre los mismos datos
● peor caso de volumen de operaciones.
El objetivo de la prueba de esfuerzo es también identificar y documentar las condiciones
bajo las cuales el sistema falla y no continúa funcionando apropiadamente
3.1.6.2. Técnica
La técnica usada es similar a la de las anteriores dos pruebas, aquí se debe simular los
casos donde se den picos de uso como son etapas de inscripciones a becas, aprobación
de becas, envíos de formularios, consultas y demás, en cortos periodos de tiempo.
Luego se debe analizar la respuesta del sistema a estas situaciones corroborando si los
resultados son satisfactorios y documentando los mismos.
Todas las pruebas planeadas se ejecutaron y se alcanzaron o excedieron los límites del
sistema sin que el software fallara o las condiciones bajo las que ocurre una falla en el
software están fuera de las condiciones especificadas
Se debe considerar la eficiencia de los métodos para simular las situaciones de estrés, se
elegirán aquellos métodos que demuestren realizar las simulaciones planteadas de forma
adecuada al software.
3.1.7. Prueba de Volumen

La prueba de volumen implica someter a el software a grandes cantidades de datos para
determinar si se alcanzan límites que causen la falla del software. La prueba de volumen
identifica la carga máxima continua que puede manejar el software, aquí no se evalúan
picos de datos en cortos periodos de tiempo.

El objetivo de la prueba es verificar que es software funciona correctamente cuando es
sometidos a volúmenes de datos grandes de forma continua. Se estará bajo simulaciones
continuas de número de usuarios conectados y realizando la misma operación.
3.1.7.2. Técnica
Se pretende evaluar que para un volumen mayor al estimado de operación continua
normal el software funciona sin falla, para esto se utilizarán volúmenes operativos hasta
encontrar aquel para que el sistema no lo pueda manejar sin perder performance. Este
nivel es el máximo que el sistema puede operar bajo esas condiciones.
Para realizar la prueba se debe simular grandes volúmenes de operación, se
documentarán los resultados de las pruebas y bajo qué volúmenes fueron realizadas.
Siempre que el volumen encontrado como máximo que soporta el software en la prueba
sea mayor al volumen máximo estimado de operación normal la prueba se considerará
exitosa.
Especificar previamente a la prueba que tiempo es considerado aceptable para realizar la
prueba de volumen.
3.1.8. Prueba de Seguridad y Control de Acceso

La Prueba de Seguridad y Control de Acceso se enfoca en dos áreas de seguridad:
1. Seguridad en el ámbito de aplicación, incluyendo el acceso a los datos de los
usuarios y a las funcionalidades de las aplicaciones.
2. Seguridad en el ámbito de sistema, incluyendo conexión, o acceso remoto al
sistema.
La seguridad en el ámbito de aplicación asegura que, basado en la seguridad deseada los
actores están restringidos a funciones o casos de uso específicos o limitados en los datos
que están disponibles para ellos.
La seguridad en el ámbito de sistema asegura que, solo los usuarios con derecho a
acceder al sistema son capaces de acceder a las aplicaciones y solo a través de los
puntos de ingresos apropiados.
Verificar que los usuarios solo puedan acceder a las funcionalidades o datos para los
cuales su tipo de rol tiene permiso y verificar que nadie externo al sistema pueda acceder
a ellos.
3.1.8.2. Técnica
Se debe generar casos de pruebas que tengan potencial de burlar los controles de
seguridad del sistema. Para realizar los mismos se pueden estudiar problemas conocidos
de seguridad en sistemas similares. Estos casos de prueba deben contemplar las dos
áreas de seguridad antes mencionadas.
Se debe identificar los diferentes tipos de usuarios y analizar a qué funcionalidades y
datos se puede acceder, luego comparar con aquellas funcionalidades y datos a los
cuales dicho usuario debería acceder, continuar la prueba para los diferentes tipos de
usuario corroborando que los permisos permanecen inalterados. Lo mismo se debe
realizar para actores externos al sistema.

Se corrobora y documenta que cada usuario tiene disponible todas las funcionalidades y
datos que debe tener y no disponibles ninguna de aquellas funcionalidades o datos que
no debe tener acceso. También que ningún actor externo tiene acceso a información o
funcionalidades que no debe tener.
Mientras las pruebas son ejecutadas y las fallas todavía no son resueltas se debe
mantener total hermetismo sobre dicha información y procurar medidas de seguridad
para evitar que se explote la falla de seguridad encontrada.
3.1.9. Prueba de Configuración

La prueba de configuración verifica el funcionamiento del software con diferentes
configuraciones de software y hardware.
Verificar que el software funcione apropiadamente en las configuraciones requeridas de
hardware y software. Haciendo énfasis en la aplicación para el estudiante que tendrá
mayor variabilidad de dispositivos de uso.
3.1.9.2. Técnica
Ejecutar funcionalidades desde varios dispositivos de la aplicación para el estudiante,
corroborando que no pierde características que ocasione que no se cumpla
satisfactoriamente con alguna de las pruebas aquí mencionadas. (Recordar que la única
manera de acceder a la aplicación gestión de becas era desde computadoras ubicadas en
el lugar de trabajo de los funcionarios)
Tanto como para la aplicación del estudiante como para la de gestión de becas, se debe
abrir y cerrar varias sesiones de otras aplicaciones que no son objeto de prueba, como
parte de la prueba o antes de comenzar la prueba. Ejecutar operaciones seleccionadas
para simular la interacción de los usuarios con las aplicaciones de interés y con otras
aplicaciones o software.
Todas las operaciones son completadas exitosamente sin fallas.
3.1.10. Prueba de Instalación

La Prueba de Instalación tiene dos propósitos. Uno es asegurar que el software puede ser
instalado en diferentes condiciones (como una nueva instalación, una actualización, y
una instalación completa o personalizada) bajo condiciones normales y anormales. El
otro propósito es verificar que, una vez instalado, el software opera correctamente.
Mostrar que se cumple con unos de los requerimientos establecidos por el cliente donde
establece que las aplicaciones deben ser fácilmente distribuible y accesible en todo el
territorio nacional.
3.1.10.2. Técnica

Para la aplicación de estudiante para smartphones o tablets se realizarán instalaciones en
diferentes configuraciones de software y hardware de estos dispositivos, principalmente
enfocándonos en aquellos de menores prestaciones.
Para las aplicaciones web se deben realizar pruebas sobre la instalación de la aplicación
web en los servidores, hay que corroborar que la configuración del servidor sea la
correcta para la instalación de la aplicación web, luego instalarla y realizar casos de
prueba para verificar su correcto funcionamiento.
Ambas aplicaciones funcionan correctamente sin fallas en todas las configuraciones de
software y hardware probadas.
3.1.11. Prueba de Documentos

La Prueba de Documentos debe asegurar que los documentos relacionados al software
que se generen en el proceso sean correctos, consistentes y entendible.
Evaluar la documentación que se le va a entregar a los usuarios. Se debe verificar que
los documentos sean:
● Correctos, que cumplan con el formato y organización para el documento
establecido en el proyecto.
● Consistentes, que el contenido del documento sea fiel a lo que hace referencia. Si
el documento es Documentación de Usuario, que la explicación de un
procedimiento sea exactamente como se realiza el procedimiento en el software,
si se muestran pantallas que sean las correctas.
● Entendibles, que al leer los documentos se entienda correctamente lo que expresa
y sin ambigüedades, además que sea fácil de leer.
Esta prueba pretende corroborar que se cumple con unos de los requerimientos del
cliente en cuando a una documentación exhaustiva y una gestión del conocimiento
adecuada, para evitar grandes impactos en la transferencia del sistema.
3.1.11.2. Técnica
Para verificar que el documento es correcto se debe comparar con el estándar definido si
existe o con las pautas de documentación y ver que el documento cumple con ellas.
Para verificar que el documento es Consistente se debe ejecutar el programa siguiendo el
documento y comprobar que lo que se explica en estos documentos es exactamente lo
que se ejecuta en el programa.
Para verificar que el documento es entendible, debe comprobar que se entiende
correctamente, que no tiene ambigüedades y que sea fácil de leer.
El documento expresa exactamente lo que debe expresar, no hay diferencias entre lo que
está escrito y el objeto de la descripción (operación de software, código de programa,
decisiones técnicas) y se entiende fácilmente.
Quien corrobore si los documentos son correctos y consistentes debe ser una persona
competente involucrada en el desarrollo del software. En el caso de si el documento es
entendible se puede realizar en conjunto con el cliente, corroborando que a este le
resulta fácil de leer y entender.

3.2. Herramientas
Herramienta Tarea
Google Drive Almacenamiento de documentación

generada a partir de pruebas
Correo electrónico Comunicación entre los involucrados en el

plan
Sistema de mensajería instantánea Comunicación instantánea entre los

involucrados en el plan
Generador de altas carga de información Pruebas de volumen
Simulador de usuarios concurrentes Pruebas de esfuerzo
Simulador de escenarios de software y Pruebas de configuración

hardware

4. Recursos
En esta sección se presentan los recursos recomendados para el proyecto “Sistema de

gestión de becas”, sus principales responsabilidades y su conocimiento o habilidades.
4.1. Roles
En la tabla a continuación se muestra la composición de personal para el proyecto
“Sistema de gestión de becas” en el área Verificación del Software.
Rol Cantidad Responsabilidades
mínima de
recursos
recomendada
Responsable de verificación 1 Identifica, prioriza e
implementa los casos de
prueba.
Genera el Plan de
Verificación.
Genera el Modelo de
Prueba.
Evalúa el esfuerzo
necesario para verificar.
Proporciona la dirección
técnica.
Adquiere los recursos
apropiados.
Proporciona informes
sobre la verificación.
Asistente de verificación 5 Ejecuta las pruebas.
Registra los resultados
de las pruebas.
Recuperar el software de
errores.
Documenta los pedidos
de cambio.
Integra el “Equipo de
verificación”
Desarrollador 5 Luego de participar en el
desarrollo del producto, realiza
las pruebas unitarias y de
integración de módulos como
parte del “Equipo de
desarrollo”.
Administrador de Base de 2 Realiza la gestión y
Datos mantenimiento del entorno de
los datos (base de datos) de
prueba y los recursos.
Administra la base de

datos de prueba.
Especialista en pruebas de 5 Realiza las pruebas
requisitos no funcionales correspondientes a los
(externo al proyecto) requisitos no funcionales.
Integra el “Equipo
especializado”
Estudiantes 2 Valida el software para
estudiantes
Funcionarios MEC 2 Valida el software para el MEC
Miembros del Comité de 5 Recibe las solicitudes de
Control de Cambios cambios, analiza el impacto de
los mismos e implementa
aquellos que sean pertinentes.
Documenta todas las
actividades anteriores.
4.2. Sistema
En la siguiente tabla se establecen los recursos de sistema necesarios para realizar la
verificación.
Para el uso por parte de estudiantes se consideran dispositivos que llevan algunos años
en el mercado para asegurar que se represente la realidad de los dispositivos que serán
usados.
Recurso Nombre/Tipo
Servidor de base de datos Microsoft SQL Server 2017
PC MEC para pruebas PC del MEC con acceso a internet
PC usuario estudiante HP Pavilion
Dispositivo android Samsung Galaxy S4
Dispositivo iOS iPhone 5S

5. Hitos del proyecto de Verificación
La verificación del “Sistema de gestión de becas” debe incorporar actividades de prueba
para cada verificación identificada en las secciones anteriores. Se deben identificar los
hitos del proyecto de verificación separados para comunicar los logros de estado de
proyecto.
Se consideran los roles ya determinados con jornadas de trabajo de 8 horas de lunes a
viernes, y se mide el esfuerzo de cada actividad en cantidad de horas de trabajo por
parte de las personas que desempeñan los roles ya mencionados.
La primera liberación es la que abarca más funcionalidades del sistema por lo cual se
estima un esfuerzo mayor para su verificación.
Liberación 1:
Actividad que determina el hito Esfuerzo Fecha de Fecha de
(Horas de comienzo finalización
trabajo)
Planificar la verificación 24 06/06/2018 08/06/2018
Elaborar casos de prueba 80 11/06/2018 22/06/2018
Pruebas unitarias 56 25/06/2018 27/06/2018
Ajuste y Control de Verificación 240 28/06/2018 05/07/2018
Ejecutar la verificación 240 06/07/2018 11/07/2018
Evaluar la verificación 40 12/07/2018 13/07/2018
Pruebas de integración 80 16/07/2018 18/07/2018
Ajuste y Control de Verificación de 240 19/07/2018 25/07/2018
integración
Ejecutar la verificación de integración 240 26/07/2018 31/07/2018
Evaluar la verificación de integración 40 01/08/2018 02/08/2018
Liberación 2:
trabajo)
integración
Ejecutar la verificación de 120 03/09/2018 06/09/2018
integración

Liberación 3:
trabajo)
integración
integración
Liberación 4:
trabajo)
integración
integración

6. Entregables
6.1. Modelo de Casos de Prueba

Documento Modelo de Casos de Prueba
Creado por El Responsable de verificación, rol que será asignado
por el gestor del proyecto.
Para quién Es la guía para realizar las pruebas del sistema y lo
usarán los equipos de verificación y desarrollo cuando
se ejecuten las pruebas del sistema.
Fecha de liberación Será liberada una versión nueva en cada liberación, en
las fechas correspondientes a la actividad “Elaborar
casos de prueba” indicadas en los hitos de verificación.
6.2. Informes de Verificación

Documento Se genera un documento Informe de Verificación
Unitaria por cada prueba unitaria que se realice al
sistema.
Creado por Las personas que ejecutan las pruebas.
Para quién Es el retorno para los implementadores de la tarea de
verificación, que detalla los errores encontrados para
que puedan ser corregidos.
las fechas correspondientes a la actividad “Pruebas
unitarias” indicadas en los hitos de verificación.
Documento Se genera un documento Informe de Verificación

de Integración por cada prueba de integración que
se realice al sistema.
Creado por Las personas que ejecutan las pruebas.
Para quién Es el retorno para los implementadores de la tarea de
verificación, que detalla los errores encontrados en la
integración de módulos para que puedan ser
corregidos.
las fechas correspondientes a la actividad “Ejecutar la
verificación de integración” indicadas en los hitos de
verificación.

6.3. Evaluación de la verificación
Documento Se genera un documento Evaluación de la
verificación por cada prueba que se realice al
sistema. Este documento contiene las fallas
encontradas en el sistema, la cobertura de la
verificación realizada y el estado del sistema.
Creado por El Responsable de verificación, que toma como fuente
de su trabajo los Informes de verificación.
Para quién Es el resumen de la tarea de verificación y es el
retorno para todo el equipo de trabajo del estado del
sistema.
las fechas correspondientes a la actividad “Evaluar la
verificación de integración” de acuerdo a los hitos de
verificación.
6.4. Informe final de verificación

Documento El documento Informe final de verificación es el
resumen de la verificación final del sistema antes de
que sea liberado al entorno del usuario.
Creado por El Responsable de verificación, que toma como fuente
de su trabajo los Informes de verificación.
Para quién Indica el estado del sistema.
Fecha de liberación Será liberado luego de la verificación final del sistema.
7. Apéndice
7.1. Niveles de gravedad de error

En muchas actividades del proceso de verificación se deben clasificar los errores según su
nivel de gravedad. Se asigna un nivel de gravedad a los errores para poder capturar de
alguna manera su impacto en el sistema. Además para poder evaluar la verificación y el
sistema.
A continuación se da una sugerencia de cuatro niveles diferentes de gravedad de error:
Catastrófico: un error cuya presencia impide el uso del sistema.
Crítico: un error cuya presencia causa la pérdida de una funcionalidad crítica
del sistema. Si no se corrige el sistema no satisfará las necesidades del
cliente.
Marginal: un error que causa un daño menor, produciendo pérdida de
efectividad, pérdida de disponibilidad o degradación de una funcionalidad que
no se realiza fácilmente de otra manera.
Menor: un error que no causa perjuicio al sistema, pero que requiere
mantenimiento o reparación. No causa pérdida de funcionalidades que no se
puedan realizar de otra manera.
7.2. Niveles de aceptación para lo elementos verificados

Se debe establecer un nivel de aceptación para los elementos verificados para poder
establecer el estado en el que se encuentra el proyecto.
En esta sección defina niveles de aceptación y los criterios de pertenencia a cada nivel.
Como ejemplo de niveles de aceptación:
No aprobado: el elemento verificado tiene errores catastróficos (uno o
varios) que impiden su uso o tiene errores críticos (uno o varios) que hacen
que el elemento verificado no sea confiable. El usuario no puede depender de
él para realizar el trabajo.
Aprobado con Observaciones: el elemento verificado no tiene errores
catastróficos, ni errores críticos, pero tiene errores marginales (uno o varios)
que hacen que el elemento de software se degrade en algunas situaciones.
Aprobado: el elemento verificado no tiene errores o tiene errores menores
que no afectan el normal funcionamiento del elemento.

Plan de Verificación y Validación

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plan de Verificación y Validación

Cargado por

Copyright:

Formatos disponibles

Sistema de Gestión de Becas

Plan de Verificación y Validación

Plan de verificación y validación - Página 1 de 21

Plan de verificación y validación - Página 2 de 21

Para las pruebas unitarias se usará una combinación de estrategias de verificación

Plan de verificación y validación - Página 3 de 21

Las pruebas de desempeño son responsabilidad de un equipo especializado, las mismas

Plan de verificación y validación - Página 4 de 21

Existe el riesgo de no poder verificar todos los requerimientos no funcionales en tiempo y

1.4 Identificación del proyecto

1.5 Estrategia de evolución del Plan

Las modificaciones al Plan de Verificación se realizarán cada vez que se finalice la

Plan de verificación y validación - Página 5 de 21

En la lista a continuación se presentan los elementos, casos de uso, requerimientos

Los requisitos no funcionales a verificar son:

Plan de verificación y validación - Página 6 de 21

A continuación, se describe toda la información referida a la realización de las pruebas,

3.1 Tipos de pruebas

3.1.1. Prueba de Funcionalidad

3.1.2. Prueba de Ciclo del Negocio

Plan de verificación y validación - Página 7 de 21

3.1.3. Prueba de Interface de Usuario

Plan de verificación y validación - Página 8 de 21

3.1.4. Prueba de Performance

3.1.5. Prueba de Carga

Plan de verificación y validación - Página 9 de 21

3.1.6. Prueba de Esfuerzo (stress, competencia por recursos, bajos recursos)

3.1.7. Prueba de Volumen

Plan de verificación y validación - Página 10 de 21

3.1.8. Prueba de Seguridad y Control de Acceso

Plan de verificación y validación - Página 11 de 21

3.1.9. Prueba de Configuración

3.1.10. Prueba de Instalación

Plan de verificación y validación - Página 12 de 21

3.1.11. Prueba de Documentos

Plan de verificación y validación - Página 13 de 21

Google Drive Almacenamiento de documentación

Correo electrónico Comunicación entre los involucrados en el

Sistema de mensajería instantánea Comunicación instantánea entre los

Generador de altas carga de información Pruebas de volumen

Simulador de usuarios concurrentes Pruebas de esfuerzo

Simulador de escenarios de software y Pruebas de configuración

Plan de verificación y validación - Página 14 de 21

En esta sección se presentan los recursos recomendados para el proyecto “Sistema de

Plan de verificación y validación - Página 15 de 21

Plan de verificación y validación - Página 16 de 21

Plan de verificación y validación - Página 17 de 21

Plan de verificación y validación - Página 18 de 21

6.1. Modelo de Casos de Prueba

6.2. Informes de Verificación

Documento Se genera un documento Informe de Verificación

Plan de verificación y validación - Página 19 de 21

6.4. Informe final de verificación

7.1. Niveles de gravedad de error

7.2. Niveles de aceptación para lo elementos verificados

Plan de verificación y validación - Página 20 de 21

Plan de verificación y validación - Página 21 de 21

También podría gustarte