Bags Inic Plan de Pruebas

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
Autor
Equipo EASY Software & Innovation
19/05/2009
1.0
Creacin del
documento
Confidencial
NATHALY CAROLINA GONZLEZ

MONTENEGRO Cdigo: 200910019
FERNANDO ANDRS BERNATE HEREDIA
Cdigo: 200913532
ANDRS MAURICIO RAMOS BONILLA
Cdigo: 200918340
NSTOR ARMANDO BOHRQUEZ SALDANA
Cdigo: 200918290
EASY Software & Innovation,

2015
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
2.
Misin de las Pruebas

2.1
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
2.3
Motivadores de las Pruebas
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

2015
Page 3
Plan de Pruebas
Fecha: 19-05-2009
8.1
9.
10.
Pgina 4 de 21
Polticas de Administracin de los Datos de Prueba
RESPONSABILIDADES Y EQUIPO DE TRABAJO

9.1
Personas y Roles
Riesgos de las pruebas
Confidencial

2015
Page 4
Plan de Pruebas
Fecha: 19-05-2009
Pgina 5 de 21
Plan de Pruebas
1.
Introduccin
1.1
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.
1.2
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.
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

2015
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
Confidencial

2015
Page 6
Plan de Pruebas
Fecha: 19-05-2009
Pgina 7 de 21
2.
Misin de las Pruebas
2.1
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

2015
Page 7
Plan de Pruebas
Fecha: 19-05-2009
Pgina 8 de 21
ellos generan a la organizacin
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

2015
Page 8
Plan de Pruebas
Fecha: 19-05-2009
Confidencial
Pgina 9 de 21

2015
Page 9
Plan de Pruebas
Fecha: 19-05-2009
4.
Pgina 10 de 21
PANORAMA DE PRUEBAS PLANEADAS
Confidencial

2015
Page 10
Plan de Pruebas
Fecha: 19-05-2009
5.
Pgina 11 de 21
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.
5.1
Medicin de la Extensin de las Pruebas
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.
Confidencial

2015
Page 11
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:
Conformidad
Tcnica:
Pruebas de operacin
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:
Facilidad de Uso
Tcnica:
Walkthroughs
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.
Confidencial

2015
Page 12
Plan de Pruebas
Fecha: 19-05-2009
Factor de Prueba:
Pgina 13 de 21
Facilidad de Operacin
Tcnica:
Pruebas de Requerimientos
Descripcin:
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

2015
Page 13
Plan de Pruebas
Fecha: 19-05-2009
Pgina 14 de 21
Objetivo de la
tcnica:
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.
Tcnica
Pruebas de Caja negra
Herramientas
requeridas:
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.
Criterio de xito
Objetivo de la
tcnica:
Verificar que los componentes funcionen adecuadamente de

manera individual cuando se encuentran integrados con otros
mdulos y componentes
Tcnica
Pruebas de Regresin
Herramientas
requeridas:
Casos de Prueba
Robot de Pruebas con scripts ya ejecutados
Bug Tracker
Tracing
Confidencial

2015
Page 14
Plan de Pruebas
Fecha: 19-05-2009
Pgina 15 de 21
Criterio de xito
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.
Tcnica
Listas de Chequeo
Herramientas
requeridas:
Criterio de xito
No se detectan errores inyectados durante la integracin del

sistema
Listas de chequeo con los items a comprobar para la

integracin
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

2015
Page 15
Plan de Pruebas
Fecha: 19-05-2009
6.
6.1
6.2
6.3
6.4
7.
Pgina 16 de 21
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
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
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
Existe consenso en el equipo acerca de la solucin del problema que supuso la suspensin
de las pruebas.
Necesidades de Ambiente
7.1
Hardware Base para ambiente de pruebas
Confidencial
2015
Page 16
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
Equipo
Procesador
DD
RAM
Aplicacin a
Instalar
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

desarrollados
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
Confidencial

2015
Page 17
Plan de Pruebas
Fecha: 19-05-2009
7.4
Pgina 18 de 21
Categora o Tipo
Nombre
Fabricante
Versin
Pruebas Unitarias
JUnit
Erich Gamma y Kent

Beck
4.5
Configuraciones de Ambientes de Pruebas

desarrollados
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
Confidencial

2015
Page 18
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

2015
Page 19
Plan de Pruebas
Fecha: 19-05-2009
Pgina 20 de 21
9.
RESPONSABILIDADES Y EQUIPO DE TRABAJO
9.1
Personas y Roles
Esta tabla muestra el personal supuesto para el esfuerzo de pruebas.

Recursos Humanos
Rol
Administrador de
Pruebas
Diseador de Pruebas
Analista de Pruebas
10.
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.
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
Conformidad
Confidencial
Requerimientos
RSK_REQ_001:
Pasar por alto la
prueba de
requerimientos no
funcionales clave que
impliquen un gran
impacto en la
arquitectura
propuesta.
Diseo
RSK_DSN_001:
Alta complejidad en
el diseo de las
pruebas que
evidencien la
conformidad con los
requerimientos de
gobernabilidad y
reusabilidad

2015
Software
RSK_SFW_001:
Omitir la ejecucin de
pruebas en las
caractersticas
menos comunes de
utilizacin.
Page 20
Plan de Pruebas
Fecha: 19-05-2009
Pgina 21 de 21
Factor de Prueba
Requerimientos
Diseo
Software
Portabilidad
RSK_REQ_002:
Identificar
tardamente
problemas de
compatibilidad con
plataformas externas
de alto riesgo o
costo.
RSK_DSN_002: No
contar con la
tecnologa necesaria
para probar aspectos
del diseo enfocados
a comprobar el bajo
acoplamiento de la
solucin.
RSK_SFW_002: No
cubrir en las pruebas
una cantidad
representativa de
plataformas que
deben ser
compatibles con la
solucin a futuro.
RSK_REQ_003: No
lograr captar la
opinin de los
usuarios finales para
determinar los
aspectos de facilidad
de uso que ellos
esperan.
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_SFW_003:
Probar solo
funcionalidades sin
identificar problemas
o mejoras en la
facilidad de
utilizacin del
software
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_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_004:
Detectar tardamente
problemas
relacionados con la
instalacin y
operacin del
software
RSK_REQ_005: No
Encontrar
requerimientos en
una fase temprana
con algn nivel de
ambigedad.
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.
Facilidad de Uso
Facilidad de
Operacin
Correccin
Confidencial

2015
Page 21

Bags Inic Plan de Pruebas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bags Inic Plan de Pruebas

Cargado por

Copyright:

Formatos disponibles

EASY Software & Innovation

Gestin Solicitudes Banco de Los Alpes

EASY Software & Innovation

NATHALY CAROLINA GONZLEZ

EASY Software & Innovation,

EASY Software & Innovation

Misin de las Pruebas

Elementos Objetivo de Pruebas

PANORAMA DE PRUEBAS PLANEADAS

ENFOQUE DE LAS PRUEBAS

CRITERIOS DE ENTRADA Y SALIDA

EASY Software & Innovation,

EASY Software & Innovation

Polticas de Administracin de los Datos de Prueba

RESPONSABILIDADES Y EQUIPO DE TRABAJO

EASY Software & Innovation,

EASY Software & Innovation

El propsito del Plan Maestro de Pruebas es:

Proveer un artefacto central que gobierne la planeacin y control del esfuerzo de

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

Elaborar un listado de los elementos entregables del plan de pruebas.

EASY Software & Innovation,

EASY Software & Innovation

Revisin de la documentacin: Consiste en revisar la calidad y completitud de los

Pruebas de integracin: Se validara la integracin entre los diferentes mdulos que

Pruebas Funcionales o de Procedimientos: Se validaran los procesos, reglas de negocio

Pruebas de sistema: Las pruebas de sistema se determinarn en el momento que el

Pruebas de regresin: Se validara que el sistema mantenga su correcta funcionalidad

EASY Software & Innovation,

EASY Software & Innovation

Misin de las Pruebas

Contexto del Proyecto y Antecedentes

Se pretende realizar un levantamiento y anlisis de informacin de los procesos de gestin de

Misin de las Pruebas aplicable a este proyecto

La misin de la evaluacin para el presente proyecto se define enfocada al aseguramiento de la

Descubrir tantos errores como sea posible

El proceso de evaluacin y pruebas debe permitir detectar problemas desde el inicio de la

Motivadores de las Pruebas

EASY Software & Innovation,

EASY Software & Innovation

ellos generan a la organizacin

Elementos Objetivo de Pruebas

EASY Software & Innovation,

EASY Software & Innovation

EASY Software & Innovation,

EASY Software & Innovation

PANORAMA DE PRUEBAS PLANEADAS

EASY Software & Innovation,

EASY Software & Innovation

ENFOQUE DE LAS PRUEBAS

El plan de pruebas se basar en su totalidad en pruebas funcionales, instalacin, regresin y

Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas

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.

Medicin de la Extensin de las Pruebas

EASY Software & Innovation,

EASY Software & Innovation

Extensin de las pruebas = (Casos de prueba ejecutados satisfactoriamente *100)/total de

La pruebas de aceptacin se basarn en su totalidad en pruebas funcionales, instalacin, y

Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas