Plan de Pruebas

2010

Andrés González. 201018063

Especialización en construcción de software Universidad de los andes Bogotá 2010

Julián Morales. 200213074 Carlos Criales. 200925612 José Daniel García. 200818257 Robinson De La Hoz. 201018033 Haiver Páez. 201018119

Versión 1 1.1 1.2

Modificado por Grupo de Trabajo .jarc Grupo de Trabajo .jarc Grupo de Trabajo .jarc

Descripción Creación del documento de arquitectura de datos Inclusión de correcciones Inclusión de vistas

Fecha Mayo 11 de 2010 Mayo 18 de 2010 Mayo 18 de 2010

CONTENIDO

1. Introducción

9
9 9 10 10 10

1.1 .................................................................................................................. Propósito 1.2 .................................................................................................................... Alcance 1.3 ............................................................................................. Audiencia del documento 1.4 ............................................................................................ Terminología y acrónimos

MEPROC: Siglas para identificar el proyecto “Mejoras del Proceso de originación de crédito en el Banco de los Alpes”. 1.5 ............................................................................................................... Referencias Los siguientes son documentos en los que se apoya este plan de pruebas: ..................................... 11 11

2. Misión de las pruebas

11

2.1 Antecedentes ............................................................................................................................. 12 2.2 Misión de evaluación ................................................................................................................ 12 2.3 Motivadores de pruebas ............................................................................................................ 12

3. Elementos a ser probados 4. Perspectiva de las pruebas planeadas

12 13
13 14 14

4.1 ............................................................................... Perspectiva de las pruebas incluidas 4.2 ................................................................. Perspectiva de otros candidatos a ser incluidos 4.3 ......................................................................... Perspectivas de exclusión en las pruebas

5. Estrategia de Pruebas

14

5.1 .................................................................. Catálogo de ideas iniciales y otras referencias

14

Como principal objetivo se usan técnicas reconocidas para mitigar el impacto de los defectos del software en la operación de la organización. En el sector financiero esta clase de errores o impactos son aún más críticos que en cualquier otro sistema, como referencia se va a usar la circular 052 en el manejo de información. .................................................................................................................. 15 5.2 .......................................................................................... Técnicas y tipos de pruebas 5.2.1 ................................................ Pruebas de integridad de Datos y Base de Datos 5.2.2 ...................................................................................... Pruebas de Función 5.2.3 ......................................................................... Pruebas de Ciclo de Negocio 5.2.4 ....................................................................... Pruebas de Interfaz de Usuario 5.2.5 ................................................................................. Pruebas de Desempeño 5.2.6 ......................................................................................... Pruebas de Carga 5.2.7 ......................................................................................... Pruebas de Stress 5.2.8 .................................................................................... Pruebas de Volumen 5.2.9 ....................................................... Pruebas de Seguridad y Control de Acceso 5.2.10...................................................................... Pruebas de Tolerancia a Fallas 5.2.11............................................................................ Pruebas de Configuración 5.2.12................................................................................. Pruebas de Instalación 15 15 15 16 17 17 18 19 19 20 21 21 22

6. Criterio de Entrada y Salida

23
23 23 23

6.1 .......................................................................................................... Plan de Pruebas 6.1.1 ............................................................ Criterio de Entrada al Plan de Pruebas 6.1.2 ............................................................... Criterio de Salida al Plan de Pruebas

.... • ...... 25 7............................................. 24 • .. Criterio de Entrada al ciclo 23 24 24 Se identifican los casos objeto de las pruebas..... 25 25 •Identifica qué mejoras se pueden realizar en el proceso de prueba para incrementar la cobertura y/o calidad de las pruebas...................2 ............ Logs de Incidentes y Control de Cambios 25 25 25 Se detallan el número de defectos detectados en la ejecución de los casos de pruebas... para los cuales el insumo principal será un lote de pruebas que previamente debe haber sido preparado por los responsables de ejecutar las pruebas..................................................................... Evalúa que el comportamiento del sistema que se ha desarrollado es correcto.................4 . Resumen de evaluación de pruebas El proceso de prueba se debe haber aplicado según lo definido en el Plan de Pruebas....1 ...........................................................2 .......... Criterio de Suspensión del Plan de Pruebas 6.............................................................................2..... 24 6........................................ Tendencia de defectos 26 29 ...........2.................................................... 25 7................... Terminación del ciclo anormal 24 24 7. 24 Mediante el informe de pruebas se: ....................................................................................................3 ..3 ......................... Entregables 24 24 7........Densidad de defectos 7..............................................................................................Ciclo de Pruebas 6............... Evalúa la aceptabilidad del proceso de pruebas llevado a cabo........ Cada uno de los defectos es clasificado y priorizado para realizar la corrección.....4....................................................................1 .....................................2....... .....1........................................ ............................ Reportes de Calidad Percibida 7.....................1 ................................... Reporte de cubrimiento de pruebas 7.........................2 .................. Criterio de Salida del ciclo 6...........................................6.........................2 ........4.....................3 ..................... Los controles de cambios son documentados y priorizados según el impacto en las funcionalidades requeridas..............

