Sistema de Gestin de Universidad

UBolivia

Sistema de Estudiantes
Plan de Calidad de Software

Version: (1.1)

Date: (25/11/2015)

Historial del Documento y Distribucin

1. Historial de Revisin
Revisin #
1

Fecha de
Revisin
25/11/2015

Descripcin del cambio

Autor

Primera versin de calidad de

software

Luis Laura
Wilde Valdez
Pietro Sanjins
Miguel Pearanda
Enrique Suarez

2. Distribucin
Nombre de Destinatario

Organizacin Destinataria

Mtodo de distribucin

Ing. Gloria Molina

UBolivia

Digital

[Escriba texto]

TABLE OF CONTENTS
1.
INTRODUCCION.........................................................................................................................................................1
2. ELEMENTOS DE PRUEBA..................................................................................................................................3
3. CARACTERISTICAS QUE SE PROBARAN.....................................................................................................4
4. CARACTERISTICAS QUE NO SERAN PROBADAS......................................................................................4
5. ENFOQUE................................................................................................................................................................4
6. CRITERIO DE APROBACION / DESAPROBACION.......................................................................................6
7. PROCESO DE PRUEBAS....................................................................................................................................6
8. REQUERIMIENTOS DE ENTORNO...................................................................................................................7
9. PROCEDIMIENTO DE GESTION DE CAMBIOS.............................................................................................8
10. APROBACION DEL PLAN..................................................................................................................................8

1. INTRODUCTION
El plan de pruebas de software (STP) est diseado para determinar el enfoque, los alcances,
recursos y programacin de todas las actividades de prueba de software. El plan identifica
todos los elementos a ser probados, las caractersticas a ser probadas, todos los tipos de
pruebas que se realizarn, el personal responsable para las pruebas, los recursos y la
programacin requerida para completar las pruebas, y los riesgos asociados con el plan.
Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier
momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software,
as como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en
las actividades de desarrollo.

1.1 Objetivos
El objetivo principal de las pruebas es tener evidencia de que el software satisface
los requerimientos del cliente.
Las pruebas que se realizaran al software tienen un alcance de solamente probar
los requerimientos que sern lanzados en el primer prototipo. La programacin de
la entrega del prototipo est definida para ser el da mircoles 25/11/2015.
Las pruebas se las realizar para la deteccin de los errores que puedan existir en
el software en base a un conjunto de casos de prueba que se aplicarn al mismo.

1.2 Estrategia de pruebas

La estrategia proporciona la descripcin de los pasos que hay que llevar a cabo
como parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto
esfuerzo, tiempo y recursos se van a requerir.
Nuestra estrategia de prueba contiene:
Planificacin de la prueba
Diseo de casos de prueba
Ejecucin de las pruebas
Agrupacin y evaluacin de datos

1.3 Alcance
Las pruebas se las realiza al finalizar cada prototipo, por lo que las pruebas se las
realizar a todos los componentes que estn incluidos en el desarrollo de este,
tomando en cuenta datos ficticios para poder probar la funcionalidad del software
hasta el punto en el que est desarrollado.

1.4 Material de referencia

Como material de referencia para hacer alusin a los componentes en los cuales se
realizar las pruebas, tenemos los siguientes:

 Especificacin de Requerimientos
Plan de Proyecto
Documento de diseo UML

1.5 Definiciones y siglas

Sigla

Definicin

STP

Software Test Plan - Plan de pruebas de

Software
Job Control Languaje Lenguaje de
Control de Trabajo

JCL
PC-#

Prueba de Componente

PI-#

Prueba de Integracin

PR-#

Prueba de Recuperacin

PRE-#

Prueba de Regresin

PA

Prueba de Aceptacin

PROTOTIPO

Entrega del avance realizado

UML

Lenguaje de Modelado Unificado

BPMN

Notacin de Modelo de proceso de

Negocio

2. ELEMENTOS DE PRUEBA
Los elementos que sern probados son:

Inscripcin de materias
Consulta en general (horarios, pensum, kardex, notas)
Administracin de cuentas de usuarios
Permisos para cambio de carrera
Interaccin con los otros mdulos

2.1 Mdulos del programa

Se realizarn una serie de pruebas por cada mdulo trabajado:

Inscripcin de materas: Realizar pruebas correspondientes para verificar

