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

.... • ...............................2 ............................. Terminación del ciclo anormal 24 24 7.2 .............4..................2........2 .......1 ..........Densidad de defectos 7.......................................... Cada uno de los defectos es clasificado y priorizado para realizar la corrección................................................................3 ..... .. 24 • ..........3 ..........................................2................................................................................... Tendencia de defectos 26 29 .....4......................................... Reportes de Calidad Percibida 7........................................ 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.................................................1........................... 24 6........ Los controles de cambios son documentados y priorizados según el impacto en las funcionalidades requeridas.............. para los cuales el insumo principal será un lote de pruebas que previamente debe haber sido preparado por los responsables de ejecutar las pruebas...................................................................................... Criterio de Salida del ciclo 6............ 24 Mediante el informe de pruebas se: .....Ciclo de Pruebas 6..... Resumen de evaluación de pruebas El proceso de prueba se debe haber aplicado según lo definido en el Plan de Pruebas.....................................................................6........ 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...........................................3 ......................... 25 7............................2 ............ Entregables 24 24 7... Reporte de cubrimiento de pruebas 7................................4 ........ ...1 ............................................................................... Evalúa que el comportamiento del sistema que se ha desarrollado es correcto...............................2...........1 ............. 25 7............................................................................. Evalúa la aceptabilidad del proceso de pruebas llevado a cabo... Criterio de Suspensión del Plan de Pruebas 6.......

..........5 .6........................1 .......................... Productos adicionales de Trabajo 7....................................................4............................................................................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 ....................6 .................. Tiempo de corrección de defectos 7.............. 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.... Pruebas automatizadas y soporte de script de pruebas 7.. asociado al Caso de prueba  Descripción Req........3 ...............

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

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

. Definir el alcance del plan de pruebas.INTRODUCCIÓN Este es un documento fundamental para que la fase de pruebas sean lo más exitosa posible. Validar que el cumplimiento de las reglas en el proceso del estudio de crédito. 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. Identificar los recursos tecnológicos y/o humanos que serán parte de las pruebas. Determinar el esfuerzo requerido para la realización de las pruebas. 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. Validar que el proceso de estudio de crédito se soporte en las regulaciones del sector financiero BASILEA II y SOX. además de generar un producto de alta calidad.     Validar el proceso de recepción de los archivos entregados por los proveedores. Definir las técnicas de pruebas a utilizar durante el desarrollo del proyecto MEPROC. 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. Validar la consistencia de los datos del cliente en los diferentes sistemas del banco.

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

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. 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. 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 . Venezuela y Ecuador.DATACREDITO: Es la Central de Información Crediticia líder en el mercado andino con presencia en Colombia.

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 MISIÓN DE EVALUACIÓN Las pruebas tienen como finalidad verificar que la solución planteada satisface los requerimientos encontrados en nuestro WBS. se obtuvo una arquitectura de solución para el negocio y un plan de tareas a desarrollar para solucionar la problemática planteada. 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. Estas pruebas también tienen como finalidad verificar la calidad de la solución en su primera versión 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.

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.- 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. quien asumirá el rol de cada perfil para la revisión. . Pruebas de Aceptación con usuarios: Se revisará la funcionalidad que se implementara de acuerdo a cada rol de usuario. Estas pruebas serán realizadas por el encargado de pruebas.

Estas pruebas serán realizadas por el encargado de pruebas. Estas pruebas serán realizadas por el encargado de pruebas.Pruebas de Regresión: Al hacer cambios en una de las partes de un módulo en una versión determinada. 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. 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. no se harán los siguientes tipos de pruebas: Pruebas en paralelo. Pruebas de Carga y Stress. se deberán realizar nuevamente pruebas a todo el módulo con el fin de validar completamente su funcionalidad. 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 . 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.

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 .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. 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.

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 .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. 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. 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.

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. .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. 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.

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. Datos de clientes esperados Técnica Oráculo: Herramientas requeridas: Criterio de éxito El sistema procesa los clientes sin cuellos de botella .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.

PRUEBAS DE VOLUMEN . Prueba iterativa realizando cada vez el doble de información a procesar por el sistema.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. 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.

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: .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.

Otras herramientas para acceder a la información Criterio de éxito Consideraciones Especiales: El sistema no ha tenido accesos no autorizados. 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 .

navegador.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. 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 . 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. Esta eventualidad será documentada y presentada ante el respectivo comité de pruebas. NO se cuenta con datos significativos.Consideraciones Especiales: CRITERIO DE ENTRADA Y SALIDA PLAN DE PRUEBAS CRITERIO DE ENTRADA AL PLAN DE PRUEBAS Basado en los casos de prueba. que afecta el desempeño de la funcionalidad y/o del módulo/sistema. se identifican las salidas. se identifican las entradas y prerrequisitos especificados. Si en alguno de los casos de prueba se detecta un defecto crítico. eventos y resultados esperados. Si alguno de los sistemas involucrados. NO se encuentra disponible(Pruebas de Integridad) NO disponibilidad de los recursos responsables de la ejecución de la 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. CRITERIO DE SALIDA AL PLAN DE PRUEBAS Basado en los casos de prueba.

CRITERIO DE SALIDA DEL CICLO En el lote 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. TERMINACIÓN DEL CICLO ANORMAL Cada resultado NO esperado en la ejecución del lote de pruebas. deberá ser documentado y reportado como un defecto. y que influya en el resultado NO exitoso de la ejecución de los demás casos de prueba.CICLO DE PRUEBAS CRITERIO DE ENTRADA AL CICLO Se identifican los casos objeto de las pruebas. que afecta el desempeño de la funcionalidad y/o del módulo/sistema. 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. • Si en alguno de los casos de prueba se detecta un defecto crítico. con su respectiva clasificación. para cada escenario se especifica el resultado esperado teniendo en cuenta las entradas ingresadas en el caso de prueba. ENTREGABLES Se describirán los resultados del proceso de prueba en términos de cobertura de los requerimientos. MEDIANTE EL INFORME DE PRUEBAS SE: .

• • EVALÚA QUE EL COMPORTAMIENTO DEL SISTEMA QUE SE HA DESARROLLADO ES CORRECTO. EVALÚA LA ACEPTABILIDAD DEL PROCESO DE PRUEBAS LLEVADO A CABO. REPORTE DE CUBRIMIENTO DE PRUEBAS Visualizará la cantidad de pruebas planeadas por caso de uso. muestra el porcentaje de casos ejecutados sin error. De todos los casos de prueba ejecutados cuántos se han completado debido a errores de software. • IDENTIFICA QUÉ MEJORAS SE PUEDEN REALIZAR EN EL PROCESO DE PRUEBA PARA INCREMENTAR LA COBERTURA Y/O CALIDAD DE LAS PRUEBAS. También se resumen los resultados obtenidos en el proceso de análisis de defectos . Cada uno de los defectos es clasificado y priorizado para realizar la corrección. Se muestran los casos de prueba definidos que se han llevado a cabo. Se realizará un gráfico que refleje lo siguiente: Porcentaje de casos de prueba desarrollados REPORTES DE CALIDAD PERCIBIDA Avance de Efectividad. cuántos han fallado. 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.

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

PRODUCTOS ADICIONALES DE TRABAJO MATRICES DE TRAZABILIDAD . el insumo serán los scripts desarrollados/configurado para la ejecución de la prueba.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.

ASOCIADO AL CASO DE PRUEBA DESCRIPCIÓN REQ. 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 .                     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.

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. procesador Dual core o superior y tarjeta wireless y Ethernet. 2Gb memoria. Servidor para repositorio de documentación y manejo de versiones. 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.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. .

ESB.1 Administrador de base de datos.1 8.11 Pruebas de Carga Pruebas funcionales PSP Tipo Servidor de aplicaciones. permite desarrollo de soluciones SOAP. 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.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.5 8. BPEL 10.4.Mercuty Apache Microsoft Dotproject.5 o superior 2.1.2 .2 1.1 2.1 2007 2.4.org HP .4.org Versión 2007 3. 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 1.

. 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.CONFIGURACIONES DE AMBIENTE DE PRUEBAS Las siguientes configuraciones necesitan ser proveídas y soportadas para el proyecto.

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

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 .10.

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. 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. 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 . DEPENDENCIAS. RIESGOS. se debe contar con un segundo probador que valide la correcta aplicación de las estrategias de pruebas.

JARC .JARC Datos de pruebas suficientes 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 Incurrir en sanciones por efectos de utilización de software pirata Herramientas con funcionalidades limitadas o nulas Herramientas con fecha de caducidad 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 .

PROCEDIMIENTO DE ADMINISTRACIÓN MÉTRICAS Y EVALUACIÓN DE LAS PRUEBAS LAS MÉTRICAS A TENER EN CUENTA PARA EL PROYECTO MEPROC. 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 . CONTENDRÁN LOS SIGUIENTES ATRIBUTOS:          Nombre Propósito Método de aplicación Medida.

. el equipo de pruebas debe examinar tendencias en las ocurrencias de los problemas. Además. ESCALA Y SOLUCIÓN DE PUNTOS El equipo de pruebas debe monitorear y controlar el cumplimiento de los procedimientos definidos para las pruebas. 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.

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. se encuentra definida en el WBS. En este documento.6 con más detalle. En el proyecto MEPROC. Finalmente. El administrador de pruebas será supervisado por los encargados de la gerencia del proyecto. con la ayuda de los integrantes de las demás áreas involucradas en el proyecto. 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 cual permite asociar los casos de pruebas con los requisitos propios para las pruebas. . 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. 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. Las principales tareas del grupo de pruebas para la fase de diseño arquitectónico son: revisar los documentos en conformidad al estándar. esta matriz se define en el numeral 7. y si se acopla al estándar utilizado. ESTRATEGIA DE TRAZABILIDAD Para la realización de la estrategia de la trazabilidad se tendrá en cuenta la matriz de trazabilidad. 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. Estas tareas de aseguramiento de la calidad serán desarrolladas por el administrador de pruebas del proyecto.Los problemas que se encuentren en el proceso serán documentados y al igual que los problemas se documentaran las soluciones de estos.

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). Gerente de proyecto: ECOS Jefe de pruebas: Carlos Javier Criales Cardozo . Al finalizar esta fase se entregará un informe resumido de las pruebas.

Sign up to vote on this title
UsefulNot useful