Plan de Pruebas
45
REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA INSTITUTO UNIVERSITARIO DE TECNOLOGÍA “DR. DELFÍN MENDOZA” TUCUPITA - ESTADO DELTA AMACURO. DESARROLLO DE PLAN DE PRUEBA 1
-
Upload
pedro-daniel -
Category
Documents
-
view
17 -
download
1
Transcript of Plan de Pruebas
REPÚBLICA BOLIVARIANA DE VENEZUELAMINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA
INSTITUTO UNIVERSITARIO DE TECNOLOGÍA “DR. DELFÍN MENDOZA”TUCUPITA - ESTADO DELTA AMACURO.
DESARROLLO DE PLAN DE PRUEBA
Enero del 2013.
INDICE
1
Introducción……………………………….…………………………………… 3
2
Pruebas………………………………………………………............................. 4
Aspectos a tener en cuenta en la aplicación de una prueba. .......................... 5
Inspecciones…………………………………………………………………. 5
etapas de las inspecciones…….……………………………………… 6
Pasos para el desarrollo de pruebas............................................................................ 7
plan de pruebas……………………………………………………………........ 8
cómo se define un plan de prueba ………………………………………… 9
La pruebas de unidad………………………………………………………… 9
Descripción pruebas de unidad……………………………………............................ 9
alcance de la pruebas de unidad …………………………... 9
objetivos de la pruebas de unidad…………………………………… 10
planificación de las pruebas de sistema …………………………... 10
estructura de los casos de prueba…………………………………... 11
propósito del plan maestro de pruebas es …………………………………………….
definición de los casos de prueba……………………………………………………..
11
11
panorama de pruebas planeadas ………………………………………… 15
3
Seguimiento Y Control Del Proyecto……………………………………….
modelo de un plan de prueba planificado…………………………………
Ciclo de plan de Prueba…………………………………………………………….
cResultado de la ejecución de las pruebas………………………………………….
Conclusiones……………………………………………………………
Bibliografía…………………………………………………………………………….. .
17
19
24
27
29
30
4
Introducción.
Las técnicas para encontrar problemas en un programa son extensamente variadas y van
desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas
que ayudan a aliviar el peso y el costo de tiempo de esta actividad. La prueba de software
es un conjunto de herramientas, técnicas y métodos que hacen a la excelencia del
desempeño de un programa, así como también la mejor publicidad que una empresa
dedicada a la producción de software pueda tener. Pero de nada serviría conocer todas las
técnicas de prueba de software, si un programa carece de documentación, el código es
confuso, o no se han seguido pasos para la planificación y desarrollo del software, ya que
seria como buscar una aguja en un pajar. No solo las herramientas, técnicas y métodos de
prueba, sino que también a todo el trabajo previo de control de calidad en el desarrollo de
software, ya que sabemos que mucho mejor que encontrar y solucionar un problema es
prevenir que no ocurra.
La necesidad de comprobar el correcto funcionamiento del producto hace que sea
imprescindible un plan de pruebas, con el cual se procederá a realizar una serie de ensayos
que permitan obtener resultados correctos y erróneos con el fin de analizar el proceso de
ejecución. Con este conjunto de pruebas seremos capaces de determinar si nuestro
programa es erróneo sobre todo en casos extremos y particulares, tanto si estos fallos se
producen por la una mala implementación del programa, o bien por un uso especifico que
realiza el usuario. El aspecto más importante para realizar la planificación de este conjunto
de pruebas es abarcar con ellas todos los requisitos que debe cumplir el programa y que por
tanto responda correctamente a las funcionalidades que se le solicitan inicialmente.
5
PRUEBAS.
Una de las características típicas del desarrollo de software basado en el ciclo de vida, es la
realización de controles periódicos. Estos controles buscan una evaluación de la calidad de
los productos generados para poder detectar posibles defectos cuanto antes. Sin embargo,
todo sistema o aplicación, independientemente de estas revisiones, debe ser probado
mediante su ejecución controlada antes de ser entregado al cliente. Estas ejecuciones o
ensayos de funcionamiento, posteriores a la terminación del código de software se
denominan habitualmente pruebas. Las pruebas constituyen un método más para poder
verificar y validar el software.
Se puede definir prueba como una actividad en la cual un sistema o uno de sus
componentes se ejecutan en circunstancias previamente especificadas. Los resultados
de la ejecución se observan y se registran con el fin de realizar posteriormente una
evaluación de algún aspecto.
Un caso de prueba (test case) se puede definir como un conjunto de entradas, condiciones
de ejecución y resultados esperados desarrollados para un objetivo particular, por ejemplo
verificar el cumplimiento de un determinado requerimiento.
Las características especiales del software (no físico, ausencia de leyes, que rijan su
comportamiento, y complejidad) hacen aun más difícil la tarea de probarlo. Las pruebas
exhaustivas del software son impracticables, ya que no se pueden probar todas las
posibilidades de su funcionamiento incluso en programas pequeños y sencillos.
Hay que recordar que el objetivo de las pruebas es detectar defectos en el software y que
descubrir un defecto debería considerarse como el éxito de una prueba.
Tradicionalmente, existe el mito de la ausencia de errores en el buen profesional,
situación que no es real. Las pruebas permiten la rectificación del software.
6
Los defectos no son siempre el resultado de la negligencia, sino que en su aparición
influyen múltiples factores, por ejemplo, la mala comunicación entre usuarios y
programadores.
ASPECTOS A TENER EN CUENTA EN LA APLICACIÓN DE UNA PRUEBA
- Operatividad. Cuanto mejor funcione el software, más eficientemente se puede
probar. Ningún error debe bloquear la ejecución de las pruebas.
- Observabilidad. Lo que ves es lo que pruebas. Un resultado incorrecto se
identifica fácilmente.
- Controlabilidad. Cuánto mejor podamos controlar el software más se puede
automatizar y optimizar. Las pruebas pueden especificarse, automatizarse y
reproducirse convenientemente.
- Capacidad de descomposición. Controlando el ámbito de las pruebas podemos
aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión.
Los módulos de software se pueden probar independientemente.
- Simplicidad. Cuanto menos haya que probar más rápidamente podemos probarlo.
- Estabilidad. Cuánto menos cambios haya, menos interrupciones a las pruebas.
- Facilidad de comprensión. Cuanta más información tengamos, mejores serán las
pruebas.
INSPECCIONES
La inspección del software IEEE es una técnica de evaluación formal, en la cual los
requisitos del software, diseño o la codificación son examinados en detalle por una
persona diferente al desarrollador, para detectar defectos, incoherencias con las normas
de desarrollo y otros problemas.
La inspección proporciona una indicación inmediata y cuantitativa de la calidad,
comenzando con los requerimientos y el diseño.
Para que una inspección tenga éxito se deben cumplir ciertas normas:
7
- Las inspecciones se realizan en varios puntos del ciclo de vida del producto.
- Se deben inspeccionar todo tipo de defecto en toda la documentación.
- En la inspección deben participar colegas y todo tipo de personal relacionado con el
sistema.
- La inspección se debe realizar según una serie predefinida de etapas.
- Las inspecciones deben ser dirigidas por personal con experiencia.
- Los miembros del grupo de inspección deben tener tareas específicas asignados a
cada uno.
- El grupo de inspección debe contar con listas de chequeo y comprobación para el
control de las inspecciones realizadas.
- Se debe inspeccionar el producto a una velocidad adecuada para encontrar posibles
fallas.
- Se deben archivar estadísticas de las inspecciones.
ETAPAS DE LAS INSPECCIONES
- Planificación. Una vez se determina que un producto esta listo para inspección se
define un equipo encargado de esa tarea, para lo cual planea una serie de actividades
(para autor e inspector) con miras a la revisión del producto.
- Presentación o visión general. Es una etapa opcional que tiene por objeto ofrecer
una visión global del proyecto y explicar las funciones, organización y técnica del
producto.
- Preparación. Aquí se define el trabajo que debe hacer cada inspector, a partir de la
documentación que le ha sido entregada. El inspector con los datos obtenidos se
prepara para desempeñar un buen papel en la reunión (siguiente etapa).
- Reunión. Tiene por objetivo la búsqueda exhaustiva de defectos del producto
analizado y por ello es la etapa más importante del proceso. La reunión de ser
dirigida por un moderador quien hacer parte del equipo de inspectores. Se
recomienda llevar el siguiente orden:
8
Introducción. Usada para presentar inspectores y recordar sus funciones.
Establecer tiempos de preparación de inspectores. El moderador verifica el
tiempo que dedicaron a prepararse para la reunión.
Lectura de producto, identificación y anotación de defectos. Pelean los defectos
encontrados por cada inspector y se toma nota de ellos.
Revisión de lista de defectos. Terminada la reunión se verifica cada uno de los
defectos encontrados buscando un consenso entre grupo de inspectores.
Determinar disposición final del producto. Se define el concepto final para el
producto. Los conceptos posibles son: afectados, afectado condicionalmente y
rechazado.
- Corrección. En esta etapa el actor debe corregir los defectos encontrados por los
inspectores y entregar el nuevo producto.
- Seguimiento. Cuando la corrección finalice, el autor en el moderador se reúnen de
nuevo para revisar los resultados. Si el moderador aprueba los resultados se da por
terminada la inspección. Si no los aprueba, el moderador puede solicitar una
corrección adicional o convocar a otra inspección.
Pasos para el desarrollo de pruebas:
- Obtener los requerimientos en forma clara.
- Obtener planificación de diseño.
- Determinar funcionalidad.
- Identificar aplicaciones de alto riesgo o con prioridad de prueba.
- Determinar métodos de prueba.
9
- Determinar contexto de la prueba.
- Obtener datos de prueba.
- Estimar tiempo de prueba.
- Clasificar errores del programa.
- Documentar errores del programa.
- Redactar los casos de prueba que encontraron fallas.
- Aprobar una revisión en la prueba.
- Evaluar resultados en reportes.
- Buscar bugs.
- Volver a probar si es necesario.
- Actualizar el plan de prueba.
PLAN DE PRUEBAS
Es un documento que tiene como objetivo señalar el enfoque, los recursos y el esquema de
actividades de prueba, así como los elementos a probar, las características, las actividades
de pruebas, el personal responsable y los riesgos asociados.
A continuación se presenta el contenido básico de un plan de pruebas:
- Identificar el documento
- Introducción y resumen de elementos y características a probar
- Elementos de software que se van a probar
- Características que se van a probar
- Características que no se prueban
- Enfoque general de la prueba (Actividades, técnicas, herramientas, etc)
- Criterios de aprobación para cada elemento probado.
10
- Criterios para suspender y requisitos para reanudar actividad
- Documentos a entregar
- Actividades de preparación y ejecución de pruebas
- Necesidades de entorno
- Responsabilidades en la organización y realización de las pruebas
- Necesidades de personal y de formación
- Cronograma de tiempos y actividades
- Riesgos asumidos por el plan
- Aprobaciones y firmas con nombre y puesto desempeñado.
¿Cómo se define un plan de prueba?
- Titulo
- Identificación, números de versión, creador, fecha de creación.
- Tabla de contenidos.
- Reportes de reuniones.
- Reportes de requerimientos.
- Reportes de documentación.
- Análisis de riesgos.
- Prioridades y focos de prueba.
- Limites. (Tiempo, riesgos, etc.)
- Reporte de datos de prueba.
- Reporte de resultados.
- Reporte de aplicaciones conjuntas al programa.
11
- Informe de herramientas automatizadas.
- Determinación de la sanidad del programa.
- Personal implicado.
- Reportes relevantes. (Licencias, clasificaciones, métodos, etc.)
- Apéndices, glosario, cronología.
LA PRUEBAS DE UNIDAD
La elaboración de un procedimiento o proyecto de software tiene como finalidad satisfacer
una necesidad planteada por el usuario. Para afirmar que se han alcanzado los niveles de
calidad exigido es necesario ajustar el producto software a medida que se va construyendo.
Por consiguiente se hace necesario llevar a cabo, en paralelo al proceso de avance, un
proceso de evaluación o comprobación de los distintos productos o modelos que se van
creando.
DESCRIPCIÓN PRUEBAS DE UNIDAD
Es la manera para ejecutar pruebas de unidad, es la forma definida a los pasos para llevar a
cabo estas pruebas. La misma analiza en detalle cada una de las fases que forma este
procedimiento, describiendo, las actividades a realizar y la documentación de entrada y
salida que las conforman.
ALCANCE DE LA PRUEBAS DE UNIDAD
Este procedimiento está dirigido a realizar las pruebas de unidad. ¿Qué se va a probar? Las
funciones individuales o métodos: se probarán las entradas y las salidas y se comprobará
que los valores obtenidos son los esperados. Es decir, se prueba el código aislado,
independiente del resto del sistema.
12
OBJETIVOS DE LAS PRUEBAS DE UNIDAD
Esta manera describe los objetivos de la elaboración de las pruebas de unidad, el camino a
seguir en la elaboración de las mismas por fases, y una descripción detallada de éstas. Las
pruebas unitarias desarrolladas en este procedimiento tienen como finalidad aislar cada
parte del programa y mostrar que las partes individuales son correctas. Son fragmentos de
unidades estructurales del programa encargados de una tarea en específico. El objetivo
principal sería producir las piezas de código de la manera más eficiente y eficaz posible
generando pruebas de unidad para las mismas que aseguren su correcto comportamiento.
PLANIFICACIÓN DE LAS PRUEBAS DE SISTEMA
Las pruebas de sistema se harán una vez que el programa haya superado las pruebas
unitarias y las de integración. Esto supone que se realizaran un conjunto de pruebas que
confirmen el funcionamiento general del programa en concordancia con los resultados
esperados, puesto que las clases ya funcionan correctamente de forma individual y
conjuntamente. Por tanto el plan de pruebas de sistema se dividirá en una serie de grupo de
pruebas que analice los requisitos examinados en el documento de especificación de
requisitos software
El Plan de Pruebas de Compatibilidad es el documento en el que se registran los casos de
pruebas a realizar para cada componente que compone el escenario de pruebas (equipo a
probar) y los resultados mínimos para entenderse como apto. Sirve para diseñar el plan de
pruebas específico. En el se definen los apartados mínimos que debe recoger un plan de
pruebas específico para un tipo de elemento hardware contemplado en la Guía de Ámbito,
así como la metodología para recoger y registrar los resultados de la ejecución de las
pruebas automáticas y manuales.
13
En el mismo se exponen los puntos mínimos que debe recoger el plan de pruebas específico
diseñado por la entidad de pruebas para un elemento hardware concreto. Cada uno de los
puntos siguientes serán los títulos de los apartados del plan de pruebas específico.
“Plan de pruebas específico” para la elaboración del plan. Definición del equipo bajo
pruebas y su escenario.
En este apartado se especificará el alcance de las pruebas a realizar, es decir, escenario a
probar y composición del mismo, así como una breve descripción del equipo
Se comprueba con la "Guía de Ámbito" durante el paso de "Recepción y Preparación del
Equipo" (apartado y se refleja en este apartado del plan de pruebas, junto con cualquier
particularidad del hardware entregado.
Así mismo, deberá indicarse cualquier otra particularidad que deba tenerse en cuenta para
la selección de las pruebas que serán realizadas: función que desarrollará el equipo bajo
pruebas, énfasis en algún componente no descrito como prioritario en la guía de ámbito,
etc.
UÍA DEABORACIÓN DEL PLAN DE PRUEBAS ESPECÍFICO
ESTRUCTURA DE LOS CASOS DE PRUEBAS
Todos los casos de pruebas tienen la misma estructura, que permite describirlos de modo
que puedan ser identificados y añadidos a un plan de pruebas genérico según las
necesidades. La estructura de los casos también permite conocer toda la información
relativa a objetivos, ejecución, resultados esperados, etc.
OBJETIVO. Es la descripción genérica del caso. Se indica cuál es el propósito del caso,
qué información proporciona su ejecución.
ENTRADA. Se describe el entorno necesario para poder ejecutar el caso (SW, HW,
configuraciones, conexiones, etc.)
14
ACCIONES. Es la descripción, paso a paso, de las acciones a realizar sobre el equipo bajo
prueba descrito en "Entrada" para la consecución del objetivo del caso.
SALIDA. Este campo permite establecer, mediante la comparación de su contenido con los
resultados obtenidos tras la aplicación de las acciones del caso, el éxito o fallo de la
ejecución de la prueba.
ETIQUETAS. Cada caso de prueba tiene una serie de atributos que permite clasificarlo en
función de distintos criterios. Cada atributo está representado por una etiqueta. A
continuación se describen las etiquetas y sus posibles valores.
DEFINICIÓN DE LOS CASOS DE PRUEBA
¿Detecta la tarjeta un cable de red enchufado en caliente? (Si/No)
Objetivo: Comprobar que el equipo, estando encendido, al conectarle el cable de red, lo
detecta sin problemas.
Entrada
Entorno Equipo con sistema operativo instalado y cable de red conectado a elemento activo
de red.
Acciones
Inicio Arrancar el equipo
Proceso Con el equipo encendido y el sistema operativo en funcionamiento, conectamos un
cable de red y comprobamos que se conecta correctamente a la red disponible.
Salida La tarjeta de red detecta link.
Etiquetas
Descripción Tarjeta red cableada, funcionalidad crítica, manual.
El propósito del plan de pruebas planteado en este documento, es permitir definir los
lineamientos a seguir para realizar la planeación de la etapa de pruebas sobre el
proyecto planteando una estrategia que conduzca al objetivo enfocado en el
aseguramiento de calidad del software.
15
EL PROPÓSITO DEL PLAN MAESTRO DE PRUEBAS ES:
Proveer un artefacto central que gobierne la planeación 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 más 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
dónde es apropiado que los interesados aprueben el plan.
Este Plan Maestro de Pruebas también soporta los siguientes objetivos específicos:
Identificar los ítems que serán objeto de las pruebas.
Enmarcar la metodología 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 DEL PLAN MAESTRO DE PRUEBAS
El plan maestro de pruebas describe el detalle de las diferentes pruebas a ser aplicadas, así
como también las herramientas y metodologías a utilizar en cada una de estas. Las pruebas
que serán realizadas son:
Revisión de la documentación: Consiste en revisar la calidad y completitud de los
documentos insumo y casos de usos para la ejecución de las pruebas.
Pruebas Unitarias: Se validaran las piezas individuales del software como una unidad
independiente, bucles, condicionales, etc.
16
Pruebas de integración: Se validara la integración entre los diferentes módulos que
componen la solución con el fin de garantizar que su operación 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 determinarán en el momento que el
Outsourcing de Desarrollo entregue el documento de Requerimientos no funcionales, y
así determinar que tipos de prueba se realizarán y a que casos de uso se aplicarán.
Pruebas de regresión: Se validara que el sistema mantenga su correcta funcionalidad
debido a la incorporación de un ajuste, corrección o nuevo requerimiento.
Adicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que son
críticos y de mayor relevancia para el proyecto, se determinan los tipos de pruebas que
se realizarán para el proyecto, diseñando los factores de calidad y las pruebas
especializadas para alcanzar estos atributos del software entregado. Con esta misión se
identifican de acuerdo a las especificaciones del cliente los factores
Especificación Requerimientos de Software
Misión de las Pruebas aplicables al proyecto de software
La misión de la evaluación de un proyecto se define enfocada al aseguramiento de la
calidad de los componentes y artefactos tecnológicos desarrollados, de manera que estos
cumplan con la especificación de los requerimientos del cliente. Para esto se definen los
siguientes lineamientos que constituyen la misión y objetivos dentro este esfuerzo de
pruebas:
Descubrir tantos errores como sea posible
Notificar acerca de los riesgos percibidos del proyecto
Examinar la aplicación 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.
17
Validar y Verificar a través de la comparación del resultado de las pruebas del
aplicativo con el resultado que el mismo tendría que producir de acuerdo a su
especificación.
Evaluar la calidad del producto y satisfacción de los interesados
Cumplir con los requerimientos del cliente.
El proceso de evaluación y pruebas debe permitir detectar problemas desde el inicio de la
especificación de requerimientos, antes de que sean de gran impacto en fases más
adelantadas del proyecto, esto con el fin de disminuir los riesgos y de obtener un producto
con calidad logrando mayor satisfacción del cliente.
PANORAMA DE PRUEBAS PLANEADAS
CRITERIOS
18
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 documentación requerida para la realización de las pruebas debe estar
disponible.
Criterio de Salida del Plan Maestro de Pruebas
Que todos los set de pruebas diseñadas para cada caso de uso se ejecuten de manera
exitosa, cumpliendo los criterios de aceptación definidos para cada uno.
Criterios de suspensión y Reanudación
Una característica 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 producción.
No se puede instalar la nueva versión o un componente
Requisitos de reanudación
Existe consenso en el equipo acerca de la solución del problema que supuso la
suspensión de las pruebas.
Datos de Prueba
Con el objetivo de realizar unas pruebas acertadas y lo más cercanas a la realidad que sea
posible, es necesario contar datos que alimenten la ejecución 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
organización en los procesos de negocio involucrados.
19
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, jerarquía, restricciones etc.)
Administración de los Datos de Prueba
Una vez construido el Set de datos de prueba, este es administrado por el equipo de
proyecto siguiendo las políticas expuestas a continuación:
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 identificación entre los demás
backups que se llevarán a cabo.
Se deben hacer scripts SQL que garanticen la integridad referencial del set de datos de
prueba construida, de cara al modelo de datos que soporta la aplicación. El set de datos solo
será aceptado si la ejecución de dichos scripts de verificación no arroja inconsistencias en
las relaciones de los datos.
El Set de datos se implanta en el ambiente de Pruebas
La administración 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:
SEGUIMIENTO Y CONTROL DEL PROYECTO
Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión. Cada requisito tendrá
una serie de atributos tales como importancia, estado, iteración donde se implementa, etc.
Estos atributos permitirán realizar un efectivo seguimiento de cada requisito. Los cambios
en los requisitos serán gestionados mediante una Solicitud de Cambio, las cuales serán
evaluadas y distribuidas para asegurar la integridad del sistema y el correcto proceso de
gestión de configuración y cambios.
20
Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de
proyecto y por el Comité de Seguimiento y Control.
Control de Calidad
Los defectos detectados en las revisiones y formalizados también en una Solicitud de
Cambio tendrán un seguimiento para asegurar la conformidad respecto de la solución de
dichas deficiencias Para la revisión de cada artefacto y su correspondiente garantía de
calidad se utilizarán las guías de revisión y checklist (listas de verificación) incluidas en
RUP.
Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las
acciones establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista
será evaluada al menos una vez en cada iteración.
Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de los artefactos generados
y sus versiones. También se incluirá la gestión de las Solicitudes de Cambio y de las
modificaciones que éstas produzcan, informando y publicando dichos cambios para que
sean accesibles a todo los participantes en el proyecto. Al final de cada iteración se
establecerá una baseline (un registro del estado de cada artefacto, estableciendo una
versión), la cual podrá ser modificada sólo por una Solicitud de Cambio aprobada.
PROPÓSITO DE UN PLAN DE PRUBA DETALLADO
Este documento tiene como propósito establecer las técnicas, herramientas y actividades
relacionadas con la ejecución y validación del plan de pruebas; incluye responsabilidades
de cada una de las tareas, los recursos y los prerequisitos que deben ser considerados en el
esfuerzo de cada una de las pruebas, permitiendo garantizar el cumplimiento de los
requerimientos planteados en el marco del desarrollo del proyecto.
21
ALCANCE DE UN PLAN DE PRUBA DETALLADO
En este, se convierte en una guía para desarrollar de una forma organizada las diferentes
actividades que se realizarán en el proceso del plan de pruebas en el desarrollo del
proyecto.
La metodologia de pruebas y el plan de pruebas permitirán al equipo profesionales
expertos que participan en el frente de pruebas del proyecto, evaluar aspectos como: La
lógica estructural, la seguridad, la interconexión, el soporte conceptual, las herramientas de
apoyo y sobretodo la independencia de aspectos técnicos del desarrollo de la solución
tecnológica contratada, tales como: la plataforma tecnológica o la arquitectura de la
solución a probar, sin embargo a continuación se describen las diferentes pruebas a ser
aplicadas:
MODELO DE UN PLAN DE PRUEBA PLANIFICADO
TIPO DE PRUEBA DEFINICIONES FASE DE RUP
UNITARIAS
INTEGRACIÓN
Unitarias: Permite verificar la funcionalidad y
estructura de cada componente individualmente del
sistema una vez que ha sido codificado.
Integración: Permite verificar el correcto ensamblaje
entre los distintos módulos que componen el sistema
desarrollado.
ELABORACIÓN
22
SISTEMA:
Carga
Volumen
Estrés
Robustez
Concurrencia,
Interfaz de Usuario
Recuperación a
Fallas
Rendimiento
Seguridad
Integridad de las BD
Interoperabilidad
Desempeño
Configuración
Sistema: Estas pruebas buscan diferencias entre la
solución desarrollada y los requerimientos, con el fin
de identificar errores que se puedan generar entre la
especificación funcional y el diseño del sistema.
Carga: Valida aquellos volúmenes de datos máximos
especificados en los requerimientos no Funcionales
Volumen: Esta prueba somete el software a grandes
cantidades de datos para determinar si se alcanzan
límites que causen la falla del software
Estrés: Valida aquellos volúmenes de datos máximos
que resiste el sistema antes de comenzar con errores.
Robustez: Valida si el sistema se mantiene estable y
consistente después de circunstancias adversas
Concurrencia: Valida la capacidad del sistema de
atender múltiples solicitudes departe de los usuarios
que acceden a un mismo recurso.
Interfaz de usuario: Ppermite verificar que la
navegación a través de los elementos que se están
probando, reflejen las funciones del negocio y los
requerimientos funcionales.
Recuperación a fallas: Estas pruebas aseguran que el
que el software pueda recuperarse a fallas de hardware,
software o mal funcionamiento de la red sin pérdida de
datos o de integridad de los datos.
23
Rendimiento: Permite validar si la aplicación cumple
los criterios de tiempos de respuesta establecidos.
Seguridad: Verifica el cumplimiento de las políticas
de seguridad acordadas para el sistema.
Integridad de las bases de datos: Consiste en
asegurar que los métodos y procesos de acceso a la
base de datos funcionan correctamente y sin corromper
datos.
Interoperabilidad: Esta prueba permite verificar todos
los artefactos de la solución desarrollada, su
arquitectura base, los protocolos de la solución, las
interfaces y los módulos del sistema, funcionando en
forma conjunta.
Desempeño: Este tipo de prueba es un aspecto
fundamental en una aplicación, ya que si ésta no
responde en el debido tiempo, se pueden perder
clientes, o dañar la imagen ante los usuarios.
Configuración: Establece y mantiene la integridad de
los productos de software a través del ciclo de vida del
proceso del mismo.
CONSTRUCCIÓN
FUNCIONALES Funcional: La prueba funcional es un proceso para
procurar encontrar discrepancias entre el programa y la
especificación funcional.
24
Caja Negra: Estas pruebas permiten obtener conjuntos
de condiciones de entrada que ejecutan todos los
requisitos funcionales de un programa.
Ciclo de Negocio: Esta prueba tiene por objeto
garantizar que el proceso de negocio esta
adecuadamente soportado por el software desarrollado
y que éste dispone de la funcionalidad adecuada para
ejecutar todas las tareas incorporadas en el proceso de
negocio.
Usabilidad: Esta prueba permite encontrar problemas
de factores humanos, o usabilidad.
Instalación: Esta prueba permite verificar la
instalación y desinstalación de la aplicación en
diferentes entornos de hardware y software
ACEPTACIÓN Es la prueba final basada en las especificaciones del
usuario o basada en el uso del programa por el usuario
final luego de un periodo de tiempoTRANSICIÓN
REGRESIÓN
25
PLANIFICACIÓN
Para el desarrollo de la solución del Sistema, se considera de gran importancia la
ejecución del plan de pruebas, haciéndose necesario la planificación de las mismas, lo que
en consecuencia hace necesario tener claro los siguientes planteamientos:
Se planifican pruebas personalizando los estándares específicamente para
el proyecto de notificaciones.
Se definen niveles de pruebas a aplicar.
Se especifican las técnicas a utilizar.
Se establece el tiempo para la ejecución de cada una de las pruebas.
Uso de herramientas.
Criterios de aceptación.
Recursos involucrados.
26
En la definición del plan de pruebas, se valorará:
El alcance de la aplicación.
La complejidad de sus procesos.
Plataforma/s en las que se debe probar.
Conocimientos y formación de quienes ejecutarán las pruebas.
Normativas legales aplicables.
Otros recursos involucrados.
Se tendrá en cuenta que:
Las pruebas estarán presentes a lo largo de todo el ciclo de vida del
desarrollo, de la solución.
Siempre hay errores.
Probar exhaustivamente el software es imposible.
No es recomendable que el programador pruebe sus propios programas.
Se puede disponer de herramientas.
Se debe considerar la importancia de actualización del plan de pruebas
con el fin de reflejar los cambios que se produzcan en los requisitos y/o
proceso de desarrollo del producto.
Resultado de la planificación:
Cronograma detallado de la ejecución de las pruebas; donde se especifica qué
prueba se realiza, cuánto tiempo se estima para su ejecución, recursos a utilizar (humanos y
tecnológicos); este cronograma se encuentra dentro del cronograma general del proyecto y
específicamente en la fase desarrollo.
Formatos a utilizar para el diseño de las pruebas.
27
Formatos a utilizar para el registro y análisis de los resultados de las
pruebas.
Herramientas a utilizar para la gestión de incidencias.
Procedimientos para el control de cambios.
Herramientas a utilizar para la ejecución de las pruebas.
DISEÑO DE LAS PRUEBAS
Para el diseño de las pruebas, se tendrán en cuenta aspectos que permitirán encontrar
defectos en el periodo de desarrollo del software, la realización de pruebas propias de
verificación y validación de datos, según se aclara en los siguientes ítems:
Alcance: El alcance de las pruebas estará dado por el marco del Sistema de Notificación en
Línea, que se encuentra en desarrollo, ésta compuesta (Información tomada de los términos
de referencia y del documento de Arquitectura General Detallada) por:
Modelo Conceptual.
Procesos.
Descripción de Procesos.
Vista de Casos de Uso.
Vista Lógica.
Diseño de las clases y su organización en paquetes y subsistemas.
Vista de Datos.
Vista de Implementación.
Vista de Despliegue.
Vista de Integración con Sistemas Externos.
Vista de Parametrización del Sistema.
Requerimientos no Funcionales.
Prototipos del sistema
28
Inventario de las Pruebas: En esta sección se especifica el inventario de las pruebas,
el cual permitirá:
Definir y asignar prioridades como; alta, media o baja.
Establecer un orden de trabajo.
Decidir qué casos entrarían en una regresión y cuáles no con mayor facilidad.
Recortar alcance en forma rápida y ordenada.
Se estima el tiempo en probar cada funcionalidad.
Evaluar aspectos técnicos del sistema.
RESULTADO DE LA EJECUCIÓN DE LAS PRUEBAS: En este punto se resaltan las
entradas fundamentales que son la partida para la ejecución del plan de pruebas.
Inventario de pruebas priorizado.
Estimación de esfuerzo de cada funcionalidad.
Plan de desarrollo del producto.
Plazos previstos para el proyecto.
29
EVALUACIÓN Y CIERRE
Para la evaluación y cierre de las pruebas se presentará el informe de pruebas donde se
documentará el resultado de cada una de las diferentes pruebas ejecutadas. El contenido de
este informe estará compuesto de la manera descrita en la “Propuesta de esquema y
contenido del Informé de pruebas”; esto ya que el informe de pruebas es un entregable
independiente.
SEGUIMIENTO Y CONTROL
Para el seguimiento y control de las pruebas se llevarán a cabo comités técnicos de
seguimiento periódico semanal donde se evalúen los siguientes temas.
Avance de las pruebas según cronograma
Estado o resultado de las pruebas ejecutadas
Seguimiento a las incidencias reportadas según la ejecución de pruebas.
Se presentará plan de contingencia para aquellas incidencias de mayor impacto que
sean de riesgo para el proyecto.
30
CONCLUSIONES
Dentro de los principales motivadores de pruebas del proyecto, están, la necesidad del
cliente de optimizar y gestionar la ejecución de sus procesos de negocio, verificar la
confiabilidad de la información que posee sobre sus clientes y dar trámites ágiles y
efectivos a las solicitudes que ellos generan a la organización.
Las pruebas de software se aplican en la fase de prueba y validación del desarrollo de un
sistema de información y son un conjunto de herramientas técnicas y métodos que tienen
como objeto comprobar los requerimientos establecidos con los usuarios o beneficiarios del
producto. Estas técnicas tienen como objeto detectar problemas y son extensamente
variadas y van desde el uso del ingenio por parte del personal de pruebas hasta
herramientas automáticas que ayudan a aliviar el peso y el costo de esta actividad. Las
pruebas no pueden asegurar la ausencia de errores; sólo puede demostrar que existen
defectos en el software.
La verificación típicamente incluye por parte de los desarrolladores la revisión de los
planes, del código, de los requerimientos, de la documentación, las especificaciones y
posteriormente una reunión con los usuarios para evaluar dichos documentos. Esto puede
ser hecho con listas de chequeos, listas de problemas. La validación típicamente incluye las
pruebas del software y comienza después que la verificación este completa.
La inspección es una reunión formal luego de la listas de problemas, generalmente incluye
personal de diferentes sectores esencialmente analistas, programadores, y personal de
prueba (testers) donde acuerdan con los usuarios los métodos de seguridad prueba a llevar a
cabo. A menudo en estas reuniones se incluye un moderador el cual representa a la empresa
y que da a conocer al usuario una lista de operaciones de métodos de prueba y controles de
calidad en las cuales el usuario debe optar definiendo el mismo el nivel de calidad.
31
BIBLIOGRAFIA
Fundamentos de Ingeniería del Software, Bertrand Meyer.
Unidad de proyecto, Universidad Politécnica de Madrid Facultad de Informática
Calidad del Software, universidad de San Carlos.
Análisis de sistema, diseño y Metodos, Whitten Bentley.
FUENTES ELECTRONICAS:
www.google.comwww.cenatic.es/boletines.http://iutmaragoza.blogcindario.com/2010/07/00002-unidad-iii-pruebas-y-calidad-del-software.htmlhttp://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF
32
[Escriba una cita del documento o del resumen de un punto interesante. Puede situar el cuadro de texto en cualquier lugar del documento. Utilice la ficha Herramientas de cuadro de texto para cambiar el formato del cuadro de texto de la cita.]
