Plan de Pruebas

Instituto Profesional Santo Toms. Escuela de Informtica.
Gestor de Horario
Analisis/Implementacion Plan de Pruebas
Versin 1.0
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR
Version: 1.0 Fecha: 31/05/2011
Historial de Revisiones
Fecha 31/05/2011
Versin 1.0
Descripcin Creacin de documento Plan de Pruebas Gestor de Horario.
Autor Jocelyn Verdugo.
Confidential
<Company Name>, 2011
Page 2
ndice
1. Introduccin 1.1 Propsito 1.2 Alcances 1.3 Destinatarios 1.4 Documento de Terminologa y Acrnimos 1.5 Referencias 1.6 Estructura del Documento 2. Pruebas de Evaluacin y Motivacin 2.1 Antecedentes 2.2 Evaluacin de la Misin 2.3 Pruebas Motivadoras 3. Metas de las Pruebas 4. Esquema de Planificacin de las Pruebas 4.1 Ensayo de lo que incluyen las Pruebas 4.2 Esbozo de Otros Candidatos para su posible inclusin 4.3 Esquemas de Pruebas de Exclusiones 5. Pruebas de Enfoque 5.1 Ideas de Pruebas Iniciales de Catlogos y Otras Fuentes de Referencia 5.2 Tipos de Pruebas Tcnicas 5.2.1 Pruebas de Datos e Integridad de Base de Datos 5.2.2 Pruebas de Funcin 5.2.3 Pruebas del ciclo del Negocio 5.2.4 Pruebas de Interfaz de Usuarios 5.2.5 Rendimientos de los Perfiles 5.2.6 Pruebas de Carga 5.2.7 Pruebas de Stress 5.2.8 Pruebas de Volmen 5.2.9 Seguridad y Pruebas de Control de Acceso 5.2.10 Pruebas de Reconexin y Recuperacin 5.2.11 Configuracin de las Pruebas 5.2.12 Pruebas de Instalacin 6. Criterios de Entrada y Salida 6.1 Plan de Pruebas 6.1.1 Criterios de entrada Plan de pruebas 6.1.2.1 Criterios de salida Plan de pruebas 6.1.3 Suspensin y reanudacin de criterios 6.2 Ciclos de Prueba 6.2.1 Criterios para las Entradas de Ciclo de Pruebas 6.2.2 Criterios para la Finalizacin de Ciclo de Pruebas 6.2.3 Ciclo de trmino anormal 5 5 5 5 6 6 6 7 7 7 7 7 8 8 8 8 8 10 10 10 11 11 12 12 13 13 14 15 16 17 18 19 19 19 19 20 20 20 20 20
Confidential
Page 3
7. Entregables 20 7.1 Resumen de las pruebas de evaluacin 20 7.2 Presentacin de los Informes sobre la cobertura de las Pruebas 20 7.3 Calidad Percibida de los Reportes 20 7.4 Registro de Incidentes y de Cambios Requeridos 21 7.5 Trabajo Adicional a los Productos 21 7.5.1 Resultado Detallado de las Pruebas 21 7.5.2 Agregar Scripts Automticos a las Pruebas Funcionales 21 Se debern agregar los scripts de las funciones que se agregaran al sistema para mejorarlo, los que se usaron en cada prueba y una descripcin de que es lo que hace o que es lo que corrige dentro del sistema. Ademas el cdigo fuente deber llevar lneas de texto en las que se especifique cada acciones y en caso de variables a que corresponden. 21 7.5.3 Directrices para las Pruebas 21 8 Pruebas del Flujo de Trabajo 9 Necesidades de Ambiente 9.1 Hardware Bsico para el Sistema 9.2 Pruebas Bsicas de los Elementos del Software 9.3 Herramientas de Produccin y de Soporte 10 Responsabilidades, Dotacin de Personal y Necesidades de Entrenamiento 10.1 Personas y Roles 10.2 Dotacin de personal y Necesidades de Capacitacin Se mostraran pantallas de como deben de realizarse las operaciones dentro del sistema, detalladas paso a paso segn el perfil del usuario. 11. Iteraciones e Hitos 12. Riesgos, Dependencias, Dependencies, Supuestos y Limitaciones 13. Management Process and Procedures 13.1 Medir y Evaluar el alcance de las pruebas 13.2 Informes de Problemas, la escalada, y la resolucin de problemas 13.3 Gestin de los Ciclos de Prueba 13.4 Aprobacin y Cierre 21 22 22 22 22 22 23 23 25 25 25 26 27 27 27 27 27
Confidential
Page 4
<Iteration/ Master> Test Plan

1.
1.1
Introduccin
Propsito
Este Plan de Pruebas para el sistema Gestor de Horario tiene como propsito los siguientes objetivos: Identificar la informacin existente de las especialidades, profesores y asignaturas que deben ser otorgadosal Horario Semestral. Listar los principales requisitos a probar para la elaboracin del proyecto. Definir las estrategias de prueba que deben emplearse. Identificar los recursos necesarios que pueden requerirse. Implementar la construccin del proyecto para cualquier escuela perteneciente a la corporacin Santo Toms. Solucionar la problemtica actual de creacin horaria, ya que que debe realizarse de forma manual por los jefes de carrera de las distintas escuelas de la corporacin. Alcances
1.2
El alcance ser explicado punto a punto, mencionando los que delimitan este para evitar malas interpretaciones o dejar vacos que puedan prestarse para malos entendidos para las partes involucradas. El prototipo grafico es presentado de manera que se desplegar el sistema una vez implementado, el cliente es quien determina las caractersticas de esta, entregando las polticas necesarias para cumplir este proceso por ello se realizarn los siguientes tipos de pruebas Tcnicas: Pruebas de Datos e Integridad de Base de Datos. Pruebas de Funcin. Pruebas del ciclo del Negocio. Pruebas de Interfaz de Usuarios. Rendimientos de los Perfiles. Pruebas de Carga. Pruebas de Stress. Pruebas de Volmen. Seguridad y Pruebas de Control de Acceso. Pruebas de Reconexin y Recuperacin. Configuracin de las Pruebas. Pruebas de Instalacin. 1.3 Destinatarios Este Documento va dirigido a las personas que desempean los roles jefes de carrera pertenecientes a las distintas escuelas de corporacin santotomas.
Confidential
Page 5
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR 1.4 Documento de Terminologa y Acrnimos
A continuacin se describen los trminos y acrnimos utilizados en el proyecto Gestor de Horario, con el objeto de aclarar y quitar ambigedades que pueden generar ciertos trminos. Aqu (definicin de palabras que no entienda el usuario). Script: Archivo de rdenes o archivo de procesamiento por lotes es un programa usualmente simple. Algoritmo: Conjunto pre-escrito de instrucciones o reglas bien definidas, ordenadas y finitas que permite realizar una actividad mediante pasos sucesivos que no generen dudas a quien deba realizar dicha actividad. Proceso de Negocio: Tareas relacionadas lgicamente llevadas a cabo para lograr un resultado de negocio definido. 1.5 Referencias Los siguientes son documentos en los que se apoya este plan de pruebas: Informe general Gestor de Horario (casos de usos). Documento Rup tspln
1.6
Estructura del Documento
Documentos
N. Versin
Disponibilidad SI
Revisado/ Aprobado
Observaciones
Plan de Pruebas
1.0
Confidential
Page 6
2.
2.1
Pruebas de Evaluacin y Motivacin

Antecedentes
Como resultado de la planificacin y anlisis desarrollado para la problemtica actual de la creacin horaria, se obtuvo una arquitectura de solucin para el sistema de horario y un plan de tareas a desarrollar para solucionar la problemtica planteada. Por ello se efectuo la planificacin de pruebas con el fin de validar que la solucin y sus funcionalidades son consistentes y acordes a las expectativas de la institucin. 2.2 Evaluacin de la Misin
Las pruebas tienen como finalidad verificar que la solucin planteada satisface los requerimientos encontrados en nuestro Sistema. Estas pruebas tambin tienen como finalidad verificar la calidad de la solucin en su primera versin. 2.3 Encontrar la mayor cantidad de errores posibles. Encontrar problemas importantes, evaluar la calidad de los riesgos. Evaluar sobre la percepcin de los riesgos del Proyecto. Certificar el estndar. Verificacin de la especificacin (requisitos, diseo o reclamos). Asesorar las Pruebas. Proceso de Cumplir con las normas.
Pruebas Motivadoras Obtener un grado de calidad en los entregables del proyecto. Validar el cumplimiento de los requerimientos funcionales y no funcionales. Asegurar la aplicacin de estndares.
3.
Metas de las Pruebas
La siguiente lista identifica aquellos elementos (casos de uso, requisitos funcionales y no funcionales) que han sido identificados como objetivos de las pruebas y que sern sometidos a prueba: Administrar proyecto. Identificar requerimientos de las pruebas. Generar informe de consultas sobre disponibilidad de profesores, asignaturas, jornadas, secciones, das y salas de la especialidad para el Horario. Generar informe de asignacin de profesores, asignaturas, jornadas, secciones, das y salas de la especialidad para el Horario. Verificar conflicto de Horario. Revisar informe de modificaciones que se realizarn en el horario. Programar Horario. Consultar proyecto terminado. <Company Name>, 2011 Page 7
Confidential
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Definir proyecto. Validacin de Proyecto Consultar horario. Generar Reportes de horario.
4.
Esquema de Planificacin de las Pruebas
La planeacin efectiva del proyecto depende de la planeacin detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipacin soluciones a ellos. El administrador del proyecto es responsable de la planeacin desde la definicin de requisitos hasta la entrega del sistema terminado. 4.1 Ensayo de lo que incluyen las Pruebas Los tipos de pruebas que son necesarios para las diferentes etapas de la implementacin de la solucin y, especficamente, las responsabilidades del grupo de trabajo de pruebas en cada tipo de prueba. La estrategia usada para la prueba en cada tipo de prueba. Las distintas funciones de equipo para los miembros del grupo de trabajo de pruebas. Las actividades de requisitos necesarias para cada miembro del equipo.
4.2 Esbozo de Otros Candidatos para su posible inclusin Otras pruebas que podran ser incluidas son: Pruebas de manejo de requerimientos que tendran como objetivo validar el cumplimiento de los requerimientos planteados en el proyecto. Pruebas de manejo de errores, que tendran el objetivo de validar la forma en cmo se estn controlando las excepciones arrojadas por los algoritmos del sistema.
4.3 Esquemas de Pruebas de Exclusiones Como no se tiene conocimiento del sistema que soportan los institutos en la actualidad ni se conoce el entorno en el que se encuentra funcionando, no se harn los siguientes tipos de pruebas: Pruebas en paralelo, que tendran como objetivo comparar el comportamiento y funcionalidad de otros proyectos similares. Estas pruebas no ayudan a lograr la meta de l proyecto de evaluacin. No hay suficientes recursos como para llevar a cabo estas pruebas.
5.
a) b) c) d) e) f) g)
Pruebas de Enfoque
Las pruebas se harn en las siguientes categoras: Usabilidad Unitarias Funcionalidad, de acuerdo a los procesos de negocios vigentes Prueba de demanda on line (por ejemplo inscripcin de asignaturas(especialidad) Rendimiento. Integracin, con los sistemas en produccin Carga masiva de datos (ficha prospectos) <Company Name>, 2011 Page 8
Confidential
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR h) i) j) k) Recuperacin frente a una cada Seguridad Robutez Aceptacin
a) Pruebas de usabilidad
Estas pruebas estn orientadas a probar la usabilidad del sistema. Esto se refiere a probar la facilidad con lo cual los usuarios de una aplicacin la pueden operar. En nuestro caso, los objetivos principales sern: Determinar si los usuarios pueden utilizar las distintas funcionalidadesdel sistema sin mayores complicaciones, es decir, ubicar rpidamente lafuncin que desean ejecutar. Determinar si la interfaz es lo suficientemente intuitiva tanto para usuarios que tienen experiencia como para aquellos que no la tienen. Determinar si la aplicacin requiere modificaciones para que cumpla con los objetivos anteriores.
b) Pruebas unitarias
Pretenden probar que las funciones (unitarias) dentro del sistema cumplan las especificaciones y tienen el comportamiento esperado.
c) Pruebas funcionales
Se denominan pruebas funcionales a las pruebas de software que tienen por objetivo probar que el sistema implementado cumpla con lafunciones. Bsicamente el enfoque de este tipo de prueba se basa en el anlisis de los datos de entrada y en los de salida (datos que ingresa el usuario para el horario; como ingresar profesores con sus respectivas asignaturas, seccin, sala, dia y jornada para la especialidad) y asi mostrar las asignaciones de estas como reporte del horario). d) Prueba de demanda on line (por ejemplo inscripcin de asignaturas semestral de la especialidad e inscripcin del profesor con su respectiva asignatura.
e) Rendimiento
A veces es importante el tiempo de respuesta, u otros parmetros de r e n d i m i e n t o . C u a n d o e l s i s t e m a d e b e procesar tantos datos, o cunta memoria consume, o cunto espacio en disco utiliza, o cuntos datos transfiere por un canal de comunicaciones.Para todos estos parmetros es importante conocer cmo evolucionan alvariar la dimensin del problema (por ejemplo, al duplicarse el volumen dedatos de entrada). f)
Prueba de integracin
Las pruebas de integracin se refieren a la prueba o pruebas de todos los elementos unitarios, que comprueban la compatibilidad y funcionalidad de las interfaces entre las distintas partes que componen un sistema, estas partespueden ser, aplicaciones individuales, aplicaciones cliente/servidor,aplicaciones web, etc. Se realizan en el mbito una vez que se han aprobadolas pruebas unitarias.
g) Carga masiva de datos (por ejemplo anuncios) h) Recuperacin frente a cadas i)
Seguridad
Se valida la funcionalidad del sistema para proveer una estructura de permisos y acceso segn sea el perfil del usuario.
j)
Prueba de robustez
<Company Name>, 2011 Page 9
Confidential
Determinan la capacidad del sistema para no soportar entradas incorrectas. Se prueba la capacidad del sistema para salir de situaciones problematicas provocadas por errores en el suministro de datos.
k) Pruebas de Aceptacin
Son las que harn de acuerdo a los criterios de aceptacin, determinar que el sistema cumpla con lo deseado para obtener la conformidad del cliente. Estas pruebas las realiza el cliente. Son bsicamente pruebas funcionales, sobre el sistema completo. 5.1
Ideas de Pruebas Iniciales de Catlogos y Otras Fuentes de Referencia
Como principal objetivo se usan tcnicas para apagar el impacto de los defectos del software en la operacin de la organizacin. En el sector conflicto de horario esta la clase de errores o impactos que son an ms crticos que se encuentra en el sistema, como referencia se va a usar el manejo de informacin utilizando las pruebas tcnicas, como ejemplo prueba de carga para ver si es factible la disponibilidad de asignaturas y profesores para la especialidad, adems utilizar la prueba de stress para ver si el sistema responde adecuadamente con la carga de horario esperada.
5.2
5.2.1
Tipos de Pruebas Tcnicas

