REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN UNIVERSITARIA INSTITUTO UNIVERSITARIO DE TECNOLOGA DR.

DELFN MENDOZA TUCUPITA - ESTADO DELTA AMACURO.

DESARROLLO DE PLAN DE PRUEBA

Enero del 2013.

INDICE Introduccin. Pruebas............................. Aspectos a tener en cuenta en la aplicacin de una prueba. .......................... Inspecciones. etapas de las inspecciones. Pasos para el desarrollo de pruebas............................................................................ plan de pruebas........ cmo se define un plan de prueba La pruebas de unidad Descripcin pruebas de unidad............................ alcance de la pruebas de unidad ... objetivos de la pruebas de unidad planificacin de las pruebas de sistema ... estructura de los casos de prueba... propsito del plan maestro de pruebas es . definicin de los casos de prueba.. panorama de pruebas planeadas 3 4 5 5 6 7 8 9 9 9 9 10 10 11 11 11 15

Seguimiento Y Control Del Proyecto. modelo de un plan de prueba planificado Ciclo de plan de Prueba. cResultado de la ejecucin de las pruebas. Conclusiones Bibliografa.. .

17 19 24 27 29 30

Introduccin. Las tcnicas 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, tcnicas y mtodos que hacen a la excelencia del desempeo de un programa, as como tambin la mejor publicidad que una empresa dedicada a la produccin de software pueda tener. Pero de nada servira conocer todas las tcnicas de prueba de software, si un programa carece de documentacin, el cdigo es confuso, o no se han seguido pasos para la planificacin y desarrollo del software, ya que seria como buscar una aguja en un pajar. No solo las herramientas, tcnicas y mtodos de prueba, sino que tambin 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 errneos con el fin de analizar el proceso de ejecucin. Con este conjunto de pruebas seremos capaces de determinar si nuestro programa es errneo sobre todo en casos extremos y particulares, tanto si estos fallos se producen por la una mala implementacin del programa, o bien por un uso especifico que realiza el usuario. El aspecto ms importante para realizar la planificacin 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.

PRUEBAS. Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de vida, es la realizacin de controles peridicos. Estos controles buscan una evaluacin de la calidad de los productos generados para poder detectar posibles defectos cuanto antes. Sin embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe ser probado mediante su ejecucin controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo de software se denominan habitualmente pruebas. Las pruebas constituyen un mtodo ms 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 ejecucin se observan y se registran con el fin de realizar posteriormente una evaluacin de algn aspecto. Un caso de prueba (test case) se puede definir como un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular, por ejemplo verificar el cumplimiento de un determinado requerimiento. Las caractersticas especiales del software (no fsico, ausencia de leyes, que rijan su comportamiento, y complejidad) hacen aun ms difcil 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 pequeos y sencillos. Hay que recordar que el objetivo de las pruebas es detectar defectos en el software y que descubrir un defecto debera considerarse como el xito de una prueba. Tradicionalmente, existe el mito de la ausencia de errores en el buen profesional, situacin que no es real. Las pruebas permiten la rectificacin del software.

Los defectos no son siempre el resultado de la negligencia, sino que en su aparicin influyen mltiples factores, por ejemplo, la mala comunicacin entre usuarios y programadores. ASPECTOS A TENER EN CUENTA EN LA APLICACIN DE UNA PRUEBA Operatividad. Cuanto mejor funcione el software, ms eficientemente se puede probar. Ningn error debe bloquear la ejecucin de las pruebas. Observabilidad. Lo que ves es lo que pruebas. Un resultado incorrecto se

identifica fcilmente. Controlabilidad. Cunto mejor podamos controlar el software ms se puede Las pruebas pueden especificarse, automatizarse y

automatizar y optimizar.

reproducirse convenientemente. Capacidad de descomposicin. Controlando el mbito de las pruebas podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin. Los mdulos de software se pueden probar independientemente. Simplicidad. Cuanto menos haya que probar ms rpidamente podemos probarlo. Estabilidad. Cunto menos cambios haya, menos interrupciones a las pruebas. Facilidad de comprensin. Cuanta ms informacin tengamos, mejores sern las pruebas.

