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