Pruebas de Datos e Integridad de Base de Datos
Se realizara una Investigacin adicional en el sistema de gestin de bases de datos (DBMS), debe ser realizado para identificar las herramientas y tcnicas que puedan existir para apoyar las pruebas sealadas en el siguiente cuadro. Objetivo de la Tcnica: Ejercicios de acceso por ejemplo: La consulta de horario, esta base de datos se podr acceder y observar el funcionamiento incorrecto del comportamiento objetivo o corrupcin de los datos consultados. Inspeccionar los datos consultados o ingresados en la base de datos para asegurar que se encuentren en perfecto funcionamiento a la hora de ser procesados. Observacin y caractersticas especficas de los resultados, lo cual indican el xito o el fracaso de la consulta realizada. Pruebas de Herramientas de Comandos automticos Criterios de xito: Configurador y restaurador de imgenes Base Herramientas de Respaldo y Recuperacin Instalacin de herramientas de seguimiento (registro, disco duro, CPU, memoria, etc.) Utilitarios y Herramientas de Base de Datos y SQL
Tcnica:
Resultados Esperados: Herramientas Requeridas
Resultado esperado del usuario en la consulta o gestin realizada.
Confidential
Page 10
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Consideraciones Especiales:
Los Administradores del sistema podrn ingresar o modificar los datos directamente en las bases de datos. Los procesos podrn ser invocados manualmente.
5.2.2
Pruebas de Funcin
El objetivo de estas pruebas es para comprobar la correcta aceptacin procesamiento y recuperacin de los datos. Este tipo de pruebas se basa en tcnicas donde verifica la interaccin de la interfaz grfica de usuario (GUI) y el anlisis de las salidas. Objetivos de las Tcnicas Tcnicas: Resultados Esperados: Navegacin, entrada de datos y consultas. Realizar cada procedimiento, para verificar su correcto funcionamiento, y expectativas del usuario. Observar con precisin los procesos de prueba, siendo los resultados esperados se auto-verifiquen, permitiendo hacer una evaluacin inicial de pruebas o el fracaso de las gestiones realizadas. Configurador y restaurador de imagines base Criterios de xito: Consideraciones Especiales: Herramientas de respaldo y recuperacin Herramientas de Monitoreo e Instalacin (registro, Disco Duro, CPU, memoria, y as sucesivamente)
Herramientas Requeridas:
Todos los escenarios y claves caractersticas para los casos de uso Temas que tienen un impacto en la implementacin y ejecucin de las pruebas de funcin.
5.2.3
Pruebas del ciclo del Negocio
Las pruebas del ciclo de negocio afectan directamente a la capa de negocio del proyector Gestor de horario las cuales estn encargadas de verificar el comportamiento con el tiempo de dicha capa. Objetivo de las Tcnicas: En esta prueba tenemos como objetivo probar el funcionamiento del ciclo de negocio en un tiempo definido.
Confidential
Page 11
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Tcnicas:
La prueba simula ciclos de negocio, en los que haremos; Pruebas que simulen ciclos de negocios simultneamente para ver la capacidad de de usuarios que interactual con el en un periodo de tiempo En estas pruebas se ocuparan datos validos e invalidos para ver como reaccionar los ciclos al momento de ingresar datos invalidos y verificar que las reglas de negocio acten satisfactoriamente.
Resultados Esperados:
Los resultados esperados pueden ser de estado exitoso o fallido los resultados fallidos se rescataran para poder llegar a una solucin y que no ocurra nuevamente. Las pruebas necesitan las siguientes herramientas: Herramientas que autogeneren datos. Herramienta de respaldo.
Criterio de xito: Consideraciones Especiales:
Estas tcnicas las soportan todos los ciclos de la capa de negocio Al momento que autogeneren datos ser necesaria una herramienta de respaldo por alguna eventualidad.
5.2.4
Pruebas de Interfaz de Usuarios
La Interface de Usuarios (IU) verifica la interaccin de los usuarios con el sistema, su perfecto funcionamiento a travs de la web, donde las consultas y administracin del sistema se lleven a cabo con xito. El IU asegura que dentro de las funciones cumpla con los objetivos como se esperaba y se ajusten a las normas de la Institucin. Tcnicas de los Objetivos: La Navegacin a travs del objetivo de la prueba, se reflejan las necesidades y las funciones del gestor de horario, incluyendo las teclas de tabulacin, los movimientos del ratn, teclas de acelerador. Crear o modificar las pruebas por cada opcin que toma el usuario, para verificar la apropiada navegacin en las consultas y gestiones que realiza. Los resultados esperados sern Auto-Verificados, permitiendo hacer una evaluacin de las pruebas realizadas. Interaccin Usuario-Sistema Conformidad del usuario, de acuerdo a su gestin o consulta.
Tcnicas:
Resultados Esperados: Herramientas Requeridas: Criterios para el xito.:
5.2.5
Rendimientos de los Perfiles
Estas pruebas estn orientadas a medir la velocidad de las respuestas y las transacciones que se efectan hacia el gestor de horario. Confidential <Company Name>, 2011 Page 12
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Objetivos de las Tcnicas: Tcnica: Resultado Esperado:
Probar el rendimiento de velocidad de respuesta y transaccin de los distintos perfiles. Hacer varias transacciones para medir velocidad de respuesta de los disintos perfiles del sistema. Los resultados posibles en esta prueba pueden ser de xito o fracaso viendo el tiempo de respuesta si es bueno sera de xito pero si es muy lento sera de fracaso y debera haber alguna modificacin en las iteraciones o en el ancho de banda. Las herramientas para esta prueba sern: Herramientas de comandos automaticos. Herramientas para medir rendimiento de perfiles. Las tcnicas soportadas para las pruebas: Transacciones de un solo usuario para asi tener transacciones sin fallas.
Criterios para el xito:
Consideraciones Especiales:
Crear un usuario virtual para poder efectuar el simulador y hacer las transacciones.
5.2.6
Pruebas de Carga
Objetivo de la Tcnica: Tcnica: Medir el rendimiento de las transacciones lgicas del negocio. En esta prueba haremos: Resultado Esperado: Que las transacciones utilizen la carga mxima para asi ver como reacciona el sistema. Las cargas se realizar en un estimado de tiempo continuo y estas siempre sern cargas mximas.
Esta prueba se encarga de cargar al mximo la transaccin y medir la respuesta del sistema a dicha transaccin.
Los resultados pueden ser de carcter exitoso o fallido al momento de ser exitoso o fallido se guardaran automticamente con un capturador de sucesos y asi poder tener un registro de estos para hacer los cambios correspondientes Las herramientas utilizadas sern: Herramientas de automatizacin de procesos. Herramientas de autogeneracin de datos. Herramienta para cargar transacciones.
Herramientas requeridas:
Criterios de xito: Consideraciones especiales:
La prueba puede ser exitosa si trabajamos con las transacciones adecuadamente y asi no tener ninguna posible falla. Para poder llevar a cabo esta prueba se necesita tener un usuario que pueda dedicarse a hacer estas transacciones.
5.2.7
Pruebas de Stress
El Test de rendimiento implementado y ejecutado para cuando el sistema falla en condiciones de bajos
Confidential
Page 13
recursos, en estas condiciones revela como caen las metas de las pruebas que no estn aparentemente bajo condiciones normales.
Objetivo de la Tcnica:
Verificar las condiciones bajo las cuales el sistema falla para continuar con los siguientes procedimientos. Poca memoria disponible o no en el servidor.
Tcnica: Resultado Esperado: Herramientas Requeridas:
Mltiples usuarios realizando la misma transaccin contra la misma informacin o cantidad. El resultado esperado sern pruebas de evaluacin en procesos que tienen xito o fracaso. Automatizacin de procesos. Herramientas de Instalacin-Monitoreo (registros, disco duro, CPU, memoria, etc.) En las aplicaciones realizadas, que el resultado sea exitoso de acuerdo a las pruebas realizadas. Aumento de la disponibilidad de espacio para las bases de datos. Sincronizar el acceso de usuarios a los mismos registros.
Criterio de xito: Consideraciones Especiales:
5.2.8
Pruebas de Volmen
Esta prueba esta encargada de medir el mximo numero de usuarios que puedan hacer transaciones a la vez y que estas sean soportadas por el sistema. Objetivo de la Tcnica : Esta prueba se encarga de medir el rendimiento del sistema de acuerdo a la cantidad de usuarios que estn simultneamente en el sistema y asi poder dar un aproximado de los usuarios mximos para un buen rendimiento del sistema.
Tcnica: Resultados Esperados:
Conectar una gran cantidad de usuarios al sistema y hacer varias transacciones para ver como se comporta este. Los resultados pueden ser exitosos o fallidos estos serultados sern capturados para asi poder tener un registro de estos y ver las fallas para poder remediarlas. Se utilizaran las siguientes herramientas: Herramientas de automatizacin de procesos. Herramientas de autogeneracin de datos. Herramientas para cargar transacciones.
Herramientas Requiridas:
Criterios de xito:
Para un xito en la prueba es necesario tener una gran cantidad de usuarios virtuales para poder generar transacciones al sistema y ver como responde este.
Confidential
Page 14
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Consideraciones Especiales:
Crear una gran cantidad de usuarios para poder medir el rendimientos y cargar las transacciones con datos reales para no tener problemas con dichas transacciones.
5.2.9
Seguridad y Pruebas de Control de Acceso
Dentro de cualquier tipo de sistema debe existir por lo menos el mnimo de seguridad para depositar la confiabilidad a un sistema informtico. Dentro de este sistema que es el gestor de horarios existir el tipo de seguridad pertinente. Dentro del gestor podremos acceder por medio de cuentas de usuario, en donde existirn por lo menos dos tipos, los cuales para acceder a cualquier informacin debern estar previamente autenticados. Seguridad y Pruebas de Control de Acceso, enfocado en dos reas claves de seguridad: Nivel de seguridad de la aplicacin, incluyendo acceso a los datos o a las funciones del negocio. Nivel de seguridad, incluyendo registrando dentro de acceso remoto al sistema. Basado en la seguridad que tu quieres, el nivel de seguridad de la aplicacin, asegura que los actors estn restringidos para especificar las funciones o los casos de uso, o ellos estn limitados en la informacion que est disponible para ellos. Por ejemplo, para cualquiera puede estar permitido ingresar datos y crear nuevas cuentas, pero solo los adminsitradores pueden borrarla. Si esto es seguridad al nivel de los datos, asegurndose que usuario tipo uno puese ver a toda la informacin de los clientes, incluyendo informacin financiera, sim embargo el usurio tipo dos solo ver la informacin demografica del mismo cliente. A nivel de sistema de seguridad garantiza que slo los usuarios acceso al sistema es capaz de acceder a las aplicaciones y slo a travs de las correspondientes puertas de acceso (gateway). Objetivos de la Tcnica: Dependiendo del comportamiento y las caractersticas de los usuarios que utilizaran este sistema se han dividido en dos tipos: usuario general y administrador. Nivel de seguridad de las aplicaciones: dentro de este tipo de escenario podr interactuar el usuario general, el cual tendr acceso a la informacin que otorgara el sistema, pero no a modificarla. El nivel de Seguridad: dentro de este nivel solo podr interactuar el administrador, ya que este tiene acceso a inserta, modifica y eliminar cualquier informacin. Tcnica: Los usuarios que pueden interactuar con el sistema son dos, estos tienen distintos tipos de permisos sobre el sistema. Usuario general: este usuario podr interactuar con el sistema a nivel solo de consulta, es decir, este tendr acceso a la informacin que entregar el sistema, pero no podr hacer ninguna modificacin de ella. Administrador: este usuario tambin podr interactuar con el sistema (consulta), pero adems podr modificar, ingresar y eliminar la informacin que estime conveniente. Nivel de Seguridad de las Aplicaciones: dentro de este nivel tendr acceso el usuario general (solo podr consultar), adems tendr acceso el administrador al cual se le otorgaran permisos de administracin. Acceso al nivel de Seguridad:a este nivel solo tendr acceso el administrador.
Confidential
Page 15
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Resultado Esperados:
Con el sistema de gestor de horarios se espera alcanzar un alto nivel de seguridad con los datos que se puedan utilizar. Adems de proporcionar la mayor confiabilidad en el acceso de los usuarios, tanto con los que tendrn solo la posibilidad de consultar tanto como los que podrn ralizar algn tipo de cambio. Dentro de las herramientas que se utilizaran tendremos: "Hacker" de seguridad y herramientas de sondeo. Herramienta administradora para la Seguridad de los Sistemas Operativos.
Criterio del xito:
Dentro de las posibilidades de seguridad para ser aplicadas en el caso del acceso de cualquier tipo de actores son variadas. En este caso utilizaremos alguna que nos permita seguridad al logearse. En el caso del tipo de red que utilizaremos puede que no dependa del sistema en s, esto tendr que ver con el tipo de administracin de red. En tal caso mejor dirigirse a soporte tcnico.
5.2.10 Pruebas de Reconexin y Recuperacin