INSPECCIONES La inspeccin del software IEEE es una tcnica de evaluacin formal, en la cual los requisitos del software, diseo o la codificacin son examinados en detalle por una persona diferente al desarrollador, para detectar defectos, incoherencias con las normas de desarrollo y otros problemas. La inspeccin proporciona una indicacin inmediata y cuantitativa de la calidad, comenzando con los requerimientos y el diseo. Para que una inspeccin tenga xito se deben cumplir ciertas normas:

Las inspecciones se realizan en varios puntos del ciclo de vida del producto. Se deben inspeccionar todo tipo de defecto en toda la documentacin. En la inspeccin deben participar colegas y todo tipo de personal relacionado con el sistema.

La inspeccin se debe realizar segn una serie predefinida de etapas. Las inspecciones deben ser dirigidas por personal con experiencia. Los miembros del grupo de inspeccin deben tener tareas especficas asignados a cada uno.

El grupo de inspeccin debe contar con listas de chequeo y comprobacin para el control de las inspecciones realizadas.

Se debe inspeccionar el producto a una velocidad adecuada para encontrar posibles fallas.

Se deben archivar estadsticas de las inspecciones.

ETAPAS DE LAS INSPECCIONES Planificacin. Una vez se determina que un producto esta listo para inspeccin se define un equipo encargado de esa tarea, para lo cual planea una serie de actividades (para autor e inspector) con miras a la revisin del producto. Presentacin o visin general. Es una etapa opcional que tiene por objeto ofrecer una visin global del proyecto y explicar las funciones, organizacin y tcnica del producto. Preparacin. Aqu se define el trabajo que debe hacer cada inspector, a partir de la documentacin que le ha sido entregada. El inspector con los datos obtenidos se prepara para desempear un buen papel en la reunin (siguiente etapa). Reunin. Tiene por objetivo la bsqueda exhaustiva de defectos del producto analizado y por ello es la etapa ms importante del proceso. La reunin de ser dirigida por un moderador quien hacer parte del equipo de inspectores. Se recomienda llevar el siguiente orden:

Introduccin. Usada para presentar inspectores y recordar sus funciones. Establecer tiempos de preparacin de inspectores. El moderador verifica el tiempo que dedicaron a prepararse para la reunin. Lectura de producto, identificacin y anotacin de defectos. Pelean los defectos encontrados por cada inspector y se toma nota de ellos. Revisin de lista de defectos. Terminada la reunin se verifica cada uno de los defectos encontrados buscando un consenso entre grupo de inspectores. Determinar disposicin final del producto. Se define el concepto final para el producto. Los conceptos posibles son: afectados, afectado condicionalmente y rechazado. Correccin. En esta etapa el actor debe corregir los defectos encontrados por los inspectores y entregar el nuevo producto. Seguimiento. Cuando la correccin finalice, el autor en el moderador se renen de nuevo para revisar los resultados. Si el moderador aprueba los resultados se da por terminada la inspeccin. Si no los aprueba, el moderador puede solicitar una correccin adicional o convocar a otra inspeccin.

Pasos para el desarrollo de pruebas: - Obtener los requerimientos en forma clara. - Obtener planificacin de diseo. - Determinar funcionalidad. - Identificar aplicaciones de alto riesgo o con prioridad de prueba. - Determinar mtodos de prueba.
8

- 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 revisin 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 sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caractersticas, las actividades de pruebas, el personal responsable y los riesgos asociados. A continuacin se presenta el contenido bsico de un plan de pruebas: Identificar el documento Introduccin y resumen de elementos y caractersticas a probar Elementos de software que se van a probar Caractersticas que se van a probar Caractersticas que no se prueban Enfoque general de la prueba (Actividades, tcnicas, herramientas, etc) Criterios de aprobacin para cada elemento probado.

Criterios para suspender y requisitos para reanudar actividad Documentos a entregar Actividades de preparacin y ejecucin de pruebas Necesidades de entorno Responsabilidades en la organizacin y realizacin de las pruebas Necesidades de personal y de formacin Cronograma de tiempos y actividades Riesgos asumidos por el plan Aprobaciones y firmas con nombre y puesto desempeado.

Cmo se define un plan de prueba? - Titulo - Identificacin, nmeros de versin, creador, fecha de creacin. - Tabla de contenidos. - Reportes de reuniones. - Reportes de requerimientos. - Reportes de documentacin. - Anlisis 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.

