Escuela de Ing.

en Computacin

Introduccin al desarrollo de aplicaciones web

Documento de Pruebas

Profesor: Emilia Zeledn Lostalo

Estudiantes: Kenneth Jimnez Cerdas - 200926414 Geovanny Lpez Jimnez 200926416 Manuel Murillo Snchez - 200927704 Edgar Salas Garita - 200926432 Octubre, 2011

1. Identificador del plan de prueba: WPT-LNNC 0.1 2. Referencias

SRS del proyecto. SAD del proyecto.

3. Introduccin
Este documento pretende especificar los tipos de pruebas a realizar para probar las distintas funciones del proyecto, el cual consiste en desarrollar una pgina web que muestre informacin referente al Liceo Nocturno de Ciudad Colon. Especficamente se trata de informacin de profesores, administrativos, contactos, cursos, entre otras cosas. Para realizar las pruebas se consideraran los requerimientos planteados en el documento de especificacin de requerimientos. Adems, se pretende que al finalizar este documento se tenga un conjunto solido de pruebas para ayudar a determinar si la pgina funciona bien, o en caso contrario, si hay que realizar alguna mejora al proyecto. 4. tems a Probar (Funciones) Entre las funciones que se pretenden probar podemos mencionar: Modificar informacin: Se pretenden realizar pruebas donde se tenga que modificar la informacin que se muestra en el sitio. Subir documento: Consiste en realizar pruebas para ver si un documento se sube correctamente al sitio. Bajar documento: Se pretende hacer pruebas descargando documentos para ver que esta funcin este correctamente desarrollada. Agregar usuario: Consiste en pruebas donde se agregan usuario para verificar que esta funcin est completamente terminada y funcional. Eliminar usuario: Esta funcin se pretende probar eliminando algn usuario de la base de datos y as, comprobar que se encuentra funcionando perfectamente. Iniciar sesin: Consiste en pruebas donde se intentara iniciar sesin con varios usuarios, donde algunos estarn registrados y otros no. Cerrar Sesin: Se pretende probar nicamente mostrando que la cuenta de un usuario determinado se cierra correctamente al ejecutar esta funcin.

5. Riesgos del sistema El software que vamos a evaluar en este documento corresponde a las funciones bsicas de la pgina web, las cuales son detalladas en el segmento de tems que se trat anteriormente. Los

artefactos de la pgina web que se evaluaran corresponden a las sentencias de aadir usuarios, borrar usuarios, modificar usuarios, iniciar sesin, cerrar sesin, agregar documento, y borrar documento. Los riesgos corren principalmente por el lado de los terceros a allegados al software los cuales son las personas que van utilizar la pgina accediendo a misma desde computadoras externas a la institucin. Con esto aparece riesgo que son evaluados en este programa como la compatibilidad de la pgina web a travs de distintos navegadores y sus frameworks, de los cuales desconocemos cules son sus versiones y si con actualizaciones caen en alguna des compatibilidad. Existen otro riesgo que corre el sistema, pero esta vez del lado que se va en cargar de la administracin del producto el cual puede ser provocado por una actualizacin del sistema de bases de datos, una modernizacin de la interfaz web que pueda provocar problemas de acceso o compatibilidad. Todos estos riesgos heredan un impacto sobre el cliente quien es que se va ms afectado si el sistema deja de funcionar. 6. Aspectos a probar En esta seccin se cules son las funcionalidades que van ser evaluadas desde el punto de vista del usuario de lo que el sistema hace, adems se incluye una descripcin y un nivel de riesgo. Funcionalidad Iniciar Sesin Descripcin Es rutina consiste en tomas los datos del usuario, tanto identificacin como contrasea para verificar si pertenece al sistema y as habilitar el resto de las funciones Se encarga de guardar todas las acciones realizadas durante de la sesin y vuelve la pgina a su ambiente esttico Se encarga de agregar un usuario nuevo a la base de datos. Elimina un usuario que ya existe previamente en la base de datos. Se encarga de agregar un archivo nuevo a la base de datos. Elimina un archivo que ya existe previamente en la base de datos. Riesgo Alto

Cerrar Sesin

Medio

Agregar Usuario

Bajo

Borrar Usuario

Bajo

Agregar Archivo

Bajo

Borrar Archivo

Bajo

7. Aspectos que no sern probados Hay varios aspectos del proyecto a los cuales no se les realizaran pruebas, entre estos podemos mencionar: Navegadores compatibles con el sitio: Esto quiere decir que no se establecern pruebas para determinar los navegadores compatibles con la pgina web desarrollada. Funcionamiento de la pgina en un servidor: Dado que se acord que la pgina se creara pero que esta no sera puesta en un servidor a menos que la institucin lo decida hacer por su cuenta, no se harn pruebas para probar el funcionamiento del proyecto una vez que se ha montado en un servidor, sino que estas corren por cuenta del colegio.