Las conexiones, o ms bien el tipo de red no estn ligadas directamente con el sistemas, pero es muy necesario tomar en cuenta el mejor servicio de red par obtener resultados satisfactorios. Objetivo de la Tcnica: En el caso de prdida de conexin por cualquier motivo bebe existir algn tiempo para poder resguardar la informacin, con esto se garantizara el buen funcionamiento del sistema. Dentro del sistema se pueden utilizar variadas herramientas como base para la creacin de una serie de operaciones para apoyar la recuperacin de pruebas y fallos, principalmente para definir que las pruebas de ejecucin de la recuperacin ha sido exitosa. Interrumpir la energa elctrica al cliente: Desconectar el PC, y Interrupcin del la energa elctrica del servidor: Simular o iniciar los procedimientos con la energa elctrica abajo para el servidor ( debe ser proporcionado algn tipo de bateras o generador que brinden energa para evitar la prdida de informacin) Igualmete debe existir la conexin de red que aporte seguridad en el caso de que se Interrumpir va red el servidor: Simular o inicializar la comunicacin prdida con la red Resultados Esperados: Los resultados esperados para un optimo funcionamiento del sistema es poder resguardar la informacin al momento de cualquier prdida de conexin. Las herramientas requeridas son: Herramientas de monitoreo adems de algn otro tipo que ayude a resguardar los datos en caso de prdida de conexin
Tcnica:
Herramientas Requeridas :
Confidential
Page 16
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Criterio de xito:
Se deben tener en cuenta muchos puntos para el buen funcionamiento de este sistema, por lo que se requiere el tipo de conexin de red ms segura que pueda conseguir, adems de la alimentacin elctrica segura que impida cualquier prdida de energia, con esto se garantiza el buen funcionamiento del sistema. Bateras y/o generadores que proporciones larga duracin de la energa a los servidores. Buena conexin de red.
5.2.11 Configuracin de las Pruebas