que la inscripcin de materias funcione correctamente. Que no se permitan
cruces de horarios, que se cumplan los requerimientos para inscripcin de
cada materia, que se cumpla el limite de materias que se puedan inscribir
por semestre.

Consultas generales: Probar el correcto funcionamiento de las diferentes

consultas al sistema. Consultas sobre estados de cuentas, horarios, notas
parciales y finales, al igual que el kardex.
Administracin de cuentas de usuario: Hacer las pruebas
correspondientes a las cuentas de los diferentes tipos de usuarios que tienen
acceso al sistema de estudiantes. Verificar que los distintos tipos de
usuarios tengan acceso a ciertas partes del sistema.
Permisos para cambios de carrera: Controlar correctamente los
requisitos para poder efectuar los cambios de carrera. Asegurarse que el
cambio de carrera no se pueda efectuar en el transcurso del semestre. De
igual manera controlar que el cambio de carrera solo pueda ser llevado a
cabo un mximo de tres veces por alumno.
Interaccin con los otros sub sistemas: Probar el correcto funcionamiento
de la interaccin con los otros sub sistemas. Asegurarse que la integracin
con los dems sub sistemas haya sido exitosa ya que nuestro sistema
depende en gran parte de la interaccin con ellos, estos nos otorgan la
mayor parte de los datos.

2.2 Procedimientos de Control de Trabajo

Este punto no aplica a nuestro sistema.

2.3 Procedimiento de Usuario

Las pruebas de la documentacin de usuario son realizadas para hacer control
de la exactitud de la misma. Para realizar este tipo de pruebas se utiliza la
documentacin y se determinan los casos de prueba. Se realizarn casos de
sobrecarga, para poder escribir los casos de prueba. Esta documentacin
deber ser inspeccionada para poder comprobar la exactitud y claridad.

2.4 Procedimientos de Operador

Para poder llegar a la conclusin de que el funcionamiento y flujo de ejecucin
del programa es correcto, se harn las pruebas de utilizar el software desde
distintos entornos, utilizando cada una de sus propiedades y funcionalidades,
asegurndonos de esa manera que el flujo de ejecucin es correcto y no se
tiene ningn tipo de inconveniente

3. CARACTERISTICAS QUE SE PROBARAN

Las pruebas se las realizar sobre un conjunto determinado de componentes, estos
componentes sern: los usuarios (altas y modificaciones), las consultas (altas), la funcionalidad
de las interfaces de formularios.
Se probar la funcionalidad del sistema, por lo que se harn las pruebas de integracin de los

distintos componentes y su correcto funcionamiento dentro del sistema.

Previo a realizar la entrega a nuestro cliente, se realizarn las pruebas de entrega, para de esta
manera poder tener una mayor confianza de que est siendo entregado un software con plena
funcionalidad y sin errores.
Para el diseo de las pruebas, se realizar un diseo de pruebas por particiones en varios
casos, tomando en cuenta que para varios dominios se tendrn algunas pruebas similares.

4. CARACTERISTICAS QUE NO SERAN PROBADAS

Elementos a programacin futura: No se pensara en pruebas de las futuras extensiones e
incrementos del sistema por ahora.
Performance del producto: No se harn pruebas de rendimiento del programa en su mxima
capacidad, con respecto a las solicitudes de usuarios, debido a su baja prioridad en la entrega.
Validacin de datos que sean proporcionados: No se harn pruebas a los datos que los
otros sub sistemas nos proporcionen, debido a que estas pruebas tomaran mucho tiempo y
adems estos datos ya deberan estar validados por el sub sistema que sea el que
proporcione..

5. ENFOQUE
Una estrategia de pruebas de software pretende proporcionar una gua donde se describan
los pasos que se deben seguir para realizar estas pruebas correctamente. Para este
cometido se utilizara el mtodo de caja negra, los casos de prueba intentara demostrar que
las funciones del software son operativas, y que los datos de entrada sern adquiridos de
forma adecuada y que esta a su vez imprima una salida correcta.

5.1 Prueba de Componentes

Estas pruebas tienen el fin de verificar que cada uno de los componentes individuales est
funcionando correctamente, esto a fin de evitar errores y problemas futuros. Entonces el
objetivo de las pruebas de componentes es encontrar defectos en el diseo de los mismos.

ID de
Prueba

Componente (Caso de Uso)

Objetivo

PC-1

Autentificacin

El usuario ingresa su C.I. y

