Introduccin

El presente documento tiene como objetivo describir las pruebas a las que se debe someter la aplicacin en sus diferentes fases de desarrollo con el fin de cumplir con los requisitos establecidos por el estndar IEEE 829 Se describen las tcnicas manuales y automticas de comprobacin de errores que se van a ejecutar sobre el visor as como los responsables de cada prueba.

Igualmente se establecen los mtodos de comunicacin entre los desarrolladores y los encargados de llevar a cabo las pruebas y los documentos donde deben quedar reflejados los resultados. Se pretende que el proceso del plan de pruebas forme parte del desarrollo en s de manera que la mayora de mdulos desarrollados sean probados una vez codificados, sin necesidad de esperar al final del proyecto. El desarrollo del proyecto, basado en metodologa RUP, permite la frecuente generacin de pequeas soluciones o mdulos la mayora de los cuales son testeables de forma independiente. Este tipo de proyectos permite a los desarrolladores recibir un feedback rpido por parte del equipo de testing u otros desarrolladores de manera que los errores no se hereden ni se magnifiquen en siguientes versiones cuando el volumen de cdigo es mayor.

Una vez que el sistema se ha construido, es necesario hacerlo pasar por una serie de pruebas antes de y entrar a la fase de produccin. Mediante dichas pruebas, se medir su reaccin integral frente a diversas acciones que realizarn los usuarios desde sus ventanas. Entre otros aspectos ser necesario probar el desempeo computacional de la plataforma tecnolgica usada; seguridad ante intentos de ataque y exactitud; correccin de su contenido y su despliegue en los diferentes programas visualizadores, entre otros aspectos. Dado que la prueba ideal de un sistema sera exponerlo en todas las situaciones posibles, as encontraramos hasta el ltimo fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecucin real. Esto es imposible desde todos los puntos de vista: humano, econmico e incluso matemtico. Probar un programa es someterle a todas las posible variaciones de los datos de entrada, tanto si son vlidos como si no lo son. Sobre esta premisa de imposibilidad de alcanzar la perfeccin, hay que buscar formas humanamente abordables y econmicamente aceptables de encontrar errores.

Objetivos General: y Realizar Plan de pruebas en busca de fallas del Sistema Dental - ProSalud

Especficos: y y y y Identificar los elementos que se van a probar. Describir la estrategia de pruebas que se va a seguir en el proceso de prueba. Identificar los recursos necesarios para llevar a cabo el proceso de prueba y estima los esfuerzos que conlleva. Listar los resultados que se obtienen de las actividades de prueba.

Consideraciones: A continuacin se especificaran algunas consideraciones que se tomaran en cuenta para el plan de pruebas: y Robustez. Se llevarn a cabo las pruebas necesarias para comprobar que la aplicacin es capaz de manejar todas las situaciones a las que debe hacer frente y que el cdigo sigue una estructura lgica. Usabilidad. Es preciso comprobar la facilidad de uso de la aplicacin en reas como la navegabilidad o la rapidez. Se debe comprobar que la aplicacin cumple con los requisitos de carga en cuanto a tiempo expresados en la oferta. Igualmente se debe verificar el tiempo entre transiciones de estados dados diferentes entornos, tanto de recursos del sistema como de tamaos de ficheros de entrada. Interfaces de usuario y correccin. Se comprobar la visualizacin de las pantallas en los entornos mostrados en los requisitos. Se verificar la ortografa y la gramtica de las diferentes pantallas del sistema y de los comentarios relativos al cdigo.

Identificacin del plan de pruebas y el sistema al que se aplica Este plan de pruebas tiene como finalidad dictar los pasos a seguir para realizar un conjunto de pruebas sobre Dental Pro salud. Esta versin del sistema abarca los siguientes eventos del sistema:

Fase 1: Eventos bsicos de Determinar Estado de Pacientes y y y y Crear Historia de Pacientes. Buscar Historias de Pacientes Gestin de Citas Reportes.

Fase 2: Elaboracin de una nica recomendacin

iniciar_sesionRecomendacin(inicio: Medico o Asistente Registrado)

A esta reduccin se lleg luego de haber hecho una planificacion del desarrollo para poder generar material de calidad en menor cantidad a lo esperado en un principio. A esta lista de eventos se debe aadir la correspondiente Interfaz que los soportar y el manejador de archivos que utiliza iniciar_sesion(). Cabe destacar que por estas mismas restricciones de tiempo que tanto la cantidad y calidad de las pruebas a ser aplicadas pueden ser mermadas. Por lo tanto nos enfocaremos en tratar de conseguir un equilibrio entre el tiempo disponible y la cantidad de casos de prueba a aplicar. Tambin debemos tener en cuenta cules son las partes de Dental Pro Salud ya codificadas que sean ms propensas a tener errores y cules son las pruebas ms apropiadas para las mismas.

Criterios de Aceptacin: Esperamos poder abarcar todas las partes de Dental Pro Salud desarrolladas en estas dos fases as como la interfaz y el manejo de archivos, elementos necesarios para poder hacer una entrega funcional del sistema. Cabe destacar que estas no han sido las primeras pruebas que se llevaron a cabo sobre este cdigo, por lo tanto se espera que la aplicacin de las mismas sea menos complicada de lo normal.

Criterios de Rechazo: Por los momentos no se tiene contemplado retirar de las pruebas ninguna parte de Dental Pro Salud nombrada anteriormente. Pero esto est restringido al tiempo, por lo tanto de ser necesario se eliminarn algunas caractersticas de Dental Pro Salud del plan de pruebas.

Enfoque: Este plan de pruebas se basar en su totalidad en pruebas del tipo Caja Negra. Entre las razones que se cuentan para tomar esta decisin est la ms importante: la restriccin del tiempo, se sabe que las pruebas de caja blanca son ms completas pero que necesitan mucho tiempo para poder ser llevadas a cabo; las mismas se utilizan cuando se tiene todo el cdigo desarrollado, aunque contamos con todo el cdigo desarrollado, el sistema est propenso a cambios dependiendo de los errores o fallas que encontremos en el plan de pruebas. Se considera como terminada una prueba cuando haya agotado su tiempo correspondiente, ese ser el criterio de finalizacin a emplear.

Productos a Entregar: Al finalizar las pruebas y rectificar los fallos obtenidos se le entregar a usuario una carpeta de archivos que contendr su sistema completo, junto con el manual de usuario para el fcil manejo de la aplicacin y el manual del sistema para poder ser aprovechado por un administrador de sistema que est a cargo de la organizacin.

Requerimientos y recursos: Para poder realizar las pruebas al sistema se deber contar con un gestor de base de datos en el computador donde se vaya a ejecutar las pruebas y un servidor web, de tipo local. Es importante destacar que no es imprescindible un sistema operativo especfico, ya que la aplicacin podr ejecutarse en cualquier sistema operativo que posea los dos componentes ya nombrados.

Tareas a Realizar para satisfacer el Proceso: El trabajo de pruebas se ha dividido en subgrupos de desarrolladores con la finalidad de que cada uno de ellos sea especialista en una fase del proceso de pruebas en especfico. Cada subgrupo debe ser responsable de generar la siguiente documentacin:

Marco Terico: sobre la respectiva prueba Consiste en el soporte terico del tipo de prueba. Tiene como finalidad servir de referencia rpida ante cualquier duda sobre el respectivo plan de prueba. Plan de prueba: Casos de prueba como tal que corresponden al tipo de prueba desarrollado. Contiene todo lo necesario para poder generar el arns de prueba y los respectivos casos. Resultado de la prueba: Los desarrolladores al aplicar sus pruebas deben generar un documento en el cual muestren los casos de prueba realizados y los resultados obtenidos.

Responsables de generar planes de prueba:

Pruebas de mtodos Pruebas de clases Pruebas de subsistemas Pruebas de sistema

Robert Valero Jenny Ramirez Ronny Posso Carlos Campos y Deliher

Planificacin:

Semana 1

Pruebas Unitarias Fase 1 Pruebas Manejador Archivos

Semana 2

Pruebas Unitarias Fase 2 PRUEBAS FASE 1 COMPLETADAS

Semana 3

Pruebas Subsistema Fase 1 y 2 Pruebas Interfaz Pruebas de Sistema PRUEBAS FASE 2 COMPLETADAS

Semana 4

Actividades atrasadas Instalacin de sistema FINALIZACIN DE LAS PRUEBAS

Riesgos: Cabe destacar que esta planificacin prev posibles atrasos, para lo cual se deja disponible la ltima semana, y la semana 4 que es bastante cmoda. Entre las posibles fuentes de problemas estn: y y Falta de tiempo: como se viene mencionando en este plan, el tiempo es la principal fuente de incertidumbre a la hora de aplicar las pruebas. Plan de pruebas incorrecto: es posible que algn desarrollador realice mal su plan de pruebas, por lo tanto las pruebas que sern aplicadas sern defectuosas o incorrectas. Mala interpretacin: as como el plan puede estar malo, tambin es posible que los dems desarrolladores interpreten mal alguno de los contenidos del mismo y se apliquen mal las pruebas. Atrasos en correccin de errores: se puede presentar el caso en el cual se descubran muchos errores y no haya tiempo de corregirlos, y menos tiempo habr para seguir probando. Atrasos en generacin de casos de prueba.