Bags Inic Plandepruebas

EASY Software & Innovation
Gestin Solicitudes Banco de Los Alpes

Plan de Pruebas
Versin 1.0
Plan de Pruebas
Fecha: 19-05-2009
Pgina 2 de 21
Historial de Revisin
Fecha Versin Descripcin Creacin del documento Autor Equipo EASY Software & Innovation NATHALY CAROLINA GONZLEZ MONTENEGRO Cdigo: 200910019 FERNANDO ANDRS BERNATE HEREDIA Cdigo: 200913532 ANDRS MAURICIO RAMOS BONILLA Cdigo: 200918340 NSTOR ARMANDO BOHRQUEZ SALDANA Cdigo: 200918290
19/05/2009
1.0
Confidencial
EASY Software & Innovation, 2013
Page 2
Plan de Pruebas
Fecha: 19-05-2009
Pgina 3 de 21
Tabla de Contenido
1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Audiencia 1.4 Referencias 5 5 5 6 6
2. Misin de las Pruebas 7 2.1 Contexto del Proyecto y Antecedentes 7 Se pretende realizar un levantamiento y anlisis de informacin de los procesos de gestin de solicitudes del Banco de los Alpes con el fin de plantear una arquitectura de solucin tecnolgica con el fin de optimizar la gobernabilidad, monitoreo y eficiencia, tanto a nivel tcnico como funcional de estos procesos de negocio que constituyen y representan valor en las objetivos estratgicos de la organizacin. 7 2.2 Misin de las Pruebas aplicable a este proyecto 7 2.3 Motivadores de las Pruebas 7 3. Elementos Objetivo de Pruebas 4. PANORAMA DE PRUEBAS PLANEADAS 5. ENFOQUE DE LAS PRUEBAS 5.1 Medicin de la Extensin de las Pruebas 5.2 Pruebas de Aceptacin 5.3 Pruebas de Integracin 6. CRITERIOS DE ENTRADA Y SALIDA 6.1 Criterios de Entrada del Plan Maestro de Pruebas 6.2 Criterio de Salida del Plan Maestro de Pruebas 6.3 Criterios de suspensin y Reanudacin 6.4 Requisitos de reanudacin 7. Necesidades de Ambiente 7.1 Hardware Base para ambiente de pruebas 7.2 Software Base para ambiente de pruebas 7.3 Herramientas de soporte a las pruebas 7.4 Configuraciones de Ambientes de Pruebas 8. Datos de Prueba Confidencial EASY Software & Innovation, 2013 8 10 11 11 12 13 16 16 16 16 16 16 16 17 17 18 18 Page 3
Plan de Pruebas
Fecha: 19-05-2009
8.1 Polticas de Administracin de los Datos de Prueba 9. RESPONSABILIDADES Y EQUIPO DE TRABAJO 9.1 Personas y Roles 10. Riesgos de las pruebas
Pgina 4 de 21
18 20 20 20
Confidencial
Page 4
Plan de Pruebas
Fecha: 19-05-2009
Pgina 5 de 21
Plan de Pruebas
1.
1.1
Introduccin
Propsito El propsito del plan de pruebas planteado en este documento, es permitir definir los lineamientos a seguir para realizar la planeacin de la etapa de pruebas sobre el proyecto Gestin de Solicitudes Banco de los Alpes, planteando una estrategia que conduzca al objetivo enfocado en el aseguramiento de calidad del software.
El propsito del Plan Maestro de Pruebas es:
Proveer un artefacto central que gobierne la planeacin y control del esfuerzo de pruebas. Este define el enfoque general que ser empleado para probar el software y para evaluar los resultados de esas pruebas, y es el plan de ms alto nivel que ser usado por los administradores para guiar y dirigir el trabajo de pruebas detallado. Proveer visibilidad a los interesados en el esfuerzo de pruebas que han tenido las consideraciones adecuadas para varios aspectos que orientan el esfuerzo de pruebas, y dnde es apropiado que los interesados aprueben el plan. Este Plan Maestro de Pruebas tambin soporta los siguientes objetivos especficos: Identificar los tems que sern objeto de las pruebas. Enmarcar la metodologa de pruebas que ser utilizada Identificar los recursos requeridos y proveer un estimado del esfuerzo de las pruebas. Elaborar un listado de los elementos entregables del plan de pruebas.
1.2
Alcance
El plan maestro de pruebas describe el detalle de las diferentes pruebas a ser aplicadas, as como tambin las herramientas y metodologas a utilizar en cada una de estas. Las pruebas que sern realizadas son:
Confidencial
Page 5
Plan de Pruebas
Fecha: 19-05-2009
Pgina 6 de 21
Revisin de la documentacin: Consiste en revisar la calidad y completitud de los documentos insumo y casos de uso para la ejecucin de las pruebas. Pruebas Unitarias: Se validaran las piezas individuales del software como una unidad independiente, bucles, condicionales, etc. Pruebas de integracin: Se validara la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta. Pruebas Funcionales o de Procedimientos: Se validaran los procesos, reglas de negocio establecidas y los requerimientos funcionales. Pruebas de sistema: Las pruebas de sistema se determinarn en el momento que el Outsourcing de Desarrollo entregue el documento de Requerimientos no funcionales, y as determinar que tipos de prueba se realizarn y a que casos de uso se aplicarn. Pruebas de regresin: Se validara que el sistema mantenga su correcta funcionalidad debido a la incorporacin de un ajuste, correccin o nuevo requerimiento. Adicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que son crticos y de mayor relevancia para el proyecto, se determinan los tipos de pruebas que se realizarn para el proyecto, diseando los factores de calidad y las pruebas especializadas para alcanzar estos atributos del software entregado. Con esta misin se identifican de acuerdo a las especificaciones del cliente los factores Para este proyecto de acuerdo a los requerimientos, se definen los siguientes factores en los que se enfocarn las pruebas: Correccin. Conformidad. Facilidad de Uso. Portabilidad. Facilidad de Operacin.
1.3 Audiencia Este plan maestro de pruebas esta dirigido a todas aquellas personas involucradas en la planeacin, aprobacin y ejecucin del mismo. 1.4

Referencias Cronograma del Proyecto Especificacin Requerimientos de Software

EASY Software & Innovation, 2013 Page 6
Confidencial
Plan de Pruebas
Fecha: 19-05-2009
Pgina 7 de 21
2.
2.1
Misin de las Pruebas

Contexto del Proyecto y Antecedentes
Se pretende realizar un levantamiento y anlisis de informacin de los procesos de gestin de solicitudes del Banco de los Alpes con el fin de plantear una arquitectura de solucin tecnolgica con el fin de optimizar la gobernabilidad, monitoreo y eficiencia, tanto a nivel tcnico como funcional de estos procesos de negocio que constituyen y representan valor en las objetivos estratgicos de la organizacin. 2.2 Misin de las Pruebas aplicable a este proyecto
La misin de la evaluacin para el presente proyecto se define enfocada al aseguramiento de la calidad de los componentes y artefactos tecnolgicos desarrollados, de manera que estos cumplan con la especificacin de los requerimientos del cliente. Para esto se definen los siguientes lineamientos que constituyen la misin y objetivos dentro este esfuerzo de pruebas: Descubrir tantos errores como sea posible Notificar acerca de los riesgos percibidos del proyecto Examinar la aplicacin para comprobar si hace o no lo que se supone, debe hacer. De igual forma verificar si sta hace o no lo que se supone, no debe hacer. Validar y Verificar a travs de la comparacin del resultado de las pruebas del aplicativo con el resultado que el mismo tendra que producir de acuerdo a su especificacin. Evaluar la calidad del producto y satisfaccin de los interesados Cumplir con los requerimientos del cliente
El proceso de evaluacin y pruebas debe permitir detectar problemas desde el inicio de la especificacin de requerimientos, antes de que sean de gran impacto en fases ms adelantadas del proyecto, esto con el fin de disminuir los riesgos y de obtener un producto con calidad logrando mayor satisfaccin del cliente.
2.3 Motivadores de las Pruebas
Dentro de los principales motivadores de pruebas del proyecto, estn, la necesidad del cliente de optimizar y gestionar la ejecucin de sus procesos de negocio, verificar la confiabilidad de la informacin que posee sobre sus clientes y dar trmites giles y efectivos a las solicitudes que
Confidencial EASY Software & Innovation, 2013 Page 7
Plan de Pruebas
Fecha: 19-05-2009 ellos generan a la organizacin
Pgina 8 de 21
Adicionalmente existen unos motivadores puntuales que van a contribuir a que se construya un software que satisfaga los requerimientos del cliente de la manera ms ptima posible y siguiendo un proceso adecuado para conseguirlo. Estos son:

Aseguramiento de la calidad. Solicitudes de cambios. Riesgos de calidad. Verificacin de los casos de uso. Comprobacin de los requerimientos funcionales y no funcionales.
3.
Elementos Objetivo de Pruebas
A continuacin se listan los elementos (artefactos, entregables, documentos etc.) que seran objeto de prueba dentro del esfuerzo de pruebas: Fase Inicial Documentacin Especificacin de Requerimientos Estimaciones Modelos - Diagramas
Confidencial
Page 8
Plan de Pruebas
Fecha: 19-05-2009
Pgina 9 de 21
Confidencial
Page 9
Plan de Pruebas
Fecha: 19-05-2009
Pgina 10 de 21
4.
PANORAMA DE PRUEBAS PLANEADAS
Confidencial
Page 10
Plan de Pruebas
Fecha: 19-05-2009
Pgina 11 de 21
5.
ENFOQUE DE LAS PRUEBAS
El plan de pruebas se basar en su totalidad en pruebas funcionales, instalacin, regresin y otras teniendo en cuenta los requerimientos no funcionales. Revisin de la documentacin: La estrategia para realizar estas pruebas, consiste en la revisin de la documentacin y casos de uso verificando su completitud y concordancia en la informacin que se encuentra en ellos.
Pruebas unitarias: Las estrategias para realizar estas pruebas consiste en generar casos de prueba necesarios: Para que cada sentencia o instruccin del programa se ejecute al menos una vez correctamente. Para que cada condicin tenga por lo menos una vez un resultado verdadero y al menos una vez uno falso. Para probar varias veces el mismo bucle (en donde aplique) considerando los siguientes casos: Ignorar el bucle, pasar una vez, pasar dos veces, pasar n veces, pasar n-1 veces y n+1 veces. Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas consiste en la elaboracin y ejecucin de Set de Pruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e invlidos que permitan verificar lo siguiente: Los resultados esperados ocurren cuando se usan datos validos. Se despliegan mensajes de error cuando se usan datos invlidos. Cada regla de negocio es propiamente aplicada. Pruebas de Regresin: La estrategia para realizar estas pruebas consiste en repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir defectos o de aadir nuevas funcionalidades, para comprobar que las modificaciones no provocan errores donde antes no los haba. Medicin de la Extensin de las Pruebas
5.1
Cuando se tiene un numero determinado de casos de prueba por cada caso de uso, la forma de medir la extensin de las pruebas ser comparando el numero de casos de prueba ejecutados satisfactoriamente contra el numero de casos de prueba total, esto nos dar a conocer el porcentaje de pruebas ejecutado por el grupo de pruebas.
Plan de Pruebas
Fecha: 19-05-2009
Pgina 12 de 21
Extensin de las pruebas = (Casos de prueba ejecutados satisfactoriamente *100)/total de casos de prueba
5.2
Pruebas de Aceptacin
La pruebas de aceptacin se basarn en su totalidad en pruebas funcionales, instalacin, y otras teniendo en cuenta los requerimientos funcionales las pruebas. Adicionalmente estas pruebas sern de caja negra.
Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas consiste en la elaboracin y ejecucin de Set de Pruebas, teniendo en cuenta flujo normal y flujos alternativos, usando datos validos e invlidos que permitan verificar los casos de prueba descritos en el documento RCFU_ANL_CasosPruebaAceptacion. Estos casos de prueba son aprobados por el cliente.
5.2.1 Tcnicas y Herramientas de Prueba A continuacin se exponen las herramientas y tcnicas que se usaran para llevar a cabo las pruebas enfocadas a la mitigacin de los riesgos anteriormente planteados: Factor de Prueba: Descripcin: Con las pruebas de operacin se garantiza que el usuario est bien capacitado en el manejo del software y adems se lleva un registro para guardar los caminos no contemplados dentro de las pruebas previas del software, y con ello se tomarn las medidas adecuadas. Factor de Prueba: Descripcin: Se debe incluir al cliente y/o usuario final con un role de evaluador durante sesiones de walkthroughs en las cuales se discutirn los escenarios de calidad referentes a la usabilidad del software. Facilidad de Uso Tcnica: Walkthroughs Conformidad Tcnica: Pruebas de operacin
Confidencial
Page 12
Plan de Pruebas
Fecha: 19-05-2009 Factor de Prueba: Descripcin: Facilidad de Operacin Tcnica:
Pgina 13 de 21 Pruebas de Requerimientos
Validar los requerimientos no funcionales de ambiente recolectados con el cliente versus las caractersticas requeridas por el ambiente de produccin.
5.3
Pruebas de Integracin
Las pruebas de integracin que se realizaran durante el proceso de desarrollo de los componentes de software, deben seguir las siguientes polticas y lineamientos de ejecucin:

Se tiene una fase de pruebas unitarias competa y aprobada para el inicio de las pruebas de integracin. Se seguir el enfoque Bottom-UP para la ejecucin de estas pruebas, es decir, se probaran en primer lugar los componentes o mdulos individuales del software y posteriormente y de manera progresiva se Irn agrupando hacia arriba y de manera funcional estos componentes para probar escenarios que impliquen varias funcionalidades de interaccin entre los componentes, y se continuar as hasta llegar al nivel ms alto de funcionalidad e integracin. Para la ejecucin de estas pruebas se utilizarn las siguientes tcnicas:
Confidencial
Page 13
Plan de Pruebas
Fecha: 19-05-2009 Objetivo de la tcnica:
Pgina 14 de 21 Verificar el funcionamiento interno de los componentes desarrollados por medio de la comprobacin del los procedimientos llevados a cabo por el software en cada invocacin/llamado/respuesta, asi como el procesamiento de datos que tiene lugar en cada uno de esta acciones. Pruebas de Caja negra Debuggers Robot de Pruebas Bug Tracker Tracing y Seguimiento a variables Concordancia de los procedimientos del sistema con los requerimientos de usuario Optimo manejo de excepciones y errores Fcil seguimiento de la ejecucin por medio de los traces.
Tcnica Herramientas requeridas:
Criterio de xito
Objetivo de la tcnica: Tcnica Herramientas requeridas:
Verificar que los componentes funcionen adecuadamente de manera individual cuando se encuentran integrados con otros mdulos y componentes Pruebas de Regresin Casos de Prueba Robot de Pruebas con scripts ya ejecutados Bug Tracker Tracing
Confidencial
Page 14
Plan de Pruebas
Fecha: 19-05-2009 Criterio de xito
Pgina 15 de 21 No se detectan errores inyectados durante la integracin del sistema
Objetivo de la tcnica:
Verificar que la parametrizacin de componentes y todos los aspectos referentes a la integracin de partes del software (consideraciones, configuraciones,ajustes) cumplan con lo preestablecido pro el equipo desarrollo en la fase de diseo. Listas de Chequeo Listas de chequeo con los items a comprobar para la integracin
Tcnica Herramientas requeridas: Criterio de xito
El 100% de los tems han sido chequeados y cumplen con la condicin para ser aprobados.
Finalmente y como criterio de aceptacin para esta fase de las pruebas se realizar un piloto funcional de la solucin construida, para el cual se debe generar un Set de casos de prueba que abarquen la mayor cantidad de interacciones que impliquen comunicacin e integracin entre los diferentes componentes del software, y en el deben participar tanto los usuarios finales como los desarrolladores.
Confidencial
Page 15
Plan de Pruebas
Fecha: 19-05-2009
Pgina 16 de 21
6.
6.1

CRITERIOS DE ENTRADA Y SALIDA

Criterios de Entrada del Plan Maestro de Pruebas
Set de pruebas completo y claro. Claridad en el procedimiento para el desarrollo de las pruebas. Tener un entorno de pruebas adecuado. Toda la documentacin requerida para la realizacin de las pruebas debe estar disponible.
Criterio de Salida del Plan Maestro de Pruebas
6.2
Que todos los set de pruebas diseados para cada caso de uso se ejecuten de manera exitosa, cumpliendo los criterios de aceptacin definidos para cada uno.
Criterios de suspensin y Reanudacin
6.3

Una caracterstica principal tiene un error que impide probar un rea importante. El entorno de pruebas no es lo suficientemente estable como para confiar en los resultados. El entorno de pruebas es muy diferente del entorno de produccin. No se puede instalar la nueva versin o un componente
Requisitos de reanudacin
6.4
Existe consenso en el equipo acerca de la solucin del problema que supuso la suspensin de las pruebas.
7.
Necesidades de Ambiente
Page 16
7.1 Hardware Base para ambiente de pruebas Confidencial EASY Software & Innovation, 2013
Plan de Pruebas
Fecha: 19-05-2009
Pgina 17 de 21
La siguiente tabla relaciona los recursos de hardware que son necesarios para crear un ambiente inicial de pruebas en este proyecto
Aplicacin a Instalar
Equipo
Procesador
DD
RAM
PC Windows (XP o superior)
Intel
10GB
2 GB
Windows Herramientas ofimticas
* En esta fase an no se posee la informacin suficiente para determinar que Hardware y software ser requerido para la ejecucin de pruebas sobre los componentes tecnolgicos desarrollados
7.2 Software Base para ambiente de pruebas
El software a instalar en el equipo de pruebas es: Windows XP o superior Herramientas ofimticas
7.3
Herramientas de soporte a las pruebas
Las siguientes son herramientas a utilizar para la ejecucin de las pruebas y la administracin de sus resultados
Plan de Pruebas
Fecha: 19-05-2009
Pgina 18 de 21
Categora o Tipo
Nombre
Fabricante
Versin
Pruebas Unitarias
JUnit
Erich Gamma y Kent Beck
4.5
7.4
Configuraciones de Ambientes de Pruebas
8.
Datos de Prueba
Con el objetivo de realizar unas pruebas acertadas y lo ms cercanas a la realidad que sea posible, es necesario contar datos que alimenten la ejecucin de los casos de prueba, los cuales, en la medida de lo posible, deben ser reales, cubrir un rango considerable y representar una profundidad significativa dentro del dominio de los datos que maneja la organizacin en los procesos de negocio involucrados El Set de datos de prueba debe cumplir con la estructura del modelo de datos del negocio, y debe ser generados como una base de datos relacional que respete la integridad referencial requerida por el proceso (relaciones, jerarqua, restricciones etc.)
8.1 Polticas de Administracin de los Datos de Prueba
Una vez construido el Set de datos de prueba, este es administrado por el equipo de proyecto siguiendo las polticas expuestas a continuacin:
Se debe realizar un back up inicial del set de datos, antes de cualquier otro tratamiento, y este debe ser etiquetado apropiadamente para su posterior identificacin entre los dems backups que se llevarn a cabo. Se deben hacer scripts SQL que garanticen la integridad referencial del set de datos de
Plan de Pruebas
Fecha: 19-05-2009
Pgina 19 de 21
prueba construido, de cara al modelo de datos que soporta la aplicacin. El set de datos solo ser aceptado si la ejecucin de dichos scripts de verificacin no arroja inconsistencias en las relaciones de los datos. El Set de datos se implanta en el ambiente de Pruebas La administracin del Set de datos de prueba queda nicamente asignada a los responsables fijados por el equipo de desarrollo para tal fin, se debe garantizar el acceso al Set de datos de prueba y a los backups haciendo uso de la seguridad que dispone el motor de base de datos utilizado Los Backups del set se realizan de la siguiente manera de acuerdo al ambiente:
Ambiente Poltica de BackUps
Un BackUp completo antes de la ejecucin de cualquier caso de prueba Al finalizar una jornada de pruebas se realiza un backup incremental Ambiente de Pruebas Al detectar errores de impacto Crtico en la aplicacin, se realizar backup completo e inmediato de la base de datos y del sitio de la aplicacin, asocindolo a un documento descriptivo del escenario y del caso de prueba que se estaba llevando a cabo. Esto con el fin de poder reproducir estos errores posteriormente sobre un ambiente controlado y facilite la deteccin de la causa y la correccin del mismo.
La restauracin del Set de datos de prueba a su estado inicial sobre un ambiente se dar cuando ocurra alguno de los siguientes eventos: Se detecta corrupcin de los datos (perdida de integridad referencial, errores de metadata, referencia a valores no existentes etc.) por causa de errores en la aplicacin o por el manejo inadecuado de los datos por parte de los desarrolladores de a nivel del motor de base de datos Se libera una nueva versin del set de datos de prueba. Se detectan errores en la aplicacin causados por integridad referencial en los datos que no fueron advertidos en los controles iniciales. Se libera un nuevo release de la algn componente que implica pruebas de regresin y de nuevas funcionalidades
Confidencial
Page 19
Plan de Pruebas
Fecha: 19-05-2009
Pgina 20 de 21
9.
9.1
RESPONSABILIDADES Y EQUIPO DE TRABAJO

Personas y Roles
Esta tabla muestra el personal supuesto para el esfuerzo de pruebas.

Recursos Humanos Rol Administrador de Pruebas Responsabilidades Especficas o Comentarios Administra el esfuerzo de las pruebas, aprueba los criterios de entrada y salida a las pruebas, monitorea avance del esfuerzo de pruebas, aprueba los casos de prueba, gestiona el alcance y misin de las pruebas, Certifica el nivel de calidad del producto construido. Es el responsable de disear los set de pruebas (estructura y enfoque) que se realizarn al sistema para una certificar que se construy un producto que satisface los requerimientos definidos. Es el responsable de ejecutar los casos de prueba y realizar los reportes correspondientes sobre esta ejecucin. Realizar documentacin tcnica de las pruebas.
Diseador de Pruebas
Analista de Pruebas
10.
Riesgos de las pruebas
A continuacin se expone una matriz en la cual se relacionan los 5 factores de prueba ms crticos para el proyecto con los riesgos identificados para cada uno de ellos vs. las fases en las que se ejecutan las pruebas.
Factor de Prueba Requerimientos Diseo Software
Conformidad
RSK_REQ_001: Pasar por alto la prueba de requerimientos no funcionales clave que impliquen un gran impacto en la arquitectura propuesta.
RSK_DSN_001: Alta complejidad en el diseo de las pruebas que evidencien la conformidad con los requerimientos de gobernabilidad y reusabilidad
RSK_SFW_001: Omitir la ejecucin de pruebas en las caractersticas menos comunes de utilizacin.
Confidencial
Page 20
Plan de Pruebas
Fecha: 19-05-2009
Factor de Prueba Requerimientos Diseo
Pgina 21 de 21
Software
Portabilidad
RSK_REQ_002: Identificar tardamente problemas de compatibilidad con plataformas externas de alto riesgo o costo. RSK_REQ_003: No lograr captar la opinin de los usuarios finales para determinar los aspectos de facilidad de uso que ellos esperan. RSK_REQ_004: No incluir en las listas de chequeo de comprobacin de los requerimientos, los aspectos relacionados con la facilidad de operacin, por desconocimiento en los mismos RSK_REQ_005: No Encontrar requerimientos en una fase temprana con algn nivel de ambigedad.
RSK_DSN_002: No contar con la tecnologa necesaria para probar aspectos del diseo enfocados a comprobar el bajo acoplamiento de la solucin. RSK_DSN_003: Realizar las pruebas con un enfoque muy tcnico sin detectar aspectos que por diseo supongan complejidades altas en el uso del software RSK_DSN_004: No detectar a tiempo aspectos del diseo que se conviertan en impedimentos para permitir las fcil instalacin y administracin de las solucin
RSK_SFW_002: No cubrir en las pruebas una cantidad representativa de plataformas que deben ser compatibles con la solucin a futuro. RSK_SFW_003: Probar solo funcionalidades sin identificar problemas o mejoras en la facilidad de utilizacin del software RSK_SFW_004: Detectar tardamente problemas relacionados con la instalacin y operacin del software
Facilidad de Uso
Facilidad de Operacin
Correccin
RSK_DSN_005: No Identificar problemas para corregir defectos detectados en una fase avanzada del desarrollo.
RSK_SFW_005: Presencia de errores en el producto que sean muy costosos de corregir cuando este ya se encuentre finalizado.
Confidencial
Page 21

Bags Inic Plandepruebas

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Bags Inic Plandepruebas

Încărcat de

Drepturi de autor:

Formate disponibile

EASY Software & Innovation

Gestin Solicitudes Banco de Los Alpes

EASY Software & Innovation

EASY Software & Innovation, 2013

EASY Software & Innovation

EASY Software & Innovation

EASY Software & Innovation, 2013

EASY Software & Innovation

El propsito del Plan Maestro de Pruebas es:

EASY Software & Innovation, 2013

EASY Software & Innovation

Referencias Cronograma del Proyecto Especificacin Requerimientos de Software

EASY Software & Innovation

Misin de las Pruebas

EASY Software & Innovation

Fecha: 19-05-2009 ellos generan a la organizacin

Elementos Objetivo de Pruebas

EASY Software & Innovation, 2013

EASY Software & Innovation

EASY Software & Innovation, 2013

EASY Software & Innovation

PANORAMA DE PRUEBAS PLANEADAS

EASY Software & Innovation, 2013

EASY Software & Innovation

ENFOQUE DE LAS PRUEBAS

EASY Software & Innovation

EASY Software & Innovation, 2013

EASY Software & Innovation

Fecha: 19-05-2009 Factor de Prueba: Descripcin: Facilidad de Operacin Tcnica:

Pgina 13 de 21 Pruebas de Requerimientos

EASY Software & Innovation, 2013

EASY Software & Innovation

Fecha: 19-05-2009 Objetivo de la tcnica:

Tcnica Herramientas requeridas:

Objetivo de la tcnica: Tcnica Herramientas requeridas:

EASY Software & Innovation, 2013

EASY Software & Innovation

Fecha: 19-05-2009 Criterio de xito

Pgina 15 de 21 No se detectan errores inyectados durante la integracin del sistema

Tcnica Herramientas requeridas: Criterio de xito

EASY Software & Innovation, 2013

EASY Software & Innovation

CRITERIOS DE ENTRADA Y SALIDA

EASY Software & Innovation

PC Windows (XP o superior)

Windows Herramientas ofimticas

El software a instalar en el equipo de pruebas es: Windows XP o superior Herramientas ofimticas

Herramientas de soporte a las pruebas

EASY Software & Innovation

Erich Gamma y Kent Beck

Configuraciones de Ambientes de Pruebas

EASY Software & Innovation

EASY Software & Innovation, 2013

EASY Software & Innovation

RESPONSABILIDADES Y EQUIPO DE TRABAJO

Esta tabla muestra el personal supuesto para el esfuerzo de pruebas.

Riesgos de las pruebas

RSK_SFW_001: Omitir la ejecucin de pruebas en las caractersticas menos comunes de utilizacin.

EASY Software & Innovation, 2013

EASY Software & Innovation

EASY Software & Innovation, 2013

S-ar putea să vă placă și