contrasea, el sistema valida que
la informacin sea correcta y
permite el acceso al de la
Universidad UBolivia dependiendo
de los privilegios dados por el
administrador.

PC-2

Acceso a padres

El Padre o apoderado tendr

algunos privilegios para ver el
estado del Usuario alumno con
relacin o parentesco familiar
verificado por el administrador.

PC-3

Consultas de estudiantes

El estudiante inscrito en la
Universidad
UBolivia
tendr
algunos privilegios para ver el
estado en el que se encuentra su
situacin
en
la
Universidad
UBolivia.

PC-4

Inscripciones

El
administrador
realiza
una
gestin del alumno, que constara
del registro del nuevo alumno
Inscripcin, modificacin y dar
baja a alumnos de la Universidad
UBolivia, tambin podr realizar
Copias de Seguridad.

PC-5

Cambio de carrera

El estudiante solicita un cambio de

carrera que solo ser vlido por
Administracin General dentro de
un lapso de tiempo dado y de
acuerdo
a
un
calendario
establecido

PC-6

Evaluacin docente

El
estudiante
realizara
una
evaluacin docente de acuerdo a
un calendario establecido y solo
una vez por Semestre que ser
enviado a direccin Acadmica.

PC-7

Uso de correo

El usuario podr enviar y recibir

mensajes va correo electrnico a
un
destinatario
de
otro
subsistema.

5.2 Prueba de Integracin

PI-1
Caso de Prueba:
Datos de entrada:

Cambio de paralelo
Usuario: JUANITO DOMINGUEZ
Contrasea: *******

Pasos a seguir:

Ingresar a la interfaz del sistema

Ingresar a la interfaz de inscripciones
Ir a la opcin de cambio de paralelo
Mensaje que confirme el cambio de paralelo

Datos de salida esperados:

PI-2
Caso de Prueba:
Datos de entrada:
Pasos a seguir:

Datos de salida esperados:

Consulta de notas despus de la realizar la evaluacin

docente
Usuario: ARM.HOYOS
Contrasea: *******
Ingresar a la interfaz del sistema
Intentar ver las notas parciales sin haber realizado la
evaluacin docente
Ir a la interfaz de evaluacin docente
Realizar la evaluacin
Enviar la evaluacin
Intentar nuevamente ver las notas
La primera vez no debera poder ver las notas, la segunda vez
si

5.3 Prueba de Conversin

Estas pruebas no aplican a nuestro sistema.

5.4 Pruebas de Flujo de Trabajo

Probar el correcto funcionamiento del flujo de ejecucin del sistema.
o Inicio del Sistema
o Iniciar Sesin(como estudiante)
o
o
o
o
o
o
o
o
o

Inscripcin de materias
Retirar materias
Consulta de materias inscritas
Cambio de paralelo
Revisin del horario de materias inscritas
Llenado de formulario de cambio de carrera
Consulta de notas parciales
Consulta de notas finales
Consulta de kardex

o
o
o
o
o
o
o
o
o
o
o
o

Consulta de pensum
Consulta de estados de cuenta
Llenado del formulario de evaluacin docente
Cambio de contrasea
Cerrar Sesin
Iniciar Sesin (como padre)
Consulta de notas finales y parciales
Consulta de kardex
Consulta de estados de cuentas
Consulta de horarios
Cambio de contrasea
Cerrar Sesin

5.5 Pruebas de Interfaz

Caso de Prueba:
Datos de entrada:

Ingresar al sistema con usuario: alumno, correcto

Usuario: lg.jurado
Contrasea: *******
Ingresar a la interfaz del sistema
Elegir el usuario que se quiere (alumno, padre de
familia o administrativo)
Elegir alumno para este caso
Ingresar usuario y contrasea

Pasos a seguir:

Datos de salida esperados:

Ventana principal de la interfaz de alumno

Caso de Prueba:
Datos de entrada:

Ingresar al sistema con usuario: padre registrado

Usuario: ARM.HOYOS
Contrasea: *******
Ingresar a la interfaz del sistema
Elegir el usuario que se quiere (alumno, padre de
familia o administrativo)
Elegir padre en este caso
Ingresar usuario y contrasea
Mostrar la pgina principal de docentes
Ventana principal de docentes

Pasos a seguir:

Datos de salida esperados:

5.6 Pruebas de Seguridad

ID de prueba
Objetivo
Entrada
Procedimiento

Prueba