Dentro de las posibilidades que existen al poner en marcha un nuevo sistema ya sea de cualquier caracterstica, podemos encontrarnos con los riesgos de no compatibilidad con los equipos, es por esto que es de mucha importancia dar a conocer las condiciones en donde se deben ejecutar este sistema de gestor de horarios. En este tipo de condicione se debe explicar la capacidad de los equipos, como tambin el tipo de conexin de red, adems d los servidores de base de datos. Objetivo de las Tcnica: Como se menciono anteriormente, para lograr una satisfactoria ejecucin del programa se debe cumplir con las condiciones requeridas previamente a la instalacin. Por ejemplo: el equipo debe tener por lo menos 2 gb de ram para aportar un correcto funcionamiento de los procesos. Ademas se debe contar con cualquier Explorer, siempre y cuando este no sea de google. Tcnica: Al ser ejecutado el sistema, este no debe aportar ningn tipo de problemas a abrir y cerrar distintos tipos de aplicaciones que no estn relacionados con el gestor de horario, ya se a abris, cerra, minimizar o restaurar el Word, Excel, etc. Durante las pruebas que se realicen no debera existir ningn tipo de inconveniente con las aplicaciones que no pertenezcan al sistema. Ademas deberia funcionar, si se lega a minimizar la memoria disponible del cliente. Resultado Esperado: Durante la realizacin de las pruebas el sistema se encontrara con distintos tipos de complicaciones, lo cual se quiere minimizar al mximo. Al cabo de este procedimiento no debera existir algn obstculo para lograr ejecutar aplicaciones que no tenga que ver con el sistema que se desea emplear. Para realizar este tipo de pruebas necesitaremos interactuar con aplicaciones que no tengan que ver con el sistema, estas pueden ser: Word, Excel, etc. Durante la ejecucin de algunas de estas aplicaciones y el gestor de horarios, no debera existir algn inconveniente al minimizar, restaurar, cerrar o abrir estas aplicaciones.
Confidential
Page 17
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Criterios de xito:
Debe ponerse en marcha el sistema ejecutando a la misma vez otras aplicaciones para poder tener nocin de las posibles complicacin es que pueda generar este tipo de proceso, y as poder descartar cualquier tipo error. Los objetivos que no estn disponibles para las pruebas que necesita el software son poder ejecutar otra aplicacin junto con el sistema, esto se refiere a que no existe la prueba concreta de que otra aplicacin funcionara correctamente al ser ejecutado el gestor de horarios. Las aplicaciones que se utilizan conmunmente son: Word Excel, power point. Pdf, etc. [Que objetivos no estn disponibles par alas pruebas que necesita el software y que estn disponibles en el escritorio? Que aplicaciones son comunmente usadas? Que aplicaciones de datos estn corriendo; por ejemplo, una gran hoja de clculo abierta en Excel o unas 100 pginas de un documento Word? La entrada al sistema netware, servidores de red, based d datos, etc, tambin necesitan ser documentadas como parte de las pruebas?.]
5.2.12 Pruebas de Instalacin

El nuevo sistema de gestor de horarios debe ser capaz de poder ser instalado en diversos entornos, con esto se quiere decir, que este debe ser capas de montarse en cualquier tipo de equipo que el cliente requiera adems, de poder adaptarse a la personalizacin que el usuario solicite. En palabras ms simples, el sistema debe poder ser instalado bajo diferentes condiciones como poder: instalar nuevamente, actualizar, instalacin completa y personalizada del software. Objetivo de la Tcnica: Como se menciono anteriormente el sistema debe adaptarse segn las circunstancias que se puedan requerir. Entre estas podemos mencionar: Nueva instalacin: el sistema gestor de horarios debe poder ser instalado en una maquina que no haya contado con el software anteriormente, es decir, una instalacin por primera vez. Actualizacin: el sistema gestor de horarios debe poder refrescarse a alguna nueva versin en una maquina con el software previamente instalado, as como tambin pueda soportar versiones antiguas. Instalacin Personalizada: el sistema gestor de horarios debe permitir la interaccin con el cliente, es decir, el cliente podr instalar el software con las propiedades o caractersticas que estime convenientes.
Confidential
Page 18
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Tcnica:
Para poder facilitar una instalacin ptima, se debe conceder los manuales necesarios para conseguir el correcto funcionamiento del sistema. Dentro de las posibilidades de instalacin podemos encontrar variadas situaciones como: Nuevo: al ser la primera vez que se instala un software con estas caractersticas, se debe proporcionar un manual en donde se explique detalladamente la manera de cmo ejecutar el programa, dando a conocer los distintos entornos en donde puede ser situado. Actualizacin: en este caso se debe proporcionar al cliente un manual donde se proporcione informacin de cmo renovar el software, es decir, este manual ser para casos en donde es sistema ya ha sido previamente instalado.
El sistema debe otorgar las caractersticas del medio e donde debe realizarse la instalacin. Resultados Esperados: El sistema en si, debe cumplir con los requerimientos del cliente y las capacidades hardware que se estimen convenientes para un conveniente y oportuno funcionamiento del sistema gestor de horarios. Se espera poder cumplir con todo lo establecido previamente, adems de poder adaptar el software segn las circunstancias permitidas ( ya sea una nueva instalacin, actualizacin e instalacin personalizada Herramientas Requeridas: El sistema requiere algunas herramientas para poder ser instalado: Se debe aportar algn medio de recuperacin de datos en caso de algn error. El sistema deber ser instalado segn las condiciones que se requieran ( en tal caso el sistema otorgara las caractersticas del medio en donde debe ser montado el programa). Criterios de Exito: Consideraciones Especiales: El sistema entregara un medio de contacto, ya sea un correo electrnico algn telfono e el caso de que sea necesario ayuda y soporte tcnico. El sistema gestor de horario requiere estrictamente la lectura del manual de instalacin o en caso contrario contactar con algun especialista.
6. Criterios de Entrada y Salida

6.1 Plan de Pruebas 6.1.1 Criterios de entrada Plan de pruebas Para comenzar con el plan de pruebase deben: Contar con los equipos necesarios para poder llevar a cabo el plan de pruebas Contar con el software para realizar las pruebas Contar con el personal capacitado para realizar la prueba
6.1.2.1 Criterios de salida Plan de pruebas Los criterios de salida que debemos probar en este plan son los siguientes: Los Usuarios logran acceder al sistema a travez de un login, el cual solicita un username y una Confidential <Company Name>, 2011 Page 19
password Los usuarios_profesores, debern ver en su sesin datos como: Nombre, Asignatura y Nota de Evaluacion correspondiente Los usuarios_jefecarrera debern ver en su sesin datos como: Nombre, Carrera a la cual esta asociada y datos de los dems profesores y las asignaturas. Los usuarios_administrativos debern ver en su sesin datos como: Nombre, Sede en la cual se encuentran e Informacion estadstica. El sistema deber generar un informe con las asignaturas que no estn programadas y adems de las asignaturas programadas con su respectiva carrera y profesor asignado. El sistema debe generar un informe exportable a Excel o a Pdf para las asignaturas no programadas.
6.1.3 Suspensin y reanudacin de criterios El plan de pruebas podr ser suspendido solo si se agregaran nuevos requerimientos por parte del usuario-final. O en caso de falla en los servidores del Instituto Profesional Santo Tomas. O se presenten problemas de salud por parte de las personas encargadas de las pruebas. 6.2 Ciclos de Prueba 6.2.1 Criterios para las Entradas de Ciclo de Pruebas Revisin y aceptacin del documento que contiene los casos de pruebas para la certificacin del proyecto.
6.2.2 Criterios para la Finalizacin de Ciclo de Pruebas El ciclo de prueba se finalizara una vez que se hayan corregidos los problemas que se hayan encontrado, adems las correciones que se hayan hecho al sistema debern ser registradas y documentadas en el plan de pruebas de cada ciclo. 6.2.3 Ciclo de trmino anormal El ciclo deber ser documentado y en caso de encontrar errores estos se pasaran al equipo de desarrollo y estos debern corregir el problema, para ellos deber detallarse bien el problema que se encontr en el ciclo de prueba y adems las correcciones que se requieren.
7. Entregables
7.1 Resumen de las pruebas de evaluacin Las pruebas al sistema se realizaran una vez terminado el sistema, y se crearan informes en un tiempo determinado para corregir los errores que se podrin encontrar, ademas con las pruebas de evaluacin se podr mejorar el sistema y hacerlo mas robusto en caso de errores. 7.2 Presentacin de los Informes sobre la cobertura de las Pruebas Los informes que se generaran en las pruebas debern comenzar con el caso de uso al cual se esta realizando el plan de pruebas, debern contener un autor y los registros que se encontran al realizar la prueba. Estos debern tener una hora en la que se realizo, una fecha y ademas observaciones del autor, en el que proporciona informacin de posibles hechos del error, ademas de posibles soluciones todo esto con el mtodo que se utilizo y las herramientas que se ocuparon para dicha prueba. 7.3 Calidad Percibida de los Reportes Para cada prueba deber mostrarse si el caso de uso logro o no lo que tenia que hacer, para medir si logra o no lo que se pide lo haremos a travez de mtricas las cuales debern ser: se logra hacer lo que se pide?, se podra mejorar?, se logra con eficiencia lo que se pide?. Todo esto deber ser documentado y registrado para Confidential <Company Name>, 2011 Page 20
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR una vez terminado el plan de prueba.
7.4 Registro de Incidentes y de Cambios Requeridos Todo incidente o cambio requerido deber ser documentado en el plan de prueba, este deber ser analizado y solucionado por parte del equipo de desarrollo, los incidentes o cambios requeridos debern ser en un documento con fecha, hora, nombre del caso de uso y el autor. Se debern especificar los cambios y el porque deberan hacerse. 7.5 Trabajo Adicional a los Productos 7.5.1 Resultado Detallado de las Pruebas Los resultados de las pruebas debern ser detallados en una planilla Excel, con el nombre del caso de uso, los errores encontrados y las soluciones que sedeberan agregar y las que se solucionaron, todo esto bajo un autor, fecha, y hora. 7.5.2 Agregar Scripts Automticos a las Pruebas Funcionales Se debern agregar los scripts de las funciones que se agregaran al sistema para mejorarlo, los que se usaron en cada prueba y una descripcin de que es lo que hace o que es lo que corrige dentro del sistema. Ademas el cdigo fuente deber llevar lneas de texto en las que se especifique cada acciones y en caso de variables a que corresponden. 7.5.3 Directrices para las Pruebas Cada prueba debera realizarse partiendo por ejecutar la accin que se solicita, una vez se vera la capacidad de reaccin del sistema, luego se vern los resultados arrojados por el sistema, todo esot debera ser documentado
8 Pruebas del Flujo de Trabajo

Flujo de trabajo que debera seguir el plan de pruebas en el desarrollo y ejecucin del plan. 1.- El usuario par a ingresar al sistema debera autentificarse, atravez de un username y unas password. 2.- El sistema debera verificar al usuario, en caso de que el login sea correcto debera iniciar sesin de usuario, de lo contrario mostrara un mensaje de error. 3.- El sistema mostrara al usuario una interfaz de inicio que tendr el nombre del usuario y cargo que desempea en el IP. 4.- En el caso de los profesores la interfaz debera mostrar una pantalla con la opcin de ingresar la especialidad del profesor y disponibilidad horaria. 5- En el caso de los jefe de carrera, el sistema debera mostrar una opcin de generar reporte de horario. En el cual se debern mostrar los profesores que han ingresado su disponibilidad y ademas su especialidad correspondiente. 6.- En el caso del usuario administrador se podrn ver los informes, ademas de los profesores y los jefes de carrera que tengan acceso al sistema. 7.- El sistema debera generar reportes para ser exportables en Excel o en PDF.
Confidential
Page 21
9 Necesidades de Ambiente
Se detallaran las necesidades para el desarrollo de las pruebas, estas necesidades abarcan las herramientas que utilizaremos y que es necesario tener para un buen plan de pruebas. 9.1 Hardware Bsico para el Sistema System Resources Resource Servidor de Base de Datos Servidor CST Base de Datos CST Pruebas del PC del Cliente Internet Explorer 9 Ancho Banda 4mbps Desarrollo de las pruebas para PC TBD TBD TBD TBD Quantity Name and Type
9.2 Pruebas Bsicas de los Elementos del Software Nombre Software Versin Windows Server Windows 7 Internet Explorer 2003 Home 9
Tipos y Otras Notas Sistema Operativo de Red Sistema Operativo Internet Browser
9.3 Herramientas de Produccin y de Soporte Categora o Tipo de la Tool Brand Name Herramienta Pruebas de Gestin Pistas Defectuosas Herramientes de DBMS Microsoft Project Microsoft Excel Gestin del Proyecto
Vendor or In-house
Version
Confidential
Page 22
10 Responsabilidades, Dotacin de Personal y Necesidades de Entrenamiento

10.1 Personas y Roles Esta tabla muestra la dotacin de personal sumidas para esta prueba de esfuerzo Recursos Humanos Roles Gestor de Pruebas Recursos mnimos recomendados Especificar las Responsabilidades o comentarios Proporciona la supervision de la Gestin. Resposabilidades includas: Analista de Pruebas Planificacin y Logstica Misin de los acuerdosa Identificacin de las Motivaciones Adquirir los recursos adecuados Reportes de gestin Actulaes Defender los interes de las pruebas Evaluar efectivamente las pruebas de esfuerzo
Identificar y definir las pruebas especificas a conducir. Las responsabilidades Incluyen: Identificar la idea de las Pruebas Definir el detalle de las Pruebas Determinar el resultado de las pruebas Documentar los cambios requeridos Evaluar la calidad del producto
Diseador de las Pruebas
Define el enfoque tcnico para la aplicacin de las pruebas de esfuerzo Responsabilidades includas: Definir el enfoque de las pruebas Definir la arquitectura de las pruebas automticas Verificar las Pruebas tcnicas Definir los elementos de pruebas Implementacin de la estructura de las pruebas
Confidential
Page 23
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Recursos Humanos Roles Revisor Recursos mnimos recomendados
Especificar las Responsabilidades o comentarios Implementa y ejecuta las pruebas. Responsabilidades includas: Implementar las pruebas y la suite de las pruebas Ejecutar los suites de pruebas Registrar los resultados Analizar y recuperacin de pruebas fallidas Documentar los incidentes
Administrador de Sistemas de las Pruebas
Asegurar el ambiente de las pruebas y mantener y administrar los activos Responsabilidades includas: Administrar la gestion de las pruebas de sistema instalar y apoyar el acceso y la recuperacin de configuraciones de entorno de prueba y laboratorios de prueba
Administrador de Base de Datos, Gestor de Base de Datos
Asegurar el ambiente de las pruebas de Datos (base de datos) y los valores son adminiustrados y mantenidos. Responsabilidades includas: Soporte de la Adminitracin de las pruebas de datos y los bancos de pruebas (base de datos).
Diseador
Identifica y define las operaciones, atributos y asociaciones de las pruebas de clases. Responsibilities include: define las clases de prueba necesarios para apoyar los requisitos de prueba, tal como se define por el equipo de prueba
Confidential
Page 24
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Recursos Humanos Roles Implementador Recursos mnimos recomendados
Especificar las Responsabilidades o comentarios Implemetar y probar las clases de pruebas y las pruebas de los paquetes. Responsibilities include: crear los components de pruebas requeridos para apoyar los requyierimientos de pruebas com son definidos por el diseador
10.2 Dotacin de personal y Necesidades de Capacitacin Se mostraran pantallas de como deben de realizarse las operaciones dentro del sistema, detalladas paso a paso segn el perfil del usuario.
11. Iteraciones e Hitos

Hitos Fecha de Inicio Planificado 18-03-2011 28-03-2011 05-04-2011 14-04-2011 14-04-2011 24-04-2011 28-04-2011 02-05-2011 07-05-2011 13-05-2011 18-05-2011 24-05-2011 Fecha de Inicio Actual 23-03-2011 28-03-2011 06-04-2011 14-04-2011 14-04-2011 24-04-2011 28-04-2011 02-05-2011 07-05-2011 14-05-2011 19-05-2011 24-05-2011 Fecha de Termino Planeada 30-06-2011 01-04-2011 11-04-2011 21-04-2011 20-04-2011 27-04-2011 29-04-2011 06-05-2011 12-05-2011 17-05-2011 21-05-2011 28-05-2011 Fecha de Termino Actual 04-07-2011 04-04-2011 13-04-2011 23-04-2011 21-04-2011 27-04-2011 29-04-2011 06-05-2011 13-05-2011 18-05-2011 23-05-2011 29-05-2011
Acuerdos del Plan de Iteracin Comienzo de la Iteracin Lnea de Base de los Requerimientos Lnea de Base de la Architectura Linea de Base de la Interfaz de los usuarios Primera entrega para pruebas Primera entrega acepatada dentro de las pruebas Primer cilco de pruebas finalizado [Segunda construccin no sera revisada] Tercera construccin entregada para pruebas Tercera entrega acepatada dentro de las pruebas Tercer cilco de pruebas finalizado
Confidential
Page 25
Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Hitos Fecha de Inicio Planificado 29-05-2011 11-05-2011 22-05-2011 Fecha de Inicio Actual 30-05-2011 13-05-2011 23-05-2011
Fecha de Termino Planeada 08-05-2011 19-05-2011 29-04-2011 30-06-2011
Fecha de Termino Actual 10-05-2011 21-05-2011 02-04-2011 04-07-2011
Cuarta construccin entregada para pruebas Cuarta contruccin aceptada dentro de las pruebas Revisin de la evaluacin de la Iteracin revisada Termino de la Iteracin
12. Riesgos, Dependencias, Dependencies, Supuestos y Limitaciones

Contingencia Riesgo
Pre-requisito de los criterios de entrada no son cumplidas.
Estrategia de Migracin
Declarar las definiciones de los pre-requisitos que deben cumplirse antes que la Carga de las Pruebas pueda comenzar.
(El riesgo es realizado)

Cumplir los requisitos pendientes Considerar las pruebas de falla de Carga Realizar nuevas pruebas y generar nuevos documentos, las pruebas anteriores tambin deben ser documentadas.
Los datos de las pruebas resultan ser insuficientes
Confidential
Page 26
13. Management Process and Procedures

13.1 Medir y Evaluar el alcance de las pruebas Las prueba sern medidas a trave de mtricas las cuales van desde el cumplimiento de los requerimientos especifico de cada caso de uso. Y estas debern ser documentadas para evaluaciones para cada plan de prueba. 13.2 Informes de Problemas, la escalada, y la resolucin de problemas Los documentos con los problemas que se presenten sern entregados al equipo de desarrollo. Los informes debern detallar los problemas encontrados y adems pobles soluciones como observaciones por parte del autor del informe.
13.3 Gestin de los Ciclos de Prueba Se comenzara con la ejecucin del proceso. Se vera la reaccin del proceso a travez de consultas e interacion con el usuario. Se buscaran posibles errores a travez de datos mal ingresados. Se documentara cada problema encontrado Se dara una posible solucin al problema. Se entrege el documento, bajo un autor, fecha, hora y nombre del proceso. 13.4 Aprobacin y Cierre El Plan de Pruebas deber ser entregado al equipo de desarrollo, una vez terminado el ciclo de pruebas y ya con los procesos verificados y listos, estos debern ser entregados a la Corporacion Santo Tomas. La Corporacion Santo Tomas deber firmar una acuerdo en el que certifique que las pruebas que se realizaron estn cumplidas y que el sistema funciona segn la documentacin que se establecio.
Confidential
Page 27

Plan de Pruebas

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Plan de Pruebas

Enviado por

Direitos autorais:

Formatos disponíveis

Instituto Profesional Santo Toms. Escuela de Informtica.

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

Descripcin Creacin de documento Plan de Pruebas Gestor de Horario.

Autor Jocelyn Verdugo.

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

<Iteration/ Master> Test Plan

<Company Name>, 2011

Version: 1.0 Fecha: 31/05/2011

Estructura del Documento

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

Pruebas de Evaluacin y Motivacin

Metas de las Pruebas

Version: 1.0 Fecha: 31/05/2011

Esquema de Planificacin de las Pruebas

Version: 1.0 Fecha: 31/05/2011

g) Carga masiva de datos (por ejemplo anuncios) h) Recuperacin frente a cadas i)

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

Ideas de Pruebas Iniciales de Catlogos y Otras Fuentes de Referencia

Tipos de Pruebas Tcnicas

Resultados Esperados: Herramientas Requeridas

Resultado esperado del usuario en la consulta o gestin realizada.

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Consideraciones Especiales:

Version: 1.0 Fecha: 31/05/2011

Pruebas del ciclo del Negocio

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Tcnicas:

Version: 1.0 Fecha: 31/05/2011

Criterio de xito: Consideraciones Especiales:

Pruebas de Interfaz de Usuarios

Resultados Esperados: Herramientas Requeridas: Criterios para el xito.:

Rendimientos de los Perfiles

Version: 1.0 Fecha: 31/05/2011

Criterios para el xito:

Criterios de xito: Consideraciones especiales:

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR

Version: 1.0 Fecha: 31/05/2011

Tcnica: Resultado Esperado: Herramientas Requeridas:

Criterio de xito: Consideraciones Especiales:

Tcnica: Resultados Esperados:

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Consideraciones Especiales:

Version: 1.0 Fecha: 31/05/2011

Seguridad y Pruebas de Control de Acceso

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Resultado Esperados:

Version: 1.0 Fecha: 31/05/2011

Criterio del xito:

5.2.10 Pruebas de Reconexin y Recuperacin

<Company Name>, 2011

Gestor de Horario. <Iteration/ Master> Test Plan PLAPRU_GESHOR Criterio de xito: