ACTIVIDAD CALIDAD EN EL DESARROLLO DE SOFTWARE

Actividad Semana 3

PRESENTADO POR:
WILLIAM ORTIZ
Aprendiz

SERVICIO NACIONAL DE APRENDIZAJE SENA

2017
 PLAN DE PRUEBAS DEL SOFTWARE
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 Recursos Humanos, 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.

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:
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 qu tipos de prueba se realizarn y a qu 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.
Audiencia
Este plan maestro de pruebas est dirigido a todas aquellas personas
involucradas en la planeacin, aprobacin y ejecucin del mismo.
Referencias
Cronograma del Proyecto
Especificacin Requerimientos de Software
Misin de las Pruebas
 o Contexto del Proyecto y Antecedentes
Se pretende realizar un levantamiento y anlisis de informacin de los procesos de
gestin de solicitudes del rea de Gestin de Recursos Humanos 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.

o 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.
o 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 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.
o Elementos Objetivo de Pruebas
A continuacin se listan los elementos (artefactos, entregables, documentos etc.)
que sern objeto de prueba dentro del esfuerzo de pruebas:

Fase Inicial
Documentacin
Especificacin de Requerimientos
Estimaciones
Modelos - Diagramas
PANORAMA DE PRUEBAS PLANEADAS
 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 vlidos.
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.

o Medicin de la Extensin de las Pruebas

Cuando se tiene un nmero determinado de casos de prueba por cada caso de
uso, la forma de medir la extensin de las pruebas ser comparando el nmero de
casos de prueba ejecutados satisfactoriamente contra el nmero de casos de
prueba total, esto nos dar a conocer el porcentaje de pruebas ejecutado por el
grupo de pruebas.
Extensin de las pruebas = (Casos de prueba ejecutados satisfactoriamente
*100)/total de casos de prueba

o Pruebas de Aceptacin

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

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:

Conformidad Tcnica: Pruebas de

Factor de Prueba:
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.
 Factor de Facilidad de Pruebas de
Tcnica:
Prueba: Operacin Requerimientos
Descripcin:
Validar los requerimientos no funcionales de ambiente recolectados con el cliente
versus las caractersticas requeridas por el ambiente de produccin.

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

Objetivo de la Verificar el funcionamiento interno de los componentes

tcnica: desarrollados por medio de la comprobacin de los
procedimientos llevados a cabo por el software en cada
invocacin/llamado/respuesta, as como el procesamiento
de datos que tiene lugar en cada uno de esta acciones.

Tcnica Pruebas de Caja negra

Herramientas Debuggers
requeridas:
Robot de Pruebas
Bug Tracker
Tracing y Seguimiento a variables
Criterio de xito 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.

Objetivo de la Verificar que los componentes funcionen adecuadamente de

tcnica: manera individual cuando se encuentran integrados con
otros mdulos y componentes
Tcnica Pruebas de Regresin

Herramientas Casos de Prueba

requeridas:
Robot de Pruebas con scripts ya ejecutados
Bug Tracker
Tracing

Criterio de xito No se detectan errores inyectados durante la integracin

del sistema

Objetivo de la Verificar que la parametrizacin de componentes y todos los

tcnica: 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 Listas de chequeo con los tems a comprobar para la

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

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 diseadas 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.
 RESPONSABILIDADES Y EQUIPO DE TRABAJO
Personas y Roles
Esta tabla muestra el personal supuesto para el esfuerzo de pruebas.
Recursos Humanos
Rol Responsabilidades Especficas o Comentarios
Administrador de Administra el esfuerzo de las pruebas, aprueba los criterios
Pruebas 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.
Diseador de Pruebas 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.
Analista de Pruebas 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 Requerimientos Diseo Software

RSK_REQ_001: RSK_DSN_001: RSK_SFW_001:
Pasar por alto la Alta complejidad en Omitir la ejecucin
prueba de el diseo de las de pruebas en las
requerimientos no pruebas que caractersticas
funcionales clave evidencien la menos comunes de
Conformidad que impliquen un conformidad con los utilizacin.
gran impacto en la requerimientos de
arquitectura gobernabilidad y
propuesta. reusabilidad

Portabilidad RSK_REQ_002: RSK_DSN_002: No RSK_SFW_002: No

Identificar contar con la cubrir en las
tardamente tecnologa pruebas una
problemas de necesaria para cantidad
compatibilidad con probar aspectos del representativa de
Factor de Prueba Requerimientos Diseo Software
plataformas diseo enfocados a plataformas que
externas de alto comprobar el bajo deben ser
riesgo o costo. acoplamiento de la compatibles con la
solucin. solucin a futuro.
RSK_REQ_003: No RSK_DSN_003: RSK_SFW_003:
lograr captar la Realizar las Probar solo
opinin de los pruebas con un funcionalidades sin
usuarios finales enfoque muy identificar
Facilidad de Uso para determinar los tcnico sin detectar problemas o
aspectos de aspectos que por mejoras en la
facilidad de uso que diseo supongan facilidad de
ellos esperan. complejidades altas utilizacin del
en el uso del software
software
RSK_REQ_004: RSK_DSN_004: No RSK_SFW_004:
No incluir en las detectar a tiempo Detectar
listas de chequeo aspectos del diseo tardamente
de comprobacin que se conviertan problemas
de los en impedimentos relacionados con la
Facilidad de requerimientos, los para permitir las instalacin y
Operacin aspectos fcil instalacin y operacin del
relacionados con la administracin de software
facilidad de las solucin
operacin, por
desconocimiento en
los mismos
RSK_REQ_005: No RSK_DSN_005: No RSK_SFW_005:
Encontrar Identificar Presencia de
requerimientos en problemas para errores en el
una fase temprana corregir defectos producto que sean
Correccin con algn nivel de detectados en una muy costosos de
ambigedad. fase avanzada del corregir cuando
desarrollo. este ya se
encuentre
finalizado.