.................... Matrices de Trazabilidad 30 31 31 31  ID Caso de prueba  Nombre del Caso de prueba  Aplicación  Modulo  Versión  Prioridad  Tipo de Prueba  Descripción Caso de prueba  Criterios de AceptaciÛn  ID Req..............6........ asociado al Caso de prueba  Descripción Req.................5 ......................6 ..........................4...7...................3 ............................ Pruebas automatizadas y soporte de script de pruebas 7............................... asociado al Caso de prueba  Objetivo del Caso de prueba  No Paso 32 32 32 32 32 32 32 32 32 32 32 32 32 .................................................. Tiempo de corrección de defectos 7..........1 ......................................... Productos adicionales de Trabajo 7.....

........ Dependencias.....2 ........................................Elementos de software base en el ambiente de pruebas 8................................. Descripción del Paso  Resultados Esperado  Condiciones de entrada  Medio de ValidaciÛn  Estado  Fecha Final  Documentación relacionado  Ejecutor 8............................................ Personas y roles 9.......4 ...... Herramientas de Productividad y Soporte 8...................3 .......................................................2 .............. Necesidades de ambiente 32 32 32 32 32 32 32 32 33 33 33 34 35 8............ Responsabilidades y Necesidades de Entrenamiento 35 35 36 9..................... Riesgos... Hitos de Iteración 11....................................1 .............1 ...............Hardware de base del sistema 8........ Configuraciones de ambiente de pruebas 9................................................. Necesidades de Staff y Entrenamiento 10....... Suposiciones y restricciones 37 38 .......................................................................................

............ 42 Finalmente........................ toda la organización del proyecto MEPROC......... En el proyecto MEPROC........ y si se acopla al estándar utilizado.... 40 12.......................................................................................2 ..........................5 .......... En este documento..... revisar los procedimientos desarrollados y revisar los procesos de las gerencias en conformidad al estándar y a los planes de procedimientos definidos por ellos............................ el proceso de pruebas estará a cargo de la persona asignada para el rol de Administrador de pruebas............. Procedimiento de administración 40 40 12. escala y solución de puntos 12........... también se definen los roles........12.....6 ....... se encuentra definida en el WBS.......4 ....... Valoración de los entregables de este plan de pruebas 12...................... Métricas y evaluación de las pruebas Las métricas a tener en cuenta para el proyecto MEPROC........................................... Las principales tareas del grupo de pruebas para la fase de diseño arquitectónico son: revisar los documentos en conformidad al estándar.. 42 12. con la ayuda de los integrantes de las demás áreas involucradas en el proyecto.......... .............. Reporte de problemas........................1 ......................................... Estas tareas de aseguramiento de la calidad serán desarrolladas por el administrador de pruebas del proyecto............................ El administrador de pruebas será supervisado por los encargados de la gerencia del proyecto........ Aprobación y Terminación 42 43 .......... responsabilidades y tareas de todos los integrantes del proyecto....3 ... Estrategia de Trazabilidad 12....... contendrán los siguientes atributos: .................Administración de ciclos de pruebas 41 41 42 El grupo de pruebas esta orientado a determinar si el producto en desarrollo cumple con los procedimientos detallados por las gerencias del proyecto................

Este documento esta preparado para ser incluido en el proyecto propuesto por la especialización de Construcción de Software en la Universidad de los Andes. Este define los siguientes objetivos específicos:       Identificar las funcionalidades que serán objeto de nuestras pruebas. PROPÓSITO Este documento tiene como finalidad mostrar la estrategia de prueba que se llevará a cabo para el proceso de certificación del plan de pruebas para el proyecto MEPROC. Lista los entregables de las pruebas del proyecto MEPROC ALCANCE En el presente plan se describirán algunas de las pruebas que serán contempladas y aplicadas al proyecto MEPROC. Determinar el esfuerzo requerido para la realización de las pruebas. .INTRODUCCIÓN Este es un documento fundamental para que la fase de pruebas sean lo más exitosa posible. además de generar un producto de alta calidad. Validar que el proceso de estudio de crédito se soporte en las regulaciones del sector financiero BASILEA II y SOX.     Validar el proceso de recepción de los archivos entregados por los proveedores. Identificar los recursos tecnológicos y/o humanos que serán parte de las pruebas. Definir el alcance del plan de pruebas. Validar que el cumplimiento de las reglas en el proceso del estudio de crédito. Validar la consistencia de los datos del cliente en los diferentes sistemas del banco. Definir las técnicas de pruebas a utilizar durante el desarrollo del proyecto MEPROC.

compilación. procesamiento.AUDIENCIA DEL DOCUMENTO Este documento técnico está dirigido a las personas que desempeñan los roles de Gerente de proyecto y Administrador de pruebas. creada en 1981. así como los provenientes de terceros países y cualquier otro que no sea contrario a la Constitución y la Ley. envío. para poder dar valor a la oferta. con el objeto de aclarar y quitar ambigüedades que pueden generar ciertos términos. de datos personales. . administración. CIFIN: Es una unidad estratégica de la Asociación Bancaria. obtención. financieros. en general. divulgación y transferencia a cualquier título. modificación. dedicada a la recolección. Una parte fundamental de su idea es. precisamente. es parte de una estrategia de negocio centrada en el cliente. de servicios y. CRM. TERMINOLOGÍA Y ACRÓNIMOS A continuación se describen los términos y acrónimos utilizados en el proyecto MEPROC. CRM (Customer Relationship Management): La administración de la relación con los clientes. crediticios. intercambio. La empresa debe trabajar para conocer las necesidades de los mismos y así poder adelantar una oferta y mejorar la calidad en la atención. cualquiera relacionado con el cumplimiento de obligaciones. la de recopilar la mayor cantidad de información posible sobre los clientes. MEPROC: SIGLAS PARA IDENTIFICAR EL PROYE CTO “MEJORAS DEL PRO CESO DE ORIGINACIÓN DE CRÉDITO EN EL BANCO DE LOS ALPES”.

Lista Clinton: La Lista Clinton fue expedida el 21 de octubre de 1995 con el objetivo de bloquear las empresas donde tuvieran intereses los narcotraficantes. Provee Soluciones Integrales a los principales sectores de la economía para la toma de mejores decisiones en el ciclo de otorgamiento de crédito.DATACREDITO: Es la Central de Información Crediticia líder en el mercado andino con presencia en Colombia. Venezuela y Ecuador. Es elaborada por la Oficina de Control de Bienes Extranjeros (Ofac) y hace parte de las medidas tomadas por Estados Unidos en la guerra contra los carteles de la droga y el lavado de activos Prospecto: Cliente potencial para el banco REFERENCIAS LOS SIGUIENTES SON DOCUMENTOS EN LOS QUE SE APOYA ESTE PLAN DE PRUEBAS:     Especificación de Requisitos Documentos de casos de uso Modelo de diseño e implementación Documento de pruebas MISIÓN DE LAS PRUEBAS .

2.1 ANTECEDENTES Como resultado de la planificación y análisis desarrollado para los problemas de estudio de crédito y riesgo del Banco de los Alpes. 2.3 MOTIVADORES DE PRUEBAS - Obtener un grado de calidad en los entregables del proyecto Validar el cumplimiento de los requerimientos funcionales y no funcionales Asegurar la aplicación de métricas y estándares ELEMENTOS A SER PROBADOS Los siguientes entregables se identifican como el objetivo de nuestras pruebas. se obtuvo una arquitectura de solución para el negocio y un plan de tareas a desarrollar para solucionar la problemática planteada. . Estas pruebas también tienen como finalidad verificar la calidad de la solución en su primera versión 2. Estos entregables condujeron a la planificación de pruebas con el fin de validar que la solución y sus funcionalidades son consistentes y acordes a las expectativas del banco.2 MISIÓN DE EVALUACIÓN Las pruebas tienen como finalidad verificar que la solución planteada satisface los requerimientos encontrados en nuestro WBS.

. Pruebas de Aceptación con usuarios: Se revisará la funcionalidad que se implementara de acuerdo a cada rol de usuario.- Administración de Archivos Parametrización Segmentación Validación de Riesgo CRM Estudio de Crédito Servicio al Cliente Sistema Tarjeta Crédito Sistema de Libre Inversión Activación de Tarjetas Generación de Reportes PERSPECTIVA DE LAS PRUEBAS PLANEADAS PERSPECTIVA DE LAS PRUEBAS INCLUIDAS Pruebas Manuales: El objetivo de estas pruebas es asegurar que la funcionalidad de la solución cumple con las expectativas funcionales y la interacción del usuario con el sistema. Estas pruebas serán realizadas por el encargado de pruebas. quien asumirá el rol de cada perfil para la revisión. Estas pruebas serán realizadas por el encargado de pruebas. así como la aceptación de la interfaz de usuario en la medida en que le permita al usuario acceder y navegar a través de toda la funcionalidades y que las interfaces cumplen con estándares de presentación.

Estas pruebas estarán enfocadas en la capacidad de respuesta que tendrá la solución al enfrentarse a situaciones en las que se presente alta concurrencia de usuarios. Estas pruebas serán realizadas por el encargado de pruebas. no se harán los siguientes tipos de pruebas: Pruebas en paralelo. que tendrían como objetivo comparar el comportamiento y funcionalidad de la solución planteada versus el anterior sistema ESTRATEGIA DE PRUEBAS CATÁLOGO DE IDEAS INICIALES Y OTRAS REFERENCIAS . se deberán realizar nuevamente pruebas a todo el módulo con el fin de validar completamente su funcionalidad. PERSPECTIVA DE OTROS CANDIDATOS A SER INCLUIDOS Otras pruebas que podrían ser incluidas son: Pruebas de manejo de requerimientos que tendrían como objetivo validar el cumplimiento de los requerimientos planteados en la WBS Pruebas de manejo de errores.Pruebas de Regresión: Al hacer cambios en una de las partes de un módulo en una versión determinada. Estas pruebas serán realizadas por el encargado de pruebas. que tendrían el objetivo de validar la forma en cómo se están controlando las excepciones arrojadas por los algoritmos del sistema PERSPECTIVAS DE EXCLUSIÓN EN LAS PRUEBAS Como no se tiene conocimiento del sistema que soporta el negocio en la actualidad ni se conoce el entorno en el que se encuentra funcionando. Pruebas de Carga y Stress.

Como principal objetivo se usan técnicas reconocidas para mitigar el impacto de los defectos del software en la operación de la organización. Hojas de Calculo Los datos son persistentes y congruentes en todos los sistemas y se maneja completa trazabilidad de los datos del cliente Tener en cuenta la circular 052 en cuanto a manejo de información Técnica Oráculo: Herramientas requeridas: Criterio de éxito Consideraciones Especiales: PRUEBAS DE FUNCIÓN . En el sector financiero esta clase de errores o impactos son aún más críticos que en cualquier otro sistema. mediante inspección en cada una de las bases de datos de todos los sistemas. para evitar incongruencia en los datos Comandos específicos del motor de bases de datos y consultas SQL que permitan constatar la integridad de los datos Los datos de un cliente son los mismos en todos los sistemas ? Motores de BD. TÉCNICAS Y TIPOS DE PRUEBAS PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS Objetivo de la técnica: Verificar la calidad de los datos. como referencia se va a usar la circular 052 en el manejo de información.

Simulación de todo el proceso en el sistema El sistema simula todo el proceso del negocio con los datos preparados y se obtiene el producto esperado ? Conjunto de datos completos preparados por expertos del área. PRUEBAS DE CICLO DE NEGOCIO Objetivo de la técnica: Verificar el resultado obtenido desde el inicio hasta el final del ciclo del negocio mediante pruebas y simulación de todo el ciclo para asegurar la entrega de productos financieros a la persona correcta.Objetivo de la técnica: Técnica Oráculo: Herramientas requeridas: Criterio de éxito Consideraciones Especiales: Verificar la funcionalidad del sistema usando una serie de procesos o casos de uso que lleven a un resultado esperado Desarrollar casos de uso Los casos de uso se pueden llevar a cabo en el sistema ? Casos de uso El sistema desarrolla los casos de uso con los resultados esperados por el cliente. Sistema a simular proceso completo Técnica Oráculo: Herramientas requeridas: Criterio de éxito Simulación llevada desde el inicio en que llegan los archivos hasta que se le entrega un producto al cliente dentro de los parámetros definidos .

Preguntar al usuario si los casos de uso son comprensibles dentro de los limites de la apliacion. PRUEBAS DE DESEMPEÑO Objetivo de la técnica: Asegurar el uso adecuado de recursos mediante indicadores para que no se presenten demoras excesivas en los procesos.Consideraciones Especiales: PRUEBAS DE INTERFAZ DE USUARIO Objetivo de la técnica: Técnica Oráculo: Asegurar la facilidad de manejo de la interfaz navegando con los casos de uso y que estos sean compresibles para el usuario. La navegación de los casos de uso es comprensible por el usuario ? Herramientas requeridas: El Usuario Casos de Uso Sistema con Interfaz Grafica Criterio de éxito Consideraciones Especiales: El usuario comprende el caso de uso plasmado en el sistema. .

Técnica Oráculo: Herramientas requeridas: Ejecución de script de prueba en horas pico La aplicación puede procesar X número de clientes en un rango de tiempo Y permitirle ? Scripts de Prueba Datos completos Criterio de éxito Consideraciones Especiales: Clientes procesados dentro de un rango de tiempo aceptable Realizar este tipo de prueba en horas pico para el sistema PRUEBAS DE CARGA Objetivo de la técnica: Asegurar la disponibilidad del sistema usando cantidades esperadas de usuarios para que el sistema esté en línea y no allá represamientos. Datos de clientes esperados Técnica Oráculo: Herramientas requeridas: Criterio de éxito El sistema procesa los clientes sin cuellos de botella . Se realizó una prueba experimental con un número de peticiones esperadas y se monitorea el uso de recursos Existe un cuello de botella en el procesamiento de los clientes ? Indicadores de desempeño por cada recurso usado.

El sistema responde adecuadamente cuando la carga real supera a la esperada ? Datos de clientes Indicadores de desempeño de los recursos Técnica Oráculo: Herramientas requeridas: Criterio de éxito Consideraciones Especiales: El sistema puede manejar una carga mayor a la esperada y se tiene un plan de acción para este caso. Prueba iterativa realizando cada vez el doble de información a procesar por el sistema. PRUEBAS DE VOLUMEN .Consideraciones Especiales: PRUEBAS DE STRESS Objetivo de la técnica: Determinar el límite máximo de clientes que se pueden procesar doblando la cantidad cada vez para tener un procedimiento que permite al sistema reaccionar adecuadamente.

Objetivo de la técnica: Técnica Oráculo: Herramientas requeridas: Verificar que la aplicación funciona adecuadamente determinando la cantidad máxima de datos y la carga máxima Usar un máximo de base de datos y clientes usando los mismos procesos en un periodo de tiempo extenso Cuando el sistema llega al límite de almacenamiento se procede con un plan alterno ? Base de datos limitada Múltiples Usuarios Criterio de éxito Consideraciones Especiales: Se ha alcanzado el límite del sistema sin que el sistema falle. PRUEBAS DE SEGURIDAD Y CONTROL DE ACCESO Objetivo de la técnica: Asegurar que la información no sea accedida por personal no autorizado usando perfiles y encriptaciones de datos para no llegar al fraude Ingresar con diferentes roles e intentar acceder a información no autorizada La información puede ser accedida por alguien que no está autorizado ? SQL-Injection Cross Scripting Técnica Oráculo: Herramientas requeridas: .

ni acceso a información crítica por personal no autorizado PRUEBAS DE TOLERANCIA A FALLAS Objetivo de la técnica: Técnica Oráculo: Herramientas requeridas: Aceptar los fallos dentro de los parámetros fijados para cada proceso dentro del sistema Inducir un fallo en los distintos procesos y evaluar la criticidad y tipo de tolerancia del mism El sistema ante un fallo tiene una tolerancia dentro de los parámetros ¿ Sistemas de control y recuperación de errores Hardware Excepciones Criterio de éxito Consideraciones Especiales: El sistema llego a una toleración total en los procesos críticos y degradación aceptable en los no tan criticos PRUEBAS DE CONFIGURACIÓN .Otras herramientas para acceder a la información Criterio de éxito Consideraciones Especiales: El sistema no ha tenido accesos no autorizados.

navegador. sistema operativo El sistema en diferentes configuraciones se comporta adecuadamente PRUEBAS DE INSTALACIÓN Objetivo de la técnica: Técnica Realizar ejecución en sistemas con software y hardware de mínimos prestaciones Oráculo: Herramientas requeridas: Se sabe cuáles son los requisitos mínimos para ejecutar la aplicación? Hardware de mínimas prestaciones Software de versiones antiguas Criterio de éxito El sistema corre adecuadamente con los recursos mínimos de hardware y software Determinar requisitos mínimos de software y hardware para la correcta ejecución de la aplicación .Objetivo de la técnica: Técnica Oráculo: Herramientas requeridas: Criterio de éxito Consideraciones Especiales: Evaluar variaciones de la aplicación cambiando valores de configuración para descubrir nuevos errores. Cambiar la configuración del sistema en software y hardware El sistema con otros parámetros a los de desarrollo se comporta adecuadamente? Cambios de resolución.

y que influya en el resultado NO exitoso de la ejecución de los demás casos de prueba.Consideraciones Especiales: CRITERIO DE ENTRADA Y SALIDA PLAN DE PRUEBAS CRITERIO DE ENTRADA AL PLAN DE PRUEBAS Basado en los casos de prueba. CRITERIO DE SUSPENSIÓN DEL PLAN DE PRUEBAS Las pruebas serán suspendidas en caso de presentarse alguna de las siguientes situaciones:      Los prerrequisitos no se encuentran disponibles. NO se cuenta con datos significativos. NO se encuentra disponible(Pruebas de Integridad) NO disponibilidad de los recursos responsables de la ejecución de la prueba. se identifican las entradas y prerrequisitos especificados. Esta eventualidad será documentada y presentada ante el respectivo comité de pruebas. CRITERIO DE SALIDA AL PLAN DE PRUEBAS Basado en los casos de prueba. Si en alguno de los casos de prueba se detecta un defecto crítico. Si alguno de los sistemas involucrados. . eventos y resultados esperados. se identifican las salidas. que afecta el desempeño de la funcionalidad y/o del módulo/sistema.

ENTREGABLES Se describirán los resultados del proceso de prueba en términos de cobertura de los requerimientos. para los cuales el insumo principal será un lote de pruebas que previamente debe haber sido preparado por los responsables de ejecutar las pruebas. para cada escenario se especifica el resultado esperado teniendo en cuenta las entradas ingresadas en el caso de prueba. código y del análisis de defectos RESUMEN DE EVALUACIÓN DE PRUEBAS EL PROCESO DE PRUEBA SE DEBE HABER APLICADO SEGÚN LO DEFINIDO EN EL PLAN DE PRUEBAS. con su respectiva clasificación. • Si en alguno de los casos de prueba se detecta un defecto crítico. que afecta el desempeño de la funcionalidad y/o del módulo/sistema. y que influya en el resultado NO exitoso de la ejecución de los demás casos de prueba. MEDIANTE EL INFORME DE PRUEBAS SE: . CRITERIO DE SALIDA DEL CICLO En el lote de pruebas. deberá ser documentado y reportado como un defecto.CICLO DE PRUEBAS CRITERIO DE ENTRADA AL CICLO Se identifican los casos objeto de las pruebas. TERMINACIÓN DEL CICLO ANORMAL Cada resultado NO esperado en la ejecución del lote de pruebas.

EVALÚA LA ACEPTABILIDAD DEL PROCESO DE PRUEBAS LLEVADO A CABO. • IDENTIFICA QUÉ MEJORAS SE PUEDEN REALIZAR EN EL PROCESO DE PRUEBA PARA INCREMENTAR LA COBERTURA Y/O CALIDAD DE LAS PRUEBAS.• • EVALÚA QUE EL COMPORTAMIENTO DEL SISTEMA QUE SE HA DESARROLLADO ES CORRECTO. De todos los casos de prueba ejecutados cuántos se han completado debido a errores de software. Se muestran los casos de prueba definidos que se han llevado a cabo. LOGS DE INCIDENTES Y CONTROL DE CAMBIOS Se detallan el número de defectos detectados en la ejecución de los casos de pruebas. Los controles de cambios son documentados y priorizados según el impacto en las funcionalidades requeridas. muestra el porcentaje de casos ejecutados sin error. También se resumen los resultados obtenidos en el proceso de análisis de defectos . Se realizará un gráfico que refleje lo siguiente: Porcentaje de casos de prueba desarrollados REPORTES DE CALIDAD PERCIBIDA Avance de Efectividad. Cada uno de los defectos es clasificado y priorizado para realizar la corrección. REPORTE DE CUBRIMIENTO DE PRUEBAS Visualizará la cantidad de pruebas planeadas por caso de uso. cuántos han fallado.

muestra la cantidad de defectos encontrados. . Estado del defecto (registrado. Fuente del defecto (el componente donde reside el fallo o problema). probado y terminado). asignado. Se generan los siguientes reportes: Gráfico de Tipos de defectos.DENSIDAD DE DEFECTOS Se considerarán los siguientes conceptos: • • • Tipos de defectos según su gravedad (crítico. arreglado. medio y bajo). alto.

Tipos de defectos 1 10 5 Crítico Alto Medio Bajo 20 Gráfico de Fuentes de defectos .

Fuentes de defectos 15 10 5 0 c-abx c-xxx c-eww c-ppl c-koi Componente Gráfico de Estado de los defectos. .

.Estado de los defectos Número de defectos 14 12 10 8 6 4 2 0 Estado TENDENCIA DE DEFECTOS Muestra la tendencia de aparición de defectos según el tiempo de desarrollo.

Tendencia de defectos 16 14 12 10 8 6 4 2 0 1 2 3 4 5 Tiempo (Semanas de prueba) Defectos encontrados TIEMPO DE CORRECCIÓN DE DEFECTOS Grafico de Tiempo de corrección de defectos .

Tiempo de corrección de defectos Número de defectos 25 20 15 10 5 0 >30 días 20-30 días 10-20 días 5-10 días < 5 días Tiempo de corrección PRUEBAS AUTOMATIZADAS Y SOPORTE DE SCRIPT DE PRUEBAS Se documentarán las pruebas realizadas con las herramientas de automatización de testing. PRODUCTOS ADICIONALES DE TRABAJO MATRICES DE TRAZABILIDAD . el insumo serán los scripts desarrollados/configurado para la ejecución de la prueba.

ASOCIADO AL CASO DE PRUEBA OBJETIVO DEL CASO DE PRUEBA NO PASO DESCRIPCIÓN DEL PASO RESULTADOS ESPERADO CONDICIONES DE ENTRADA MEDIO DE VALIDACIÛN ESTADO FECHA FINAL DOCUMENTACIÓN RELACI ONADO EJECUTOR . ASOCIADO AL CASO DE PRUEBA DESCRIPCIÓN REQ.                     ID CASO DE PRUEBA NOMBRE DEL CASO DE P RUEBA APLICACIÓN MODULO VERSIÓN PRIORIDAD TIPO DE PRUEBA DESCRIPCIÓN CASO DE PRUEBA CRITERIOS DE ACEPTACIÛN ID REQ.

procesador Dual core o superior y tarjeta wireless y Ethernet.NECESIDADES DE AMBIENTE HARDWARE DE BASE DEL SISTEMA La siguiente tabla define los requerimientos de sistema para el esfuerzo presentado en este plan de pruebas. Se prevee dos máquina para virtualizar los ambientes usados durante el ciclo de desarrollo ELEMENTOS DE SOFTWARE BASE EN EL AMBIENTE DE PRUEBAS El siguiente software base es requerido en el ambiente de prueba de este Plan de Pruebas. Recursos de Sistema Recurso Computadores portátiles para todo el equipo del proyecto 6 Cantidad Nombre y Tipo Notebooks con mínimo las siguientes características: 320 Gb Hd. 2Gb memoria. . 1 Servidor con por lo menos 300Gb de almacenamiento Servidor Para virtualización de ambientes 2 Pendiente por definir disponibilidad de elementos existentes en el banco. Servidor para repositorio de documentación y manejo de versiones.

4. ESB.1 2.5 8. permite desarrollo de soluciones SOAP.4.Nombre de Elemento de Software Suite JavaCAPS de sun JDK JMeter Load Runner Processdash CRM Sistema Tarjetas de credito Sistema Créditos Toad Version 6.Mercuty Apache Microsoft Dotproject.5 o superior 2.org Versión 2007 3.4. BPEL 10.11 Pruebas de Carga Pruebas funcionales PSP Tipo Servidor de aplicaciones. Categoría Administración de pruebas Seguimiento de defectos Herramienta de automatización de pruebas funcionales Herramienta de automatización de pruebas de carga Monitor de cubrimiento de pruebas Administración de proyecto Herramientas DBMS Nombre de Herramienta Excel Bugzilla Load runner / soapui Jmeter Excel dotproject Toad y/o QueryBrowser for mysql y/o MsManager Vendedor Microsoft Bugzilla.1 Administrador de base de datos.2 1.2 .1 1.1. Por confirmar las bases de datos utilizadas en el diseño final HERRAMIENTAS DE PRODUCTIVIDAD Y SOPORTE Las siguientes herramientas son utilizadas para soportar el proceso de pruebas de este plan.1 2007 2.1 8.org HP .

CONFIGURACIONES DE AMBIENTE DE PRUEBAS Las siguientes configuraciones necesitan ser proveídas y soportadas para el proyecto. Nombre de Configuración Ambiente de Desarrollo Ambiente de pruebas funcionales Ambiente de pruebas Integrales Ambiente de pruebas de homologación Ambiente productivo Descripción Ambiente para el desarrollo de las soluciones Ambiente para el desarrollo de las pruebas funcionales de las aplicaciones Ambiente para probar las interacciones con los sistemas ya existentes El propósito de este ambiente es realizar pruebas con máquinas muy similares a las maquinas productivas y entrenar los procedimientos de paso a producción Implementado en configuración física Virtualizado Virtualizado Virtualizado RESPONSABILIDADES Y NECESIDADES DE ENTRENAMIENTO PERSONAS Y ROLES Esta tabla muestra las suposiciones de roles y personas para el esfuerzo de pruebas. .

 Informar de la gestión.  Recuperar los errores. Se realizarán capacitaciones internas de las herramientas ‘de control (Bugzilla. Evaluar y probar las herramientas necesarias para cada caso de prueba definido. load runner. loadrunner. Diseñador de prueba 3 Identificar. Responsabilidades:  Instalar herramientas a usar. Implementador NECESIDADES DE STAFF Y ENTRENAMIENTO Se requiere capacitación tecnológica y funcional de las herramientas: CRM.  Adquirir los recursos apropiados.  Diseñar los Casos de prueba. Probador (Tester) 3 Ejecutar las pruebas. priorizare implementar los casos de prueba. Responsabilidades:  Generar el Plan de pruebas.  Evaluar el esfuerzo de prueba. etc…) a las personas qu e no estén familiarizados con dichas herramientas .Recursos Humanos Rol Gestor de prueba Mínimo recursos 1 Responsabilidades específicas Proporcionar una gestión adecuada.  Si es necesario.  Documentar los defectos. Responsabilidades:  Proporcionar una dirección técnica. capacitar a los ejecutores de las pruebas en las herramientas a usar. Sistemas Actuales del Banco los Alpes. Responsabilidades:  Ejecutar pruebas. dotproject.

10. HITOS DE ITERACIÓN Hito Plan de iteración acordado Inicio iteración Línea de base requerimientos Línea de base arquitectura Línea de base interfaz de usuario Primer build para pruebas Primer build aceptado para pruebas Ciclo de primer build finalizado Segundo build para pruebas Segundo build aceptado para pruebas Ciclo de segundo build finalizado Revisión de evaluación de iteración Final de iteración Fecha de Inicio planeada 26 de febrero 27 de febrero 27 de febrero 27 de febrero 18 de Abril 18 de Abril 25 de Abril 2 de mayo Junio 5 Junio 19 Junio 26 Julio 10 Julio 24 Fecha de inicio real Fecha final planeada 10 de Mayo 10 de Mayo 29 de febrero 27 de febrero 10 de Mayo 25 de Abril 10 de mayo 10 de mayo Junio 12 Junio 26 Julio 3 Julio 24 Julio 31 Fecha final real .

SUPOSICIONES Y RESTRICCIONES Riesgo Falta de tiempo Estrategia de mitigación Aplicar al cronograma planteado inicialmente una adición de tiempo equivalente al 10% sobre el tiempo inicialmente pactado Dar prioridad a errores funcionales y bloqueantes que impidan la continuación de las pruebas Para el caso en que algún probador ejecute mal un plan de pruebas. se debe contar con un segundo probador que valide la correcta aplicación de las estrategias de pruebas.Hito Tercero build para pruebas Tercero build aceptado para pruebas Tercer ciclo del build finalizado Revisión de evaluación de iteración Final de iteración Fecha de Inicio planeada Agosto 7 Septiembre 4 Octubre 2 Noviembre 6 Noviembre 27 Fecha de inicio real Fecha final planeada Agosto 28 Septiembre 25 Octubre 23 Noviembre 20 Diciembre 11 Fecha final real 11. en puntos aleatorios. RIESGOS. DEPENDENCIAS. Contingencia Contratar más recursos Atrasos en corrección de errores Plan de Pruebas deficiente Contratar más personal de pruebas Negociar previamente una adición de un 10% más de tiempo a la fase de pruebas inicialmente planeada .

JARC Datos de pruebas suficientes Grupo .JARC .JARC Incurrir en sanciones por efectos de utilización de software pirata Herramientas con funcionalidades limitadas o nulas Herramientas con fecha de caducidad Grupo .Suposición a ser probada El ambiente de pruebas debe contar con las especificaciones mínimas de hardware y software Requerimientos funcionales depurados y consistentes - Impacto de suposición incorrecta Pruebas deficientes Caídas frecuentes Atrasos en el cronograma Pruebas inconsistentes Atrasos en el cronograma Redefinición de requerimientos Cambios en otros módulos del sistema Inversión de tiempo en la generación de datos de prueba Atraso en el cronograma Inconsistencia en las pruebas Dueños Area de tecnología Grupo .JARC Dueños - Atrasos en el cronograma Grupo .JARC Restricciones La fecha límite para la finalización del plan de pruebas es la primera semana del mes de Noviembre de 2010 El máximo número de recursos disponibles para pruebas es de 6 Utilización de herramientas libres y/o licenciadas - Impacto de la restricción Iniciar a tiempo el paso a producción de la solución Incumplimiento en la entrega del proyecto Grupo .

CONTENDRÁN LOS SIGUIENTES ATRIBUTOS:          Nombre Propósito Método de aplicación Medida. formula y computo de datos Interpretación del valor medido Tipo de escala Tipo de medida Fuente de medición Audiencia A su vez cada métrica será clasificado u organizada bajo los grupos de:  Métricas de Funcionalidad o Adecuidad o Exactitud o Interoperabilidad o Seguridad o Conformidad de la funcionalidad  Métricas de Fiabilidad o Madurez o Tolerancia a fallos o Recuperabilidad o Conformidad de la fiabilidad .PROCEDIMIENTO DE ADMINISTRACIÓN MÉTRICAS Y EVALUACIÓN DE LAS PRUEBAS LAS MÉTRICAS A TENER EN CUENTA PARA EL PROYECTO MEPROC.

 Métricas de Eficiencia o Comportamiento en el tiempo o Utilización de recursos o Conformidad de la eficiencia  Métricas de Mantenibilidad o Analizabilidad o Cambiabilidad o Estabilidad o Examinabilidad o Conformidad de la matenibilidad VALORACIÓN DE LOS ENTREGABLES DE ESTE PLAN DE PRUEBAS      Código y resultados de pruebas en la fase de codificación Producto y resultado de pruebas en la fase de integración de software Sistema integrado y resultado de pruebas en la fase integración del sistema Sistema instalado en la fase de instalación Producto entregado en la fase de aceptación REPORTE DE PROBLEMAS. verificando los resultados semanalmente. el equipo de pruebas debe examinar tendencias en las ocurrencias de los problemas. . ESCALA Y SOLUCIÓN DE PUNTOS El equipo de pruebas debe monitorear y controlar el cumplimiento de los procedimientos definidos para las pruebas. Además.

6 con más detalle. Las principales tareas del grupo de pruebas para la fase de diseño arquitectónico son: revisar los documentos en conformidad al estándar. con la ayuda de los integrantes de las demás áreas involucradas en el proyecto.Los problemas que se encuentren en el proceso serán documentados y al igual que los problemas se documentaran las soluciones de estos. revisar los procedimientos desarrollados y revisar los procesos de las gerencias en conformidad al estándar y a los planes de procedimientos definidos por ellos. ADMINISTRACIÓN DE CICLOS DE PRUEBAS El grupo de pruebas esta orientado a determinar si el producto en desarrollo cumple con los procedimientos detallados por las gerencias del proyecto. Finalmente. toda la organización del proyecto MEPROC. el proceso de pruebas estará a cargo de la persona asignada para el rol de Administrador de pruebas. ESTRATEGIA DE TRAZABILIDAD Para la realización de la estrategia de la trazabilidad se tendrá en cuenta la matriz de trazabilidad. y controlar así en todo momento la cobertura de los requisitos de negocio a medida que se va avanzando en la ejecución de las pruebas. también se definen los roles. esta matriz se define en el numeral 7. En este documento. El administrador de pruebas será supervisado por los encargados de la gerencia del proyecto. se encuentra definida en el WBS. y si se acopla al estándar utilizado. En el proyecto MEPROC. responsabilidades y tareas de todos los integrantes del proyecto. el proceso que se seguirá para alcanzar la resolución de dichos problemas será el ir identificando cada uno de los problemas y aplicar las medidas necesarias para la solución de estos. el cual permite asociar los casos de pruebas con los requisitos propios para las pruebas. Estas tareas de aseguramiento de la calidad serán desarrolladas por el administrador de pruebas del proyecto. .

Gerente de proyecto: ECOS Jefe de pruebas: Carlos Javier Criales Cardozo . Al finalizar esta fase se entregará un informe resumido de las pruebas.APROBACIÓN Y TERMINACIÓN La fase de aprobación será aprobada por el gerente de proyecto con el administrador de pruebas de pruebas (jefe de pruebas).

Sign up to vote on this title
UsefulNot useful