PS-1
Asegurarse que un usuario ya sea padre o alumno solo tenga acceso a su
interfaz correspondiente
Datos del usuario (Padre)
1. Ingresar al sistema
2. Solo podr ver los mdulos que corresponden a los padres(notas,
estados de cuenta, kardex)
Exitosa

5.7 Pruebas de Recuperacin

ID de prueba
Objetivo
Entrada
Salida
Procedimiento

Prueba

ID de prueba
Objetivo
Entrada
Salida
Procedimiento

Prueba

ID de prueba
Objetivo
Entrada
Salida
Procedimiento

PR-1
Someter el sistema a un corte de energa inesperado, mientras el estudiante
se inscribe a alguna materia
Datos de la materia
Al reiniciar el equipo no se inscribe a la materia
3. Ingresar a Inscripcin de materia
4. Seleccionar la materia deseada. No hacer click en inscribir
5. Apagar el equipo de forma inesperada.
6. Reiniciar el equipo
Exitosa

PR-2
Someter el sistema a un corte de energa inesperado, mientras se llena el
formulario de Evaluacin Docente
Evaluacin al docente
Al reiniciar el equipo la evaluacin no fue enviada.
1. Ingresar a la interfaz de Evaluacin Docente
2. Llenar el formulario de la evaluacin
3. Apagar el equipo de forma inesperada.
4. Reiniciar el equipo
5. Comprobar que el formulario no fue llenado ni enviado.
Exitosa

PR-3
Someter el sistema a un corte de energa inesperado, mientras se hacen
modificaciones a la base de datos de los estudiantes
Datos del estudiante
Al reiniciar el equipo las modificaciones fueron guardadas
1. Ingresar a la base de datos
2. Hacer las modificaciones correspondientes
3. Apagar el equipo de forma inesperada.
4. Reiniciar el equipo
5. Comprobar que las modificaciones fueron guardadas.

Prueba

Exitosa

Como nuestro sistema no est terminado an y nuestra entrega solo es un prototipo, todas estas
pruebas son supuestas y que se realizaran una vez que el sistema este finalizado.

5.8 Pruebas de Rendimiento

ID de prueba
Objetivo
Entrada
Salida
Procedimiento

Prueba

PR-1
Analizar el proceso de carga en nuestro sistema.
Pruebas de carga en el servidor de la aplicacin.
Analizar la carga de nuestro sistema, detectar si se encontraron cuellos de
botella y problemas tcnicos,.
1. Utilizando la herramienta Web Page Test
2. Ingresamos el URL de nuestra pgina de aplicacin
3. La pgina proceder con el anlisis de nuestra aplicacin web y nos
mostrara un informe de resultados
Exitosa

Como nuestro sistema no est terminado an y nuestra entrega solo es un prototipo, todas estas
pruebas son supuestas y que se realizaran una vez que el sistema est finalizado.

5.9

Pruebas de Regresin

Tenemos que tener presente que cualquier cambio en el cdigo de nuestro sistema, por
pequeo e inofensivo que parezca, puede tener consecuencias inesperadas.
Cuando hacemos pruebas de regresin, estamos comprobando que el cdigo que hemos
modificado se comporta como queremos, y que el cambio no ha causado otros problemas
en otros sitios del cdigo, que funcionaban correctamente la ltima vez que los probamos.
ID de prueba
Objetivo
Entrada
Salida
Procedimiento

PRE-1
Registrar un nuevo usuario despus de que la base de datos fue modificada
Datos del usuario
El usuario debera ser registrado correctamente
1. Ingresar datos de usuario
2. El sistema dar un mensaje diciendo el correcto registro del usuario

5.10 Acceptance Testing

ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones
ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones
ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones
ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones

PA-1
Encargado de pruebas
Autentificacin
El usuario pudo ingresar al sistema con un usuario y contrasea
correspondiente
Ninguna
PA-2
Encargado de pruebas
Acceso a padres
El usuario pudo ingresar al sistema con un usuario y contrasea especfica
para los padres, estos tienen una visin limitada de las opciones del sistema
Ninguna
PA-3
Encargado de pruebas
Consulta de estudiantes
El usuario pudo hacer las diferentes consultas exitosamente, a las cual un
estudiante tiene acceso (horarios, notas, kardex,etc)
Ninguna
PA-4
Encargado de pruebas
Inscripciones
El usuario pudo ingresar al sistema como administrador y puedo hacer las
inscripciones y otras modificaciones del tipo, para cualquier estudiante
Ninguna

ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones

PA-5
Encargado de pruebas
Cambio de carrera
El usuario pudo ingresar al men de cambio de carrera y el formulario se le
presento exitosamente, este tambin pudo ser enviado despus de su llenado
Ninguna

ID de prueba

PA-6

Participante
Prueba
Anlisis de
resultados:
Observaciones

Encargado de pruebas
Evaluacin docente
El usuario pudo realizar la evaluacin docente exitosamente una sola vez por
docente. La evaluacin fue enviada exitosamente tambien
Ninguna

ID de prueba
Participante
Prueba
Anlisis de
resultados:
Observaciones

PA-7
Encargado de pruebas
Uso de correo
El usuario pudo crear, enviar y recibir correos electrnicos a otros usuarios
del sistema con xito.
Ninguna

5.11 Beta Testing

Estas pruebas no aplican para nuestro sistema

6. PASS / FAIL CRITERIA

En esta seccin se realizara una especificacin de los criterios que se tomaran en cuenta
para determinar si cada elemento se aprueba o no a la prueba. Para poder tener una buena
medida de criterios sobre el Sistema de Estudiantes se deben tener en cuenta las
caractersticas que debe cumplir, la importancia de las pruebas en sus mdulos descrita
anteriormente en este documento y la gravedad de los errores que puedan hallarse durante
la fase de pruebas.

6.1 Criterios de Suspensin

El equipo de pruebas puede suspender parcial o totalmente actividades de prueba
de una versin dada si se produce alguno de los sucesos siguientes:
El ingeniero de sistemas no puede instalar la nueva versin o un componente.
El ingeniero de sistemas no puede configurar la versin o un componente.
Una caracterstica principal tiene un error que impide probar un rea importante.
El entorno de pruebas no es lo suficientemente estable como para confiar en los
resultados.
El entorno de pruebas es muy diferente del entorno de produccin previsto y no se
puede confiar en los resultados.

6.2 Criterios de Reanudacin

La reanudacin solo se producir una vez que se resuelva el problema que origino
la suspensin. A continuacin se presentan las actividades a cumplirse para
reanudar las actividades y los procesos que debern repetirse.

El error principal desaparece o se evita de tal manera que se puede probar

la parte fundamental. Por los tiempos de entrega se reanudara la prueba
desde el comienzo considerando la parte que puede dar error, pero
buscando llegar a la parte critica que se requiere probar.
Se obtiene disponibilidad de todos los elementos y recursos necesarios.
Como especialmente este caso se lleva para las conexiones entre
dispositivos se deber hacer toda la prueba referente a que estos estn en
condiciones ptimas para las pruebas de conectividad.
Se logra igualar el entorno de instalacin, trabajo y pruebas al requerido.
En este caso solo se repetirn las ltimas pruebas antes de que se detenga
el proceso.
Los desarrolladores informan que la mayora de los errores acumulados han
sido resueltos.
Existe consenso en el equipo acerca de la solucin del problema que
supuso la suspensin de las pruebas. Este caso reanudara cualquier
suspensin del proyecto.

6.3 Criterio de Aprobacin

Errores Graves: informacin critica presentada errneamente, informacin

mal registrada en la base de datos, cadas del sistema, incumplimiento de
requerimientos, entre otros
Errores Medios (comunes): errores en presentacin de datos,
incumplimiento de requerimientos, cadas de mdulos, entre otros.
Errores Leves: errores en presentacin de datos secundarios, no
adecuacin en estndares, comportamientos correctos pero diferentes
situaciones, dificultades de operacin, entre otros.

Criterio

Descripcin

Aprobado

Se aprobara el sistema con un 100% de las pruebas ejecutadas pero con un

90% de aceptacin. Esto quiere decir que el 90% de las pruebas deben ser
exitosas y sin errores. En el restante 10% pueden existir errores medios o
bajos, pero no graves.
En caso de ocurrir que el sistema no cumpla con el nivel exigido, el sistema
se rechaza completo en su etapa de entrega.

Rechazado

7. PROCESO DE PRUEBAS
Para el proceso de realizacin de pruebas al sistema, se tomaran en cuenta las pruebas

entregables, las tareas de prueba, las responsabilidades, los recursos, la programacin

(scheduling).

7.1 Pruebas Entregables

Archivos de entrada y salida de las pruebas realizadas.

Historial de los reportes de pruebas.
Historial de incidentes en las pruebas.
Resumen de los reportes de pruebas.

7.2 Tareas de Pruebas

Familiarizacin con las herramientas de prueba.

Conocimiento de los casos de prueba.
Conocimiento de los esperados resultados de los casos de prueba.
Conocimiento del sistema.
Diseo de los casos de prueba.
Preparacin de los casos de prueba.
Ejecucin de los casos de prueba.
Resolucin de los casos de prueba.

7.3 Responsabilidades

Monitoreo de los casos de prueba: Miguel Pearanda

Diseo de los casos de prueba: Enrique Suarez
Preparar los casos de prueba: Luis Gustavo Laura
Ejecucin y evidencia de los casos de prueba: Pietro Sanjines
Resolucin de los casos de prueba: Wilde Valdez

7.4 Recursos
Los recursos que se utilizaran sern los mismos que ya fueron descritos en el
documento del plan de proyecto.

7.5 Horarios

Comenzar con las tareas de prueba: 16/11/2015

Terminar cada ciclo de las tareas de prueba: 1 da

Repetir las tareas de prueba cuantas veces sea necesario.

Las pruebas debern ser realizadas antes de la entrega final el 16/12/2015

El equipo de desarrollo debe realizar todas las recomendaciones obtenidas como

consecuencia de las pruebas.

8. REQUERIMIENTOS DE ENTORNO
En la presente seccin se presentan las propiedades necesarias y deseadas del entorno de
prueba que incluye las caractersticas fsicas, las comunicaciones, el modo de uso, y los
suministros para pruebas.

8.1 Hardware
Una computadora por cada uno de los integrantes que estn incluidos en las tareas de
prueba. Las mismas que tendrn que tener conexin a internet.

8.2 Software
Nombre del elemento
de Software
Windows
MySQL
VirtualEnv
Adobe Dreamweaver

Versin
Windows 7 o superior
5.0 o superior
Superior
5.0 o superior

8.3 Seguridad
No utilizamos ningn software de seguridad

8.4 Herramientas
Para las pruebas de integracin podremos utilizar Selenium.
Ambas herramientas son open source, por lo tanto no tendremos costo alguno al
utilizarlas.

8.5 Publicaciones
Las publicaciones que se pueden revisar adjuntas al documento de Plan de Pruebas
son:
Plan de proyecto de software
Documento de requerimientos de software
Arquitectura del sistema
Diseo de interfaces

8.5 Riesgos y supuestos

Los riesgos y supuestos fueron previamente especificado en el Plan de Proyectos
adjunto.

9. PROCEDIMIENTO DE GESTIN DE CAMBIOS

El procedimiento para modificar el plan de pruebas es el siguiente:

Proponer el cambio en el equipo de desarrollo de software. Esto se puede hacer

en una reunin de equipo o por correo electrnico, lo que conlleva a un proceso de
revisin en el equipo de desarrollo.
Analizar la propuesta. La propuesta puede ser aceptada o rechazarlo. Incluso se
podra aceptar una parte de la propuesta, o aceptarlo con modificaciones.
Consensuar las modificaciones Si el equipo acepta los casos de prueba, las
modificaciones debern ser consensuadas en grupo para llevarse a cabo.

En la gestin de pruebas, se llega al consenso de que no realizar estas pruebas resulta ms caro, y
el costo de mantenimiento ser ms alto, por lo que se define el proceso de iniciacin del plan de
pruebas.

10. PLAN APPROVALS

En la siguiente tabla muestra los aprobadores del plan.
Rol

Responsable

Monitoreo de los casos

de prueba

Miguel Pearanda

Diseo de los casos de

prueba

Enrique Suarez

Firma

Preparacin de los Luis Gustavo Laura

casos de prueba
Ejecucin y evidencia
Pietro Sanjines
de los casos de prueba
Resolucin de los casos
de prueba

Wilde Valdez

11. REFERENCIAS

https://es.wikipedia.org/wiki/Pruebas_de_software
http://es.slideshare.net/Juan_Tapias/plan-de-pruebasinces
http://pegasus.javeriana.edu.co/~CIS1010IS05/Documentos/Dise%C3%B1o/STP.pdf
Sistema de Gestin de Mantenimiento
Plantilla Plan de Pruebas UCB

Fecha de
Aprobacin