10

- Informe de herramientas automatizadas. - Determinacin de la sanidad del programa. - Personal implicado. - Reportes relevantes. (Licencias, clasificaciones, mtodos, etc.) - Apndices, glosario, cronologa.

LA PRUEBAS DE UNIDAD La elaboracin 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 evaluacin o comprobacin de los distintos productos o modelos que se van creando. DESCRIPCIN 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 documentacin 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 mtodos: se probarn las entradas y las salidas y se comprobar que los valores obtenidos son los esperados. Es decir, se prueba el cdigo aislado, independiente del resto del sistema.

11

OBJETIVOS DE LAS PRUEBAS DE UNIDAD Esta manera describe los objetivos de la elaboracin de las pruebas de unidad, el camino a seguir en la elaboracin de las mismas por fases, y una descripcin 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 especfico. El objetivo principal sera producir las piezas de cdigo de la manera ms eficiente y eficaz posible generando pruebas de unidad para las mismas que aseguren su correcto comportamiento.

PLANIFICACIN DE LAS PRUEBAS DE SISTEMA

Las pruebas de sistema se harn una vez que el programa haya superado las pruebas unitarias y las de integracin. 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 especificacin 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 mnimos para entenderse como apto. Sirve para disear el plan de pruebas especfico. En el se definen los apartados mnimos que debe recoger un plan de pruebas especfico para un tipo de elemento hardware contemplado en la Gua de mbito, as como la metodologa para recoger y registrar los resultados de la ejecucin de las pruebas automticas y manuales.
12

En el mismo se exponen los puntos mnimos que debe recoger el plan de pruebas especfico diseado por la entidad de pruebas para un elemento hardware concreto. Cada uno de los puntos siguientes sern los ttulos de los apartados del plan de pruebas especfico. Plan de pruebas especfico para la elaboracin del plan. Definicin 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 composicin del mismo, as como una breve descripcin del equipo Se comprueba con la "Gua de mbito" durante el paso de "Recepcin y Preparacin 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 seleccin de las pruebas que sern realizadas: funcin que desarrollar el equipo bajo pruebas, nfasis en algn componente no descrito como prioritario en la gua de mbito, etc. UA DEABORACIN DEL PLAN DE PRUEBAS ESPECFICO 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 aadidos a un plan de pruebas genrico segn las necesidades. La estructura de los casos tambin permite conocer toda la informacin relativa a objetivos, ejecucin, resultados esperados, etc.

OBJETIVO. Es la descripcin genrica del caso. Se indica cul es el propsito del caso, qu informacin proporciona su ejecucin.

ENTRADA. Se describe el entorno necesario para poder ejecutar el caso (SW, HW, configuraciones, conexiones, etc.)

13

ACCIONES. Es la descripcin, paso a paso, de las acciones a realizar sobre el equipo bajo prueba descrito en "Entrada" para la consecucin del objetivo del caso.

SALIDA. Este campo permite establecer, mediante la comparacin de su contenido con los resultados obtenidos tras la aplicacin de las acciones del caso, el xito o fallo de la ejecucin de la prueba.

ETIQUETAS. Cada caso de prueba tiene una serie de atributos que permite clasificarlo en funcin de distintos criterios. Cada atributo est representado por una etiqueta. A continuacin se describen las etiquetas y sus posibles valores.

DEFINICIN 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 Descripcin Tarjeta red cableada, funcionalidad crtica, manual. 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 planteando una estrategia que conduzca al objetivo enfocado en el aseguramiento de calidad del software.

14

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 DEL PLAN MAESTRO DE PRUEBAS

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 usos para la ejecucin de las pruebas.

Pruebas Unitarias: Se validaran las piezas individuales del software como una unidad independiente, bucles, condicionales, etc.

15

Pruebas de integracin: Se validara la integracin entre los diferentes mdulos que componen la solucin con el fin de garantizar que su operacin integrada es correcta.

Pruebas Funcionales o de Procedimientos: Se validaran los procesos, reglas de negocio establecidas y los requerimientos funcionales.

Pruebas de sistema: Las pruebas de sistema se determinarn en el momento que el Outsourcing de Desarrollo entregue el documento de Requerimientos no funcionales, y as determinar que tipos de prueba se realizarn y a que casos de uso se aplicarn.

Pruebas de regresin: Se validara que el sistema mantenga su correcta funcionalidad debido a la incorporacin de un ajuste, correccin o nuevo requerimiento. Adicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que son crticos y de mayor relevancia para el proyecto, se determinan los tipos de pruebas que se realizarn para el proyecto, diseando los factores de calidad y las pruebas especializadas para alcanzar estos atributos del software entregado. Con esta misin se identifican de acuerdo a las especificaciones del cliente los factores

Especificacin Requerimientos de Software

Misin de las Pruebas aplicables al proyecto de software

La misin de la evaluacin de un 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.

16

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. PANORAMA DE PRUEBAS PLANEADAS

17

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.

Datos de Prueba Con el objetivo de realizar unas pruebas acertadas y lo ms cercanas a la realidad que sea posible, es necesario contar datos que alimenten la ejecucin de los casos de prueba, los cuales, en la medida de lo posible, deben ser reales, cubrir un rango considerable y representar una profundidad significativa dentro del dominio de los datos que maneja la organizacin en los procesos de negocio involucrados.

18

El Set de datos de prueba debe cumplir con la estructura del modelo de datos del negocio, y debe ser generados como una base de datos relacional que respete la integridad referencial requerida por el proceso (relaciones, jerarqua, restricciones etc.) Administracin de los Datos de Prueba Una vez construido el Set de datos de prueba, este es administrado por el equipo de proyecto siguiendo las polticas expuestas a continuacin: Se debe realizar un back up inicial del set de datos, antes de cualquier otro tratamiento, y este debe ser etiquetado apropiadamente para su posterior identificacin entre los dems backups que se llevarn a cabo. Se deben hacer scripts SQL que garanticen la integridad referencial del set de datos de prueba construida, de cara al modelo de datos que soporta la aplicacin. El set de datos solo ser aceptado si la ejecucin de dichos scripts de verificacin no arroja inconsistencias en las relaciones de los datos. El Set de datos se implanta en el ambiente de Pruebas La administracin del Set de datos de prueba queda nicamente asignada a los responsables fijados por el equipo de desarrollo para tal fin, se debe garantizar el acceso al Set de datos de prueba y a los backups haciendo uso de la seguridad que dispone el motor de base de datos utilizado Los Backups del set se realizan de la siguiente manera de acuerdo al ambiente:

SEGUIMIENTO Y CONTROL DEL PROYECTO Gestin de Requisitos Los requisitos del sistema son especificados en el artefacto Visin. Cada requisito tendr una serie de atributos tales como importancia, estado, iteracin donde se implementa, etc. Estos atributos permitirn realizar un efectivo seguimiento de cada requisito. Los cambios en los requisitos sern gestionados mediante una Solicitud de Cambio, las cuales sern evaluadas y distribuidas para asegurar la integridad del sistema y el correcto proceso de gestin de configuracin y cambios.
19

Control de Plazos El calendario del proyecto tendr un seguimiento y evaluacin 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 tambin en una Solicitud de Cambio tendrn un seguimiento para asegurar la conformidad respecto de la solucin de dichas deficiencias Para la revisin de cada artefacto y su correspondiente garanta de calidad se utilizarn las guas de revisin y checklist (listas de verificacin) incluidas en RUP. Gestin 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 iteracin. Gestin de Configuracin Se realizar una gestin de configuracin para llevar un registro de los artefactos generados y sus versiones. Tambin se incluir la gestin 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 iteracin se establecer una baseline (un registro del estado de cada artefacto, estableciendo una versin), la cual podr ser modificada slo por una Solicitud de Cambio aprobada.

PROPSITO DE UN PLAN DE PRUBA DETALLADO Este documento tiene como propsito establecer las tcnicas, herramientas y actividades relacionadas con la ejecucin y validacin 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.

20

ALCANCE DE UN PLAN DE PRUBA DETALLADO En este, se convierte en una gua para desarrollar de una forma organizada las diferentes actividades que se realizarn en el proceso del plan de pruebas en el desarrollo del proyecto. La metodologia de pruebas y el plan de pruebas permitirn al equipo profesionales expertos que participan en el frente de pruebas del proyecto, evaluar aspectos como: La lgica estructural, la seguridad, la interconexin, el soporte conceptual, las herramientas de apoyo y sobretodo la independencia de aspectos tcnicos del desarrollo de la solucin tecnolgica contratada, tales como: la plataforma tecnolgica o la arquitectura de la

