P. 1
Plan de Prueba s Ejemplo

Plan de Prueba s Ejemplo

|Views: 4|Likes:
Publicado porLuz Delia

More info:

Published by: Luz Delia on Apr 26, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

07/17/2015

pdf

text

original

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

.......................................... Terminación del ciclo anormal 24 24 7......Densidad de defectos 7..........................2 ..........................................................6.......................3 .......... Evalúa la aceptabilidad del proceso de pruebas llevado a cabo............................................................. Evalúa que el comportamiento del sistema que se ha desarrollado es correcto............... 25 7....1 ......... 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.......... Tendencia de defectos 26 29 ...................1 ................................1 ........................ 24 • .........4..4 .....3 .......................................1............... Criterio de Suspensión del Plan de Pruebas 6........................4.....................................................Ciclo de Pruebas 6........................................ Criterio de Entrada al ciclo 23 24 24 Se identifican los casos objeto de las pruebas................................................ Reporte de cubrimiento de pruebas 7............................. 24 6.... Criterio de Salida del ciclo 6........... 24 Mediante el informe de pruebas se: ...2...2 ....................2....................................... 25 25 •Identifica qué mejoras se pueden realizar en el proceso de prueba para incrementar la cobertura y/o calidad de las pruebas.......................... Cada uno de los defectos es clasificado y priorizado para realizar la corrección............................................. • .................................. ......... Entregables 24 24 7...............3 .............................2 .......................... 25 7.................. Resumen de evaluación de pruebas El proceso de prueba se debe haber aplicado según lo definido en el Plan 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............2 ..................2........................................................................ Los controles de cambios son documentados y priorizados según el impacto en las funcionalidades requeridas................. Reportes de Calidad Percibida 7..................................

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

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

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

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

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

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

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.2 MISIÓN DE EVALUACIÓN Las pruebas tienen como finalidad verificar que la solución planteada satisface los requerimientos encontrados en nuestro WBS. 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. 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.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.

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. .- 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. 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 serán realizadas por el encargado de pruebas.

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

como referencia se va a usar la circular 052 en el manejo de información. mediante inspección en cada una de las bases de datos de todos los sistemas. En el sector financiero esta clase de errores o impactos son aún más críticos que en cualquier otro sistema. 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. 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.

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

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. Preguntar al usuario si los casos de uso son comprensibles dentro de los limites de la apliacion. 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.

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

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

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

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. para los cuales el insumo principal será un lote de pruebas que previamente debe haber sido preparado por los responsables de ejecutar las pruebas. deberá ser documentado y reportado como un defecto. TERMINACIÓN DEL CICLO ANORMAL Cada resultado NO esperado en la ejecución del lote de pruebas. 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. MEDIANTE EL INFORME DE PRUEBAS SE: .CICLO DE PRUEBAS CRITERIO DE ENTRADA AL CICLO Se identifican los casos objeto de las pruebas. ENTREGABLES Se describirán los resultados del proceso de prueba en términos de cobertura de los requerimientos. para cada escenario se especifica el resultado esperado teniendo en cuenta las entradas ingresadas en el caso de prueba. y que influya en el resultado NO exitoso de la ejecución de los demás casos de prueba. CRITERIO DE SALIDA DEL CICLO En el lote de pruebas.

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

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

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.

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

BPEL 10.1 1.1 8. 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. 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.4. permite desarrollo de soluciones SOAP.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 o superior 2.2 1.1 2.2 .1 Administrador de base de datos.4.org HP . ESB.4.org Versión 2007 3.1 2007 2.5 8.11 Pruebas de Carga Pruebas funcionales PSP Tipo Servidor de aplicaciones.Mercuty Apache Microsoft Dotproject.1.

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.

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

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 .

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

JARC Datos de pruebas suficientes 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 .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 Dueños - Atrasos en el cronograma 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 .

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. CONTENDRÁN LOS SIGUIENTES ATRIBUTOS:          Nombre Propósito Método de aplicación Medida.

verificando los resultados semanalmente. 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. . 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. el equipo de pruebas debe examinar tendencias en las ocurrencias de los problemas.

El administrador de pruebas será supervisado por los encargados de la gerencia del proyecto. y si se acopla al estándar utilizado. también se definen los roles. En este documento. Finalmente.Los problemas que se encuentren en el proceso serán documentados y al igual que los problemas se documentaran las soluciones de estos. 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. toda la organización del proyecto MEPROC. Estas tareas de aseguramiento de la calidad serán desarrolladas por el administrador de pruebas del proyecto. En el proyecto MEPROC. . se encuentra definida en el WBS. el cual permite asociar los casos de pruebas con los requisitos propios para las pruebas.6 con más detalle. el proceso de pruebas estará a cargo de la persona asignada para el rol de Administrador de pruebas. 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. esta matriz se define en el numeral 7. con la ayuda de los integrantes de las demás áreas involucradas en el 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. ESTRATEGIA DE TRAZABILIDAD Para la realización de la estrategia de la trazabilidad se tendrá en cuenta la matriz de trazabilidad. responsabilidades y tareas de todos los integrantes del proyecto. 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. 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.

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->