8. Enfoque Niveles de pruebas: Las pruebas para el proyecto consistirn de unidad, de sistema/integracin y de aceptacin. Se espera que haya por lo menos una persona independiente de pruebas de tiempo completo para las pruebas de sistema/integracin. Sin embargo, con las limitaciones de tiempo actuales, la mayora de las pruebas se llevar a cabo por el director de pruebas con la participacin de los equipos de desarrollo. Prueba de unidad: se llevar a cabo por uno de los desarrolladores del programa y ser aprobado por el lder del equipo de desarrollo. La prueba de la unidad debe ser proporcionada por el programador al jefe del equipo antes de las que las mismas se puedan aceptar y transmitir a la persona de pruebas. Toda la informacin que la prueba de unidad involucre ser proporcionada a la persona de pruebas. Pruebas de sistema/integracin: se llevarn a cabo por el director de pruebas y el lder del equipo de desarrollo con la ayuda de los desarrolladores individuales segn sea necesario. No se encontraron herramientas de prueba disponibles tiles que fueran especficas para este proyecto. El programa entrar en la prueba de sistema/integracin, despus de que todos los defectos crticos han sido corregidos. Un programa puede llegar a tener hasta dos defectos importantes, siempre y cuando estos no impidan las pruebas del programa (es decir, hay una forma de solucionar el error). Pruebas de aceptacin: sern realizadas por los usuarios finales con la asistencia del gerente de pruebas y el jefe del equipo de desarrollo. El programa entrar en la prueba de aceptacin despus de que todos los defectos crticos han sido corregidos. Un programa puede tener un defecto importante, siempre y cuando no impida la pruebas del programa (es decir, hay una forma de solucionar el error). Antes de la finalizacin definitiva de esta fase de pruebas de aceptacin, todos los defectos crticos y principales deben haber sido corregidos y verificados por el cliente representante para esta fase de pruebas.

Reuniones: El equipo de pruebas se reunir cada vez que se tenga material a evaluar para evaluar los progresos realizados hasta la fecha e identificar las tendencias de error y los problemas tan pronto

como sea posible. Tanto el encargado de pruebas como el de proyecto deben de estar presentes en dichas reuniones. Medidas y Mtricas: La siguiente informacin ser recogida por el equipo de desarrollo durante las diversas pruebas del proyecto. Esta informacin ser proporcionada al equipo de pruebas as como al equipo de proyecto. 1. Defectos por mdulo y la gravedad de los mismos. 2. Tiempo dedicado a la resolucin de defectos. Todos los defectos menores pueden ser sumados. La siguiente informacin ser recogida por el equipo de pruebas durante todas las fases de prueba. Esta informacin ser otorgada al gerente de pruebas y al equipo de proyecto. 1. 2. 3. 4. Defectos por mdulo y la gravedad de los mismos. Tiempo dedicado a la investigacin activa. Todos los defectos menores pueden ser sumados. Nmero de veces que un programa es presentado al equipo como listo para la prueba. Defectos encontraos en los niveles superiores que deberan haber sido atrapados en los niveles inferiores de las pruebas.

9. Criterios de aceptacin y fallo Esta seccin determina cuales son los criterios que se encargan de aprobar la calidad de un producto, as tambin se establece cual es el criterio de fallo que se encargar de hundir la aplicacin. En cuanto a los criterios de xito cada una de las funciones deber de pasar las pruebas que se les fueron asignadas para poner a prueba el objetivo por el cual fueron hechas. La primera unidad de xito es completada si la aplicacin logra iniciar sesin con una lista de usuarios registrados previamente en la base de datos, en caso de poder hacer un inicio de sesin correcto para cada uno de los usuarios se considera que la prueba ya ha sido completada. La segunda parte es muy similar a la anterior como la deferencia de que esta se encargad de revisar que el sistema pueda cerrar la sesin de un numero determinados de usuarios, en caso de lograr la prueba correctamente se da por concluida esta fase. En la siguiente prueba corresponde probar las funciones de crear y borrar un nuevo usuario en la base de datos, para esta prueba se cuenta con una serie de casos que tratan de todos los puntos dbiles a la hora de llenar algn tipo de formulario, caso de completar todos los casos correctamente se considera la aceptacin de esta prueba. La ltima prueba tiene que ver con subir y borrar algn archivo de la base de datos, para esta ocasin tambin vamos a utilizar una serie de casos que describen el probable flujo de acciones de

una persona para subir y borrar un archivo. En caso de que se completen los casos de termina la prueba como un xito. Como es de esperarse el criterio de evala si una prueba fue un fracaso se obtiene a partir de las pruebas anteriores, en esta caso si la aplicacin no logra terminar las pruebas mencionadas anteriormente entonces se considera que se cumpli un criterio de fallo. 10. Criterios de suspensin y reanudacin Requisitos Durante el periodo de pruebas pueden surgir diferentes casos en los que este proceso se vera suspendido. Asimismo, existen casos en los que despus de un resultado se debe reanudar el proceso de pruebas para el sistema. Entre los casos que se pueden dar para que las pruebas se tengan que suspender podemos mencionar: Que alguna prueba no resulte de la forma esperada: En este caso no es necesario seguir haciendo pruebas, ya que se debe corregir el defecto detectado antes de poder continuar. Que todas las pruebas de las funciones principales no presenten errores: En este caso no es necesario continuar probando las funciones menores del sistema dado que si las funciones principales funcionan, quiere decir que tambin lo hacen las funciones menores.

Por otro lado, entre los casos que se pueden mencionar para reanudar el proceso de pruebas podemos mencionar: Despus de haber arreglado algn defecto de la pgina: En este caso se procede a continuar aplicando las pruebas faltantes, as como la prueba que produjo el fallo.

11. Entregables de pruebas Entre las cosas que se entregaran para el proceso de pruebas podemos citar: Documento de pruebas para el proyecto. Casos de prueba. Los resultados esperados.

12. Resto de las tareas de prueba Dado que el sistema no se desarrollara por etapas, sino que ser desarrollado en una sola etapa y a su vez entregado cuando se encuentre completado, no hay tareas de prueba que necesiten ser realizadas posteriormente. Asimismo, todos los requerimientos se vern probados antes de dar por finalizada la primera y nica etapa del proyecto. 13. Necesidades de ambiente Para realizar apropiadamente las pruebas, lo nico que se requiere es que la pgina web se encuentre conectada completamente con la base de datos.

14. Dotacin de personal y las necesidades de capacitacin Al tratarse de una pgina web relativamente sencilla, no se brindara ninguna clase de capacitacin, y consecuentemente tampoco se dotara de personal extra para que maneje el sitio. 15. Responsabilidades Gerente del Equipo X X X X X X X Gerente del Proyecto X Equipo de Desarrollo Equipo de Pruebas X X X X X X Cliente X

Documentacin y ejecucin de la prueba de aceptacin Documentacin y ejecucin de la prueba de sistema/integracin. Documentacin y ejecucin de la prueba de unidad Criticas del diseo del sistema Criticas del diseo de detalles Procedimientos de prueba y reglas Control de cambio y pruebas de regresin

X X X X X X

El lder de desarrollo ser el responsable de verificar y aceptar todos los planes para pruebas de unidad. EL encargado de pruebas ser responsable por la realizacin de los planes de prueba. Todo el equipo de desarrollo participar en las crticas. El representante que tiene comunicacin con el cliente deber participar en la ejecucin y aceptacin del plan de pruebas. 16. Calendario Consultar el SRS del proyecto. 17. Planificacin de riesgos y contingencias Debido a la disposicin de los desarrolladores, se puede dar que no se logre completar el proyecto por falta de tiempo. Al encontrarse dicha situacin se debern negociar horas extra de trabajo por medio de las cuales se tratar evitar el fallo con la fecha de entrega o completitud del proyecto, si es que el equipo lo permite. Al toparse con un punto muerto como la falta de tiempo, otra estrategia es negociar una ampliacin en el tiempo de desarrollo lo que llevara a un desplazamiento de la fecha de entrega. 18. Aprobaciones Los encargados de aprobar las distintas pruebas han sido mencionados a lo largo del documento, y es por ende que se detallan en esta seccin quienes son dichos personajes nada ms y no se reiteran sus funciones:

Jefe de desarrolladores: Geovanny Lpez J, Manuel Murillo S. Jefe de pruebas: Edgar Salas G. Jefe de proyecto: Kenneth Jimnez C. Promotor del proyecto: Dr. Jaime Solano S. Grupo de desarrolladores: Geovanny Lpez, Kenneth Jimnez, Manuel Murillo S, Edgar Salas. Grupo de pruebas: Geovanny Lpez, Kenneth Jimnez, Manuel Murillo S, Edgar Salas. Grupo de proyecto: Geovanny Lpez, Kenneth Jimnez, Manuel Murillo S, Edgar Salas.

19. Glosario No se encontraron trminos que valieran ser detallados e incluidos en esta seccin.