Plan Maestro de Pruebas OIM Ver. 2.0

PLAN MAESTRO DE PRUEBAS
Desarrollo del Sistema de Informacin Interinstitucional de Justicia y Paz OIM Repblica de Colombia - Derechos Reservados
Bogot, DC., Octubre de 2009

Proyecto: Sistema de Informacin Interinstitucional de Justicia y Paz Documento: Plan Maestro de Pruebas Versin: 1.0 Contrato N: PSPJ-726-2009-DDR-162 -
Documento de Control de Aceptacin:

Aprobado Por Cargo Entidad Fecha Firmas
Documento de Control de Cambios: Registro de Control (acumulativo) Versin Fecha Quien solicita el cambio Referencia de Cambio Actualizada
2/10/09 12/11/09 N.A. Interventora 1.0 2.0 Versin Inicial Ajuste en la seccin de recursos humanos. Se elimina la columna de nombres para hacer referencia nicamente a los roles.
Revisores:
Nombre Cargo
- Distribucin: Copia No.
Nombre
Cargo
Pgina 2

CONTENIDO
1. INTRODUCCIN...................................................................4 2. PLAN MAESTRO DE PRUEBAS...............................................5 3. REVISIN, APROBACIN Y DIVULGACIN.............................15
Pgina 3

1. INTRODUCCIN 1.1 Propsito
El Plan Maestro de Pruebas tiene como propsito identificar y definir los Mecanismos de Verificacin y Validacin de la Calidad del Software desarrollado por la UT DB System - SoftManagement para el proyecto Sistema de Informacin Interinstitucional de Justicia y Paz. En este sentido, el Plan Maestro de Pruebas que provee la informacin necesaria para planear y controlar los esfuerzos de pruebas del proyecto.
1.2 Alcance
Teniendo en cuenta el propsito definido para el Plan Maestro de Pruebas del Proyecto Sistema de Informacin Interinstitucional de Justicia y Paz, el alcance del mismo se determina como: Presentar la estrategia para desarrollar las diferentes pruebas que se realizarn al sistema tanto para la Verificacin como para la Validacin de la calidad del spftware, as como las herramientas, tcnicas y metodologa a utilizar en cada uno de los tipos de pruebas a ejecutar.
Pgina 4

2. PLAN MAESTRO DE PRUEBAS 1.3 Estrategia de Pruebas para la Verificacin de la Calidad del Software
El plan de pruebas soporta los siguientes objetivos
Identificar los tems a probar Describir, en trminos generales, el enfoque de pruebas a ser usado Identificar los recursos requeridos y provee un estimado de sus esfuerzos Listar los entregables de las pruebas del proyecto
Las pruebas que se ejecutarn para la verificacin del proyecto Sistema de Informacin Interinstitucional de Justicia y Paz son: Prueba de Requerimientos: Se validar que los requerimientos/casos de uso cumplan con ciertos criterios definidos para su posterior funcionamiento. Pruebas Unitarias: Se validarn las piezas individuales del software como una unidad independiente, bucles, condicionales, etc. Pruebas de Integracin: Se validar la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta. Pruebas Funcionales: Se validarn los procesos, reglas de negocio establecidas y los requerimientos funcionales. Pruebas de Sistema (No Funcionales) Simuladas : Pruebas de Rendimiento: Se validar que la aplicacin cumple los criterios de tiempos de respuesta establecidos. Pruebas de Stress: Se validarn aquellos volmenes de datos mximos que resiste el sistema antes de comenzar con errores que pueden ser contemplados dentro de un perodo especfico en el tiempo y con un nivel de concurrencia dado. Pruebas de Regresin: Se validar que el sistema mantenga su correcta funcionalidad debido a la incorporacin de un ajuste, correccin o nuevo requerimiento.
1.4 Documentacin Disponible/Documentos Prerrequisitos

Documentos N. Versin 1.0 Disponibilidad Ok No No 1.0 Ok Revisado Revisado/ Aprobado Revisado Observaciones
Documentos de
Especificaciones
En elaboracin la
segunda versin En elaboracin En elaboracin
Lista detallada de requisitos del cliente. Plan de Control de la Configuracin.
Diagramas de Casos de Uso y

formatos de casos de uso
En elaboracin la
versin de la UT DBS SM
1.5

Objetivos de Evaluacin aplicables a este Plan de Pruebas

Descubrir tantos errores como sea posible. Notificar acerca de los riesgos percibidos del plan. Examinar la aplicacin para comprobar si realiza lo que debe hacer y lo que no debe hacer.
Pgina 5

Validar y verificar a travs de la comparacin del resultado de las pruebas del aplicativo con el resultado que el mismo tendra que producir de acuerdo a su especificacin. Evaluar la calidad del producto y satisfaccin de los interesados. Evaluar las pruebas. Cumplir con los requerimientos del cliente.
1.6 Fuentes de Motivadores de Pruebas

Por Por Por Por aseguramiento de la calidad. solicitudes de cambios. riesgos de calidad. Satisfaccin del cliente. Confiabilidad. Credibilidad. Por los casos de uso (cumplimiento de la funcionalidad establecida). Por los requerimientos funcionales y no funcionales.
1.7
Tcnicas y Tipos de Pruebas de Verificacin
Conceptos Objetivo de la Prueba: Definir claramente lo que se quiere alcanzar al realizar la prueba. Tcnicas: Procedimientos utilizados en el desarrollo de la prueba para lograr el objetivo. Herramientas requeridas: Si la prueba se realiza con ayuda de alguna herramienta se describe cual es. Criterios de Aceptacin: Se establecen de acuerdo a la Prueba que se est realizando, para verificar si la ejecucin de las pruebas fueron o no exitosas. Observaciones: Datos adicionales. Prueba de Requerimientos
Validar que los requerimientos/casos de uso cumplan con ciertos criterios definidos para su posterior funcionamiento.
1.7.1
Objetivo de la Prueba: Tcnica: Herramienta requeridas: Criterios de Aceptacin: Observaciones: Entregable:
Aplicar Formato de Verificacin Casos de Uso.

NA Ningn caso de uso debe tener criterios a validar pendientes Ninguna
Formato de Verificacin Casos de Uso diligenciado.
1.7.2
Pruebas Unitarias
Validar las piezas individuales del software como una unidad independiente. Cobertura de sentencias. Consiste en generar casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez. Cobertura de condicionales. Consiste en generar casos de prueba suficientes para que cada condicin tenga por lo menos una vez un resultado verdadero y al menos una vez uno falso.
Objetivo de la Prueba: Tcnica:
Pgina 6

Cobertura de bucles. Consiste en probar varias veces el mismo bucle considerando los siguientes casos: Ignorar el bucle, pasar una vez, pasar dos veces, pasar n veces, pasar n-1 veces y n+1 veces. Herramienta requeridas: J2EE JUnit De acuerdo a las tcnicas mencionadas anteriormente los criterios de aceptacin varan as: Cobertura de Sentencia: Los casos de prueba generados deben cubrir ms del 80% de las sentencias o instrucciones que se estn probando. Cobertura de Condicionales: Los casos de pruebas generados deben cubrir los diferentes caminos que pueden existir en una condicin (falso y verdadero) y deben existir tantos casos de pruebas como condiciones. Cobertura de bucles: Los casos de prueba generados deben considerar las posibles opciones que se pueden presentar al entrar a un ciclo (Ignorarlo, pasar una vez, etc.). El 90% de las pruebas realizadas deben ser exitosas. Detectar errores en la realizacin de las pruebas. El mdulo que se probar debe ser menor a 500 lneas de cdigo. Mdulo: pieza de cdigo que cumple: Bloque bsico de programa Implementa funcin independiente simple Puede probarse por separado Informe generado por la herramienta
Criterios de Aceptacin:
Observaciones:
Entregable
1.7.3
Pruebas de Integracin
Validar la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta Pruebas de Integracin Incremental Ascendente Combinacin de mdulos de bajo nivel en grupos que realicen una misma funcin o subfuncin especifica, con el fin de reducir el nmero de pasos de integracin. Se escribe para cada mdulo un mdulo impulsor o conductor, con el fin de simular la llamada a los mdulos, introducir datos de pruebas y recoger resultados. Se prueba cada mdulo mediante su impulsor. Se eliminan los mdulos impulsores y se sustituyen por los mdulos de nivel superior en la jerarqua. J2EE JUnit
Objetivo de la Prueba:
Tcnica:
Herramienta requeridas: Criterios de Aceptacin: Observaciones: Entregable:
La cobertura total de lo probado debe ser mayor al 80% del total de los mdulos. El 90% de las pruebas realizadas deben ser exitosas.
Modulo Impulsor: Transmite o impulsa los datos de prueba al mdulo que se esta probando y muestra los resultados de los casos de prueba. Informe generado por la herramienta
1.7.4
Pruebas Funcionales
Objetivo de la Prueba: Tcnica:
Verificar los procesos y reglas de negocio establecidas. Verificar que se cumplan los requerimientos funcionales establecidos.
Elaboracin y ejecucin de Casos de Pruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e invlidos para verificar lo siguiente:
Pgina 7

Los resultados esperados ocurren cuando se usan datos vlidos. Aplicar Formato de Control de Prueba Mdulos F-TE-06.
Se despliegan mensajes de error cuando se usan datos invlidos. Cada regla de negocio es propiamente aplicada. Herramientas Requeridas: El registro de los resultados de las pruebas se trabajar a travs de la herramienta Mantis El resultado de cada caso de prueba debe ser igual al resultado de salida esperado. Incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados. Encontrar fallas al ejecutar los diferentes casos de pruebas. La aplicacin cumple con los requerimientos funcionales especificados en la fase de anlisis. El margen de tolerancia de errores es del 80% para los errores cuya severidad sea diferente de Bloqueo y Cuelgue. Ninguna Informe consolidado por mdulo
Observaciones: Entregable:
1.7.5
Pruebas de Sistema (Carga, Stress, Rendimiento) - SIMULADAS
Validar aquellos volmenes de datos mximos (por lo general las transacciones o
Tcnica:
informes) que pueden ser completados dentro de un perodo especfico en el tiempo y con un nivel de concurrencia dado. Realizar Casos de Pruebas a partir de los Requerimientos no funcionales especificados que cubran: Pruebas de rendimiento bsico. Consiste en probar la aplicacin simulando la carga esperada en el entorno de produccin. Pruebas de estrs. Verificar el comportamiento de la aplicacin en condiciones de sobrecarga, lo cual supone la base para identificar potenciales problemas de rendimiento o cuellos de botella, antes de su pase a produccin. Grinder. Que las Pruebas Funcionales hayan sido desarrolladas con xito. Que se haya Identificado en qu punto el aplicativo no soporta las situaciones extremas. Que los reportes generados por las herramientas de automatizacin de pruebas contengan las mnimas variables que permitan un anlisis acertado de la prueba. Haber tenido en cuenta la mayora de escenarios a los que puede ser expuesta la aplicacin a probar. Nota: Los Criterios de Aceptacin podrn ser modificados o ampliados de acuerdo con los requerimientos definidos en el documento de requerimientos no funcionales. Ninguna Se debe especificar el entregable de la prueba.
Herramienta requeridas:
Observaciones: Entregable:
1.7.6
Pruebas de Regresin
Validar que el sistema siga funcionando perfectamente despus de que las correcciones y/o realces son aplicados.
Realizar nuevamente las pruebas (unitarias, de integracin, funcionales y de

Tcnica:
carga etc.) que se hicieron antes de corregir defectos o de aadir nuevas funcionalidades, para comprobar que las modificaciones no provocan errores donde antes no los haba.
Pgina 8

Herramienta requeridas: Criterios de Aceptacin: Observaciones: Entregables: Utilizar las mismas herramientas usadas para las pruebas segn sea el caso. Tomar como base los Criterios de Aceptacin de las pruebas que se volvern a realizar segn sea el caso. Las pruebas deben haber sido bien documentadas con respecto a su realizacin y resultados, para mayor facilidad a la hora de repetirlas. Los responsables de las Pruebas de Regresin se establecen dependiendo del momento en el que se realicen las modificaciones. Aplican los mismos de cada tipo de prueba
1.8 Indicadores
A continuacin se presentan los indicadores establecidos con el propsito de determinar la calidad del software desarrollado: 1.8.1 Indicadores de Pruebas Funcionales
Se definen de acuerdo con los campos que configurados en la herramienta MANTIS:
(Total de errores reportados/Total de Casos de Prueba) * 100 (Total de errores reportados por severidad/Total de Casos de Prueba) * 100
Con base en estos indicadores se podr determinar el cumplimiento del margen de tolerancia el cual es uno de los criterios de aceptacin establecidos para este tipo de pruebas. 1.8.2 Indicadores de Otras Pruebas
Para los dems tipos de pruebas, en las cuales se utilizan herramientas para su ejecucin, no se definen este tipo de indicadores teniendo en cuenta que tales herramientas los generan automticamente.
1.9
Criterios de Entrada y Salida
Los criterios de entrada y salida para el desarrollo del Plan de Pruebas determinan las condiciones bajo las cuales este debe ser ejecutado, terminado y suspendido. 1.9.1 Criterios de Ejecucin del Plan de Pruebas
Casos de pruebas documentados incluyendo escenarios claros para el desarrollo de las pruebas. Claridad en el procedimiento para la realizacin de las pruebas. El entorno de pruebas debe ser el adecuado para la realizacin de las pruebas. Toda la documentacin requerida/prerrequisito debe estar disponible. Criterio de Terminacin del Plan de Pruebas
1.9.2
Todas las pruebas se ejecutan sin errores inesperados. Las pruebas de sistema demuestran que existe un grado satisfactorio de capacidad con respecto a lo definido previamente en los requerimientos no funcionales. Las pruebas de regresin se realizaron correctamente. No existen incidencias/bugs con estado abierto. Las pruebas se documentaron de acuerdo a lo establecido dentro del procedimiento.
Pgina 9

1.9.3 Criterio de Suspensin del Plan de Pruebas
Una componente principal tiene un error que impide probar un rea importante (Error bloqueante). El entorno de pruebas no es lo suficientemente estable como para confiar en los resultados.
1.10 Recursos
Para la ejecucin del Plan de pruebas del proyecto se requieren recursos humanos y recursos del sistema 1.10.1 Recursos Humanos Los perfiles fueron establecidos de acuerdo con los alcances del proyecto y los requerimientos del Cliente y son atendidos por los profesionales que se listan a continuacin:
Cargo Director Responsabilidad en el proyecto Es el encargo de coordinar el grupo de trabajo, responsable general del proyecto por parte del contratista, elabora y propone los cronogramas de trabajo, administra los recursos, asigna recursos a tareas, reporta avance de programa y cierre de fases. Es el responsable de la calidad, estandarizacin, integracin, compatibilidad de los entregables y de que se entreguen los productos establecidos. Es responsable de las plantillas especficas del proyecto y guas especficas (arquitectura), herramientas, modelo de anlisis y diseo, modelo de despliegue, modelo de implementacin, prueba de concepto arquitectnico y documento de arquitectura del software. Es el encargado de definir la arquitectura del sistema. Define los componentes del sistema, los mecanismos arquitectnicos, la combinacin de tecnologas utilizadas en la implementacin, estndares de codificacin, etc. Es el encargado de presentar los prototipos para la presentacin del sistema de informacin a desarrollar con respecto a pantallas a la arquitectura, pantallas de captura y salidas de informacin, apoyar con las posibles modificaciones que surjan en el desarrollo del proceso. Tiene la responsabilidad de elaborar la documentacin que exige la elaboracin de un sistema de informacin, manuales de usuario, de procedimientos, etc. Es el responsable por los procesos de elaboracin de las especificaciones tcnicas del sistema y desarrollar el sistema de informacin. Es el encargado de interpretar claramente los documentos de especificaciones antes diseados con la aprobacin del usuario final, para lograr un ptimo desarrollo de la aplicacin. Debe entender los requerimientos de negocio, identificar los actores del sistema e involucrarlos en el desarrollo, ayudar al usuario a articular las capacidades que necesiten del sistema para cumplir con los objetivos del negocio y entregar los desarrollos a satisfaccin del cliente. Encargado de coordinar las actividades de migracin. Es el experto en bases de datos quien se encargar de todo el proceso de instalaciones y migraciones de datos, ejecuciones de sripts de acuerdo a las necesidades del desarrollo, preparacin de los ambientes de desarrollo y pruebas, apoyo continuo al equipo de desarrollo, etc.
Arquitecto
Diseador Grfico Documentador
Ingenieros de desarrollo
Ingeniero de Desarrollo de Base Datos Administrador de DB
Pgina 10

Cargo Ingenieros de requerimientos Administrador de la configuracin Ingeniero Asegurador de la Calidad Responsabilidad en el proyecto Es quien elabora los documentos de requerimientos de acuerdo a las necesidades del cliente. Es el encargado de detallar la documentacin de la especificacin de los casos de uso y debe documentar por cada caso de uso los flujos de proceso bsicos y alternos de cara al desarrollo de cada componente del sistema. Es la persona encargada de mantener el registro actualizado de todas las posibles novedades, versiones y configuraciones que surjan en el desarrollo del aplicativo. Encargado de coordinar las actividades de aseguramiento de calidad del proyecto y del software.
1.10.2 Recursos del Sistema A continuacin se especifican los requerimientos necesarios de hardware y software para establecer el ambiente de pruebas, el cual debe corresponder con el definido dentro del Plan de Administracin de Configuracin.
Recurso Servidor Cantidad 1 Caractersticas de SW Herramientas instaladas para pruebas: Mantis Oracle My SQL (Para la herramienta Mantis) Herramientas instaladas para pruebas: Grinder J2EE JUnit
Base de Datos
Equipos personales
1.11
Riesgos del Plan de Pruebas
Los riesgos asociados al plan de pruebas estn identificados en el Plan de Riesgos del Proyecto.
1.12
Hitos de Iteracin
A continuacin se identifican los puntos de control durante la ejecucin del Plan de Pruebas antes que el proyecto finalice para realizar seguimiento al mismo. Hito
Planificacin: Elaboracin del Plan de Pruebas Ejecucin: Diseo de Pruebas Iteracin 1 Ejecucin de Pruebas Iteracin 1 Evaluacin de Pruebas Iteracin 1 Pruebas de Usuario y entrega iteracin 1 Diseo de Pruebas Iteracin 2 Ejecucin de Pruebas Iteracin 2 Evaluacin de Pruebas Iteracin 2 Pruebas de Usuario y entrega iteracin 2 Diseo de Pruebas Iteracin 3 Ejecucin de Pruebas Iteracin 3
Fecha Planeada
08/07/09 16/09/09 21/09/09 25/09/09 26/10/09 23/10/09 30/10/09 09/11/09 11/12/09 12/01/10 15/01/10
Pgina 11

Hito
Evaluacin de Pruebas Iteracin 3 Pruebas de Usuario y entrega iteracin Diseo de Pruebas Iteracin 4 Ejecucin de Pruebas Iteracin 4 Evaluacin de Pruebas Iteracin 4 Pruebas de Usuario y entrega iteracin Diseo de Pruebas Iteracin 5 Ejecucin de Pruebas Iteracin 5 Evaluacin de Pruebas Iteracin 5 Pruebas de Usuario y entrega iteracin Diseo de Pruebas Iteracin 6 Ejecucin de Pruebas Iteracin 6 Evaluacin de Pruebas Iteracin 6 Pruebas de Usuario y entrega iteracin Diseo de Pruebas Iteracin 7 Ejecucin de Pruebas Iteracin 7 Evaluacin de Pruebas Iteracin 7 Pruebas de Usuario y entrega iteracin 3
Fecha Planeada
28/01/10 04/03/10 25/02/10 02/03/10 17/03/10 30/04/10 06/04/10 09/04/10 26/04/10 02/06/10 06/05/10 11/05/10 28/05/10 15/07/10 30/06/10 02/07/10 16/07/10 17/08/10
1.13 Mecanismos de Comunicacin

Los mecanismos y flujos de comunicacin con los tiempos de respuestas que se utilizarn para la gestin del plan de pruebas, se establecen dentro del Plan de Comunicaciones del Proyecto.
Pgina 12

1.14 Pruebas para la Validacin de la Calidad del Software
Las pruebas que se ejecutarn para la validacin del proyecto Sistema de Informacin Interinstitucional de Justicia y Paz son: Pruebas de Usuario/Aceptacin: Hacen referencia a las pruebas que debe hacer el usuario/cliente para validar la correcta funcionalidad del desarrollo.
Validar por parte de los usuarios los procesos y reglas de negocio establecidas. Validar por parte de los usuarios que se cumplan los requerimientos funcionales
Tcnica:
establecidos. El usuario recibe la capacitacin para el uso del sistema a probar por parte de la UT y para el uso de la herramienta sobre la cual se van a reportar las incidencias encontradas. El usuario elabora y ejecuta sus propios casos de prueba. El usuario reporta incidencias encontradas sobre el ambiente creado para tal fin por la UT.
Herramienta requeridas: Criterios de Aceptacin: Observaciones: Entregables:
Aplicar Formato de Casos de Prueba de los Usuarios.
El registro de los resultados de las pruebas se trabajar a travs de la herramienta Mantis La aplicacin cumple con los requerimientos funcionales especificados en la fase de anlisis. El margen de tolerancia de errores es del 80% para los errores cuya severidad sea diferente de Bloqueo y Cuelgue. Ninguna Informe consolidado por mdulo
Para cada iteracin establecida para el proyecto SIIJYP se han determinado las siguientes actividades que se ejcutarn como parte del proceso de validacin: Definicin de Roles y creacin de usuarios en la herramienta Mantis: OIM debe entregar a la UT DB System SoftManagement, por lo menos con 2 das de anterioridad a la actividades de capacitacin de usuarios, un listado de las personas que ejecutarn las pruebas de validacin del sistema, el cual debe incluir: o Nombre completo del funcionario o Entidad en la que labora o Direccin de Correo Electrnico o Rol que tendr dentro del SIIJYP Capacitacin de Usuarios: La UT DB System - SoftManagement llevar a cabo actividades de capacitacin previas al inicio de las actividades, para ensear el correcto uso de las funcionalidades desarrolladas y que deben ser validadas por los usuarios. En cada capacitacin se incluir el tiempo para instruir a los usuarios sobre el uso de la herramienta Mantis, a travs de la cual se reportarn las incidencias detectadas durante las pruebas de validacin. Para el desarrollo de estas capacitaciones la OIM debe proveer los siguientes insumos:
Pgina 13

o Espacio o saln para la capacitacin de los usuarios, con la capacidad determinada para el nmero de personas que reciban las capacitaciones y realicen las pruebas de validacin, mas dos instructores, reservado para la cantidad de das previstos para la capacitacin de cada iteracin. Equipos con conexin a Internet, para cada una de las personas que recibirn la capacitacin. Proyector para conetar al equipo del instructor de las capacitaciones. Conexin a Internet para dos capacitadores
o o
Entrega de la Gua de pruebas: La UT DB System - SoftManagement elaborar para cada iteracin una gua de pruebas que ser entregada durante las capacitaciones a los usuarios con el propsito de establecer el orden de las pruebas que sern ejecutadas y la estrategia de respuesta del equipo de desarrollo y soporte frente a las incidencias que se presenten. La gua contendr la siguiente informacin para cada iteracin: o o o Listado de Casos de Uso por mdulo a probar. Rango de fechas establecido para las pruebas por grupos de casos de uso Datos de contacto del equipo de soporte para las pruebas de validacin
Pgina 14

3. REVISIN, APROBACIN Y DIVULGACIN
Una vez completado el Plan de Calidad del Proyecto, este ser sometido a la revisin por parte de la Interventora REDCOM y ser aprobado por parte del Gerente del Proyecto de OIM. La divulgacin del plan de calidad a los interesados se realizar segn se acuerde durante las reuniones de seguimiento.
Pgina 15

Plan Maestro de Pruebas OIM Ver. 2.0

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Plan Maestro de Pruebas OIM Ver. 2.0

Hochgeladen von

Copyright:

Verfügbare Formate

PLAN MAESTRO DE PRUEBAS

Bogot, DC., Octubre de 2009