solucin a probar, sin embargo a continuacin se describen las diferentes pruebas a ser aplicadas: MODELO DE UN PLAN DE PRUEBA PLANIFICADO TIPO DE PRUEBA DEFINICIONES FASE DE RUP ELABORACIN UNITARIAS Unitarias: Permite verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado.

Integracin: Permite verificar el correcto ensamblaje INTEGRACIN entre los distintos mdulos que componen el sistema desarrollado.

21

SISTEMA: Carga Volumen Estrs Robustez Concurrencia,

Sistema: Estas pruebas buscan diferencias entre la solucin desarrollada y los requerimientos, con el fin de identificar errores que se puedan generar entre la especificacin funcional y el diseo del sistema. Carga: Valida aquellos volmenes de datos mximos especificados en los requerimientos no Funcionales

Interfaz de Usuario Volumen: Esta prueba somete el software a grandes Recuperacin a cantidades de datos para determinar si se alcanzan Fallas lmites que causen la falla del software Rendimiento Seguridad Integridad de las BD Interoperabilidad Desempeo Configuracin Estrs: Valida aquellos volmenes de datos mximos que resiste el sistema antes de comenzar con errores. Robustez: Valida si el sistema se mantiene estable y consistente despus de circunstancias adversas Concurrencia: Valida la capacidad del sistema de atender mltiples solicitudes departe de los usuarios que acceden a un mismo recurso. Interfaz de usuario: Ppermite verificar que la navegacin a travs de los elementos que se estn probando, reflejen las funciones del negocio y los requerimientos funcionales. Recuperacin a fallas: Estas pruebas aseguran que el que el software pueda recuperarse a fallas de hardware, software o mal funcionamiento de la red sin prdida de datos o de integridad de los datos.

22

Rendimiento: Permite validar si la aplicacin cumple los criterios de tiempos de respuesta establecidos. Seguridad: Verifica el cumplimiento de las polticas de seguridad acordadas para el sistema. Integridad de las bases de datos: Consiste en asegurar que los mtodos y procesos de acceso a la CONSTRUCCIN base de datos funcionan correctamente y sin corromper datos. Interoperabilidad: Esta prueba permite verificar todos los artefactos de la solucin desarrollada, su

arquitectura base, los protocolos de la solucin, las interfaces y los mdulos del sistema, funcionando en forma conjunta. Desempeo: Este tipo de prueba es un aspecto fundamental en una aplicacin, ya que si sta no responde en el debido tiempo, se pueden perder clientes, o daar la imagen ante los usuarios. Configuracin: Establece y mantiene la integridad de los productos de software a travs del ciclo de vida del proceso del mismo.

FUNCIONALES

Funcional: La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificacin funcional.

23

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. Instalacin: Esta prueba permite verificar la

instalacin y desinstalacin de la aplicacin en diferentes entornos de hardware y software

ACEPTACIN

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 tiempo TRANSICIN

REGRESIN

24

PLANIFICACIN Para el desarrollo de la solucin del Sistema, se considera de gran importancia la

ejecucin del plan de pruebas, hacindose necesario la planificacin de las mismas, lo que en consecuencia hace necesario tener claro los siguientes planteamientos: Se planifican pruebas personalizando los estndares especficamente para el proyecto de notificaciones. Se definen niveles de pruebas a aplicar. Se especifican las tcnicas a utilizar. Se establece el tiempo para la ejecucin de cada una de las pruebas. Uso de herramientas. Criterios de aceptacin. Recursos involucrados.

25

En la definicin del plan de pruebas, se valorar: El alcance de la aplicacin. La complejidad de sus procesos. Plataforma/s en las que se debe probar. Conocimientos y formacin de quienes ejecutarn las pruebas. Normativas legales aplicables. Otros recursos involucrados.

Se tendr en cuenta que: Las pruebas estarn presentes a lo largo de todo el ciclo de vida del desarrollo, de la solucin. 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 actualizacin 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 planificacin: Cronograma detallado de la ejecucin de las pruebas; donde se especifica qu prueba se realiza, cunto tiempo se estima para su ejecucin, recursos a utilizar (humanos y tecnolgicos); este cronograma se encuentra dentro del cronograma general del proyecto y especficamente en la fase desarrollo. Formatos a utilizar para el diseo de las pruebas.

26

Formatos a utilizar para el registro y anlisis de los resultados de las pruebas. Herramientas a utilizar para la gestin de incidencias. Procedimientos para el control de cambios. Herramientas a utilizar para la ejecucin de las pruebas.

DISEO DE LAS PRUEBAS Para el diseo de las pruebas, se tendrn en cuenta aspectos que permitirn encontrar defectos en el periodo de desarrollo del software, la realizacin de pruebas propias de verificacin y validacin de datos, segn se aclara en los siguientes tems: Alcance: El alcance de las pruebas estar dado por el marco del Sistema de Notificacin en Lnea, que se encuentra en desarrollo, sta compuesta (Informacin tomada de los trminos de referencia y del documento de Arquitectura General Detallada) por: Modelo Conceptual. Procesos. Descripcin de Procesos. Vista de Casos de Uso. Vista Lgica. Diseo de las clases y su organizacin en paquetes y subsistemas. Vista de Datos. Vista de Implementacin. Vista de Despliegue. Vista de Integracin con Sistemas Externos. Vista de Parametrizacin del Sistema. Requerimientos no Funcionales. Prototipos del sistema

27

Inventario de las Pruebas: En esta seccin 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 entraran en una regresin y cules no con mayor facilidad. Recortar alcance en forma rpida y ordenada. Se estima el tiempo en probar cada funcionalidad. Evaluar aspectos tcnicos del sistema.

RESULTADO DE LA EJECUCIN DE LAS PRUEBAS: En este punto se resaltan las entradas fundamentales que son la partida para la ejecucin del plan de pruebas. Inventario de pruebas priorizado. Estimacin de esfuerzo de cada funcionalidad. Plan de desarrollo del producto. Plazos previstos para el proyecto.

28

EVALUACIN Y CIERRE Para la evaluacin 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 llevarn a cabo comits tcnicos de seguimiento peridico semanal donde se evalen los siguientes temas. Avance de las pruebas segn cronograma Estado o resultado de las pruebas ejecutadas Seguimiento a las incidencias reportadas segn la ejecucin de pruebas. Se presentar plan de contingencia para aquellas incidencias de mayor impacto que sean de riesgo para el proyecto.

29

CONCLUSIONES

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. Las pruebas de software se aplican en la fase de prueba y validacin del desarrollo de un sistema de informacin y son un conjunto de herramientas tcnicas y mtodos que tienen como objeto comprobar los requerimientos establecidos con los usuarios o beneficiarios del producto. Estas tcnicas tienen como objeto detectar problemas y son extensamente variadas y van desde el uso del ingenio por parte del personal de pruebas hasta herramientas automticas que ayudan a aliviar el peso y el costo de esta actividad. Las pruebas no pueden asegurar la ausencia de errores; slo puede demostrar que existen defectos en el software. La verificacin tpicamente incluye por parte de los desarrolladores la revisin de los planes, del cdigo, de los requerimientos, de la documentacin, las especificaciones y posteriormente una reunin con los usuarios para evaluar dichos documentos. Esto puede ser hecho con listas de chequeos, listas de problemas. La validacin tpicamente incluye las pruebas del software y comienza despus que la verificacin este completa. La inspeccin es una reunin 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 mtodos 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 mtodos de prueba y controles de calidad en las cuales el usuario debe optar definiendo el mismo el nivel de calidad.

30

BIBLIOGRAFIA

Fundamentos de Ingeniera del Software, Bertrand Meyer. Unidad de proyecto, Universidad Politcnica de Madrid Facultad de Informtica Calidad del Software, universidad de San Carlos. Anlisis de sistema, diseo y Metodos, Whitten Bentley.

FUENTES ELECTRONICAS: www.google.com www.cenatic.es/boletines. http://iutmaragoza.blogcindario.com/2010/07/00002-unidad-iii-pruebas-y-calidad-delsoftware.html http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF

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

31