You are on page 1of 31

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

Enero del 2013.

1

INDICE Introducción……………………………….…………………………………… Pruebas………………………………………………………............................. Aspectos a tener en cuenta en la aplicación de una prueba. .......................... Inspecciones…………………………………………………………………. etapas de las inspecciones…….……………………………………… Pasos para el desarrollo de pruebas............................................................................ plan de pruebas……………………………………………………………........  cómo se define un plan de prueba ………………………………………… La pruebas de unidad………………………………………………………… Descripción pruebas de unidad……………………………………............................  alcance de la pruebas de unidad …………………………... objetivos de la pruebas de unidad…………………………………… planificación de las pruebas de sistema …………………………... estructura de los casos de prueba…………………………………... propósito del plan maestro de pruebas es ……………………………………………. definición 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

2

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

3

4 . ya que seria como buscar una aguja en un pajar. o no se han seguido pasos para la planificación y desarrollo del software. técnicas y métodos de prueba. 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. La prueba de software es un conjunto de herramientas. así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener. si un programa carece de documentación. el código es confuso. Pero de nada serviría conocer todas las técnicas de prueba de software. 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. técnicas y métodos que hacen a la excelencia del desempeño de un programa. No solo las herramientas. La necesidad de comprobar el correcto funcionamiento del producto hace que sea imprescindible un plan de pruebas. 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.Introducción. 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.

Tradicionalmente. 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. y complejidad) hacen aun más difícil la tarea de probarlo. todo sistema o aplicación. Estos controles buscan una evaluación de la calidad de los productos generados para poder detectar posibles defectos cuanto antes. posteriores a la terminación del código de software se denominan habitualmente pruebas. Los resultados de la ejecución se observan y se registran con el fin de realizar posteriormente una evaluación de algún aspecto.PRUEBAS. es la realización de controles periódicos. Las pruebas exhaustivas del software son impracticables. 5 . Estas ejecuciones o ensayos de funcionamiento. existe el mito de la ausencia de errores en el buen profesional. que rijan su comportamiento. Las características especiales del software (no físico. situación que no es real. Las pruebas constituyen un método más para poder verificar y validar el software. por ejemplo verificar el cumplimiento de un determinado requerimiento. Sin embargo. Un caso de prueba (test case) se puede definir como un conjunto de entradas. ya que no se pueden probar todas las posibilidades de su funcionamiento incluso en programas pequeños y sencillos. condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. debe ser probado mediante su ejecución controlada antes de ser entregado al cliente. Una de las características típicas del desarrollo de software basado en el ciclo de vida. Las pruebas permiten la rectificación del software. ausencia de leyes. independientemente de estas revisiones. Se puede definir prueba como una actividad en la cual un sistema o uno de sus componentes se ejecutan en circunstancias previamente especificadas.

Facilidad de comprensión. comenzando con los requerimientos y el diseño. por ejemplo. ASPECTOS A TENER EN CUENTA EN LA APLICACIÓN DE UNA PRUEBA Operatividad. en la cual los requisitos del software. automatizarse y automatizar y optimizar. la mala comunicación entre usuarios y programadores.Los defectos no son siempre el resultado de la negligencia. reproducirse convenientemente. para detectar defectos. La inspección proporciona una indicación inmediata y cuantitativa de la calidad. Estabilidad. mejores serán las pruebas. Capacidad de descomposición. Observabilidad. Un resultado incorrecto se identifica fácilmente. menos interrupciones a las pruebas. Cuanto menos haya que probar más rápidamente podemos probarlo. más eficientemente se puede probar. Para que una inspección tenga éxito se deben cumplir ciertas normas: 6 . Ningún error debe bloquear la ejecución de las pruebas. Los módulos de software se pueden probar independientemente. INSPECCIONES La inspección del software IEEE es una técnica de evaluación formal. Controlabilidad. Cuanta más información tengamos. diseño o la codificación son examinados en detalle por una persona diferente al desarrollador. incoherencias con las normas de desarrollo y otros problemas. Simplicidad. Cuanto mejor funcione el software. Lo que ves es lo que pruebas. Controlando el ámbito de las pruebas podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. Cuánto mejor podamos controlar el software más se puede Las pruebas pueden especificarse. Cuánto menos cambios haya. sino que en su aparición influyen múltiples factores.

Una vez se determina que un producto esta listo para inspección se define un equipo encargado de esa tarea. - Se debe inspeccionar el producto a una velocidad adecuada para encontrar posibles fallas. Tiene por objetivo la búsqueda exhaustiva de defectos del producto analizado y por ello es la etapa más importante del proceso. Se recomienda llevar el siguiente orden: 7 . para lo cual planea una serie de actividades (para autor e inspector) con miras a la revisión del producto. - Se deben archivar estadísticas de las inspecciones.- Las inspecciones se realizan en varios puntos del ciclo de vida del producto. Las inspecciones deben ser dirigidas por personal con experiencia. - La inspección se debe realizar según una serie predefinida de etapas. - El grupo de inspección debe contar con listas de chequeo y comprobación para el control de las inspecciones realizadas. Aquí se define el trabajo que debe hacer cada inspector. Reunión. El inspector con los datos obtenidos se prepara para desempeñar un buen papel en la reunión (siguiente etapa). organización y técnica 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. ETAPAS DE LAS INSPECCIONES Planificación. La reunión de ser dirigida por un moderador quien hacer parte del equipo de inspectores. Presentación o visión general. Los miembros del grupo de inspección deben tener tareas específicas asignados a cada uno. a partir de la documentación que le ha sido entregada. Es una etapa opcional que tiene por objeto ofrecer una visión global del proyecto y explicar las funciones. Preparación.

identificación y anotación de defectos.Determinar funcionalidad. Establecer tiempos de preparación de inspectores. Corrección. .Identificar aplicaciones de alto riesgo o con prioridad de prueba. Seguimiento. Revisión de lista de defectos. El moderador verifica el tiempo que dedicaron a prepararse para la reunión. Los conceptos posibles son: afectados.Introducción. Si no los aprueba.Obtener planificación de diseño. el autor en el moderador se reúnen de nuevo para revisar los resultados.Determinar métodos de prueba. Terminada la reunión se verifica cada uno de los defectos encontrados buscando un consenso entre grupo de inspectores. . Si el moderador aprueba los resultados se da por terminada la inspección. Se define el concepto final para el producto. . Pasos para el desarrollo de pruebas: . En esta etapa el actor debe corregir los defectos encontrados por los inspectores y entregar el nuevo producto. Cuando la corrección finalice. afectado condicionalmente y rechazado. Usada para presentar inspectores y recordar sus funciones. Pelean los defectos encontrados por cada inspector y se toma nota de ellos. 8 . Determinar disposición final del producto. . el moderador puede solicitar una corrección adicional o convocar a otra inspección.Obtener los requerimientos en forma clara. Lectura de producto.

.Volver a probar si es necesario. . etc) Criterios de aprobación para cada elemento probado.Aprobar una revisión en la prueba. así como los elementos a probar. PLAN DE PRUEBAS Es un documento que tiene como objetivo señalar el enfoque. 9 . técnicas.Evaluar resultados en reportes.Documentar errores del programa.Obtener datos de prueba.Buscar bugs. . . herramientas. . .Clasificar errores del programa. 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.Actualizar el plan de prueba. el personal responsable y los riesgos asociados. las actividades de pruebas.Redactar los casos de prueba que encontraron fallas. . .Determinar contexto de la prueba. los recursos y el esquema de actividades de prueba. . .Estimar tiempo de prueba. las características. .

. ¿Cómo se define un plan de prueba? . . . . 10 . . .Identificación.Titulo .) .Reporte de resultados.Limites.Reportes de documentación. etc.Reportes de reuniones. fecha de creación. . riesgos. .Tabla de contenidos. .Análisis de riesgos.Reporte de datos de prueba.- 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.Reporte de aplicaciones conjuntas al programa. creador. (Tiempo.Reportes de requerimientos.Prioridades y focos de prueba. números de versión.

Informe de herramientas automatizadas. se prueba el código aislado.Apéndices. en paralelo al proceso de avance. Por consiguiente se hace necesario llevar a cabo. es la forma definida a los pasos para llevar a cabo estas pruebas. las actividades a realizar y la documentación de entrada y salida que las conforman. (Licencias. describiendo. . Para afirmar que se han alcanzado los niveles de calidad exigido es necesario ajustar el producto software a medida que se va construyendo. glosario. clasificaciones. Es decir. ALCANCE DE LA PRUEBAS DE UNIDAD Este procedimiento está dirigido a realizar las pruebas de unidad. 11 . etc. DESCRIPCIÓN PRUEBAS DE UNIDAD Es la manera para ejecutar pruebas de unidad. LA PRUEBAS DE UNIDAD La elaboración de un procedimiento o proyecto de software tiene como finalidad satisfacer una necesidad planteada por el usuario..Reportes relevantes.Personal implicado. métodos. . independiente del resto del sistema. un proceso de evaluación o comprobación de los distintos productos o modelos que se van creando. cronología. La misma analiza en detalle cada una de las fases que forma este procedimiento.) . . ¿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.Determinación de la sanidad del programa.

Las pruebas unitarias desarrolladas en este procedimiento tienen como finalidad aislar cada parte del programa y mostrar que las partes individuales son correctas. el camino a seguir en la elaboración de las mismas por fases. Son fragmentos de unidades estructurales del programa encargados de una tarea en específico. así como la metodología para recoger y registrar los resultados de la ejecución de las pruebas automáticas y manuales.OBJETIVOS DE LAS PRUEBAS DE UNIDAD Esta manera describe los objetivos de la elaboración de las pruebas de unidad. Esto supone que se realizaran un conjunto de pruebas que confirmen el funcionamiento general del programa en concordancia con los resultados esperados. 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. y una descripción detallada de éstas. 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. Sirve para diseñar el plan de pruebas 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. puesto que las clases ya funcionan correctamente de forma individual y conjuntamente. 12 . 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.

junto con cualquier particularidad del hardware entregado. escenario a probar y composición del mismo. etc. Cada uno de los puntos siguientes serán los títulos de los apartados del plan de pruebas específico. que permite describirlos de modo que puedan ser identificados y añadidos a un plan de pruebas genérico según las necesidades. HW. 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. Se indica cuál es el propósito del caso. es decir.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. etc. Definición del equipo bajo pruebas y su escenario.) 13 . Así mismo. OBJETIVO. “Plan de pruebas específico” para la elaboración del plan. 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. conexiones. resultados esperados. énfasis en algún componente no descrito como prioritario en la guía de ámbito. qué información proporciona su ejecución. etc. En este apartado se especificará el alcance de las pruebas a realizar. 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. La estructura de los casos también permite conocer toda la información relativa a objetivos. Se describe el entorno necesario para poder ejecutar el caso (SW. configuraciones. ejecución. ENTRADA. Es la descripción genérica del caso.

al conectarle el cable de red. Acciones Inicio Arrancar el equipo Proceso Con el equipo encendido y el sistema operativo en funcionamiento. mediante la comparación de su contenido con los resultados obtenidos tras la aplicación de las acciones del caso. 14 . Salida La tarjeta de red detecta link. Es la descripción. ETIQUETAS. El propósito del plan de pruebas planteado en este documento. DEFINICIÓN DE LOS CASOS DE PRUEBA ¿Detecta la tarjeta un cable de red enchufado en caliente? (Si/No) Objetivo: Comprobar que el equipo. conectamos un cable de red y comprobamos que se conecta correctamente a la red disponible. el éxito o fallo de la ejecución de la prueba. Entrada Entorno Equipo con sistema operativo instalado y cable de red conectado a elemento activo de red. de las acciones a realizar sobre el equipo bajo prueba descrito en "Entrada" para la consecución del objetivo del caso. Etiquetas Descripción Tarjeta red cableada. Cada atributo está representado por una etiqueta. lo detecta sin problemas. paso a paso. SALIDA. 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. manual. Este campo permite establecer. estando encendido. A continuación se describen las etiquetas y sus posibles valores.ACCIONES. funcionalidad crítica. Cada caso de prueba tiene una serie de atributos que permite clasificarlo en función de distintos criterios.

Enmarcar la metodología de pruebas que será utilizada Identificar los recursos requeridos y proveer un estimado del esfuerzo de las pruebas. 15 . y es el plan de más alto nivel que será usado por los administradores para guiar y dirigir el trabajo de pruebas detallado. etc. condicionales.  Elaborar un listado de los elementos entregables del plan de pruebas.  Pruebas Unitarias: Se validaran las piezas individuales del software como una unidad independiente. y dónde es apropiado que los interesados aprueben el plan. bucles. Este define el enfoque general que será empleado para probar el software y para evaluar los resultados de esas pruebas. 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.  Este Plan Maestro de Pruebas también soporta los siguientes objetivos específicos:    Identificar los ítems que serán objeto de las 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.EL PROPÓSITO DEL PLAN MAESTRO DE PRUEBAS ES:  Proveer un artefacto central que gobierne la planeación y control del esfuerzo de pruebas.  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.

no debe hacer. 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. 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 de regresión: Se validara que el sistema mantenga su correcta funcionalidad debido a la incorporación de un ajuste. y así determinar que tipos de prueba se realizarán y a que casos de uso se aplicarán. diseñando los factores de calidad y las pruebas especializadas para alcanzar estos atributos del software entregado. reglas de negocio establecidas y los requerimientos funcionales.  Pruebas Funcionales o de Procedimientos: Se validaran los procesos. De igual forma verificar si ésta hace o no lo que se supone. 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. 16 . debe hacer. se determinan los tipos de pruebas que se realizarán para el proyecto.  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. 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.

  Evaluar la calidad del producto y satisfacción de los interesados Cumplir con los requerimientos del cliente. 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. antes de que sean de gran impacto en fases más adelantadas del proyecto. PANORAMA DE PRUEBAS PLANEADAS 17 . El proceso de evaluación y pruebas debe permitir detectar problemas desde el inicio de la especificación de requerimientos. esto con el fin de disminuir los riesgos y de obtener un producto con calidad logrando mayor satisfacción del cliente.

El entorno de pruebas no es lo suficientemente estable como para confiar en los resultados. Claridad en el procedimiento para el desarrollo de las pruebas. Criterios de suspensión y Reanudación   Una característica principal tiene un error que impide probar un área importante.CRITERIOS DE ENTRADA Y SALIDA Criterios de Entrada del Plan Maestro de Pruebas     Set de pruebas completo y claro. Datos de Prueba Con el objetivo de realizar unas pruebas acertadas y lo más cercanas a la realidad que sea posible. Tener un entorno de pruebas adecuado. Toda la documentación requerida para la realización de las pruebas debe estar disponible. cumpliendo los criterios de aceptación definidos para cada uno. en la medida de lo posible. 18 . 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. es necesario contar datos que alimenten la ejecución de los casos de prueba. 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. 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. los cuales.   El entorno de pruebas es muy diferente del entorno de producción. deben ser reales.

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. Estos atributos permitirán realizar un efectivo seguimiento de cada requisito.El Set de datos de prueba debe cumplir con la estructura del modelo de datos del negocio. etc. restricciones etc. 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. y este debe ser etiquetado apropiadamente para su posterior identificación entre los demás backups que se llevarán a cabo. de cara al modelo de datos que soporta la aplicación.  Se deben hacer scripts SQL que garanticen la integridad referencial del set de datos de prueba construida.) Administración de los Datos de Prueba Una vez construido el Set de datos de prueba. Los cambios en los requisitos serán gestionados mediante una Solicitud de Cambio. 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. jerarquía. y debe ser generados como una base de datos relacional que respete la integridad referencial requerida por el proceso (relaciones. estado.  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. Cada requisito tendrá una serie de atributos tales como importancia. 19 . 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. antes de cualquier otro tratamiento. iteración donde se implementa.

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.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. 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. 20 . incluye responsabilidades de cada una de las tareas. herramientas y actividades relacionadas con la ejecución y validación del plan de pruebas. estableciendo una versión). Esta lista será evaluada al menos una vez en cada iteración. 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. informando y publicando dichos cambios para que sean accesibles a todo los participantes en el proyecto. 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. 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. Al final de cada iteración se establecerá una baseline (un registro del estado de cada artefacto.

La metodologia de pruebas y el plan de pruebas permitirán al equipo profesionales expertos que participan en el frente de pruebas del proyecto. la seguridad. evaluar aspectos como: La lógica estructural. tales como: la plataforma tecnológica o la arquitectura de la solución a probar. 21 . 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. el soporte conceptual. Integración: Permite verificar el correcto ensamblaje INTEGRACIÓN entre los distintos módulos que componen el sistema desarrollado. la interconexión.ALCANCE DE UN PLAN DE PRUBA DETALLADO En este. las herramientas de apoyo y sobretodo la independencia de aspectos técnicos del desarrollo de la solución tecnológica contratada. 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 ELABORACIÓN UNITARIAS Unitarias: Permite verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado.

software o mal funcionamiento de la red sin pérdida de datos o de integridad de los datos.       22 . Carga: Valida aquellos volúmenes de datos máximos especificados en los requerimientos no Funcionales Interfaz de Usuario Volumen: Esta prueba somete el software a grandes Recuperación a cantidades de datos para determinar si se alcanzan Fallas límites que causen la falla del software Rendimiento Seguridad Integridad de las BD Interoperabilidad Desempeño Configuración Estrés: Valida aquellos volúmenes de datos máximos que resiste el sistema antes de comenzar con errores. Sistema: Estas pruebas buscan diferencias entre la solución desarrollada y los requerimientos. reflejen las funciones del negocio y los requerimientos funcionales.SISTEMA:       Carga Volumen Estrés Robustez Concurrencia. con el fin de identificar errores que se puedan generar entre la especificación funcional y el diseño del sistema. Recuperación a fallas: Estas pruebas aseguran que el que el software pueda recuperarse a fallas de hardware. Interfaz de usuario: Ppermite verificar que la navegación a través de los elementos que se están probando. 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.

23 . Seguridad: Verifica el cumplimiento de las políticas de seguridad acordadas para el sistema. FUNCIONALES Funcional: La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificación funcional. Interoperabilidad: Esta prueba permite verificar todos los artefactos de la solución desarrollada. los protocolos de la solución. su arquitectura base. Desempeño: Este tipo de prueba es un aspecto fundamental en una aplicación. funcionando en forma conjunta. las interfaces y los módulos del sistema. o dañar la imagen ante los usuarios. ya que si ésta no responde en el debido tiempo. Integridad de las bases de datos: Consiste en asegurar que los métodos y procesos de acceso a la CONSTRUCCIÓN base de datos funcionan correctamente y sin corromper datos.Rendimiento: Permite validar si la aplicación cumple los criterios de tiempos de respuesta establecidos. se pueden perder clientes. Configuración: Establece y mantiene la integridad de los productos de software a través del ciclo de vida del proceso del mismo.

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. o usabilidad. Usabilidad: Esta prueba permite encontrar problemas de factores humanos. 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 tiempo TRANSICIÓN REGRESIÓN 24 .Caja Negra: Estas pruebas permiten obtener conjuntos de condiciones de entrada que ejecutan todos los requisitos funcionales de un programa.

Recursos involucrados. Uso de herramientas. se considera de gran importancia la ejecución del plan de pruebas. Se especifican las técnicas a utilizar. Se definen niveles de pruebas a aplicar. 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. Criterios de aceptación.PLANIFICACIÓN Para el desarrollo de la solución del Sistema. 25 . haciéndose necesario la planificación de las mismas. Se establece el tiempo para la ejecución de cada una de las pruebas.

este cronograma se encuentra dentro del cronograma general del proyecto y específicamente en la fase desarrollo.En la definición del plan de pruebas. Siempre hay errores. Resultado de la planificación: Cronograma detallado de la ejecución de las pruebas. Se puede disponer de herramientas. cuánto tiempo se estima para su ejecución. de la solución. La complejidad de sus procesos. Plataforma/s en las que se debe probar. Probar exhaustivamente el software es imposible. No es recomendable que el programador pruebe sus propios programas. 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. Conocimientos y formación de quienes ejecutarán las pruebas. se valorará:       El alcance de la aplicación. Otros recursos involucrados. Normativas legales aplicables. 26 . Se tendrá en cuenta que:       Las pruebas estarán presentes a lo largo de todo el ciclo de vida del desarrollo. donde se especifica qué prueba se realiza.  Formatos a utilizar para el diseño de las pruebas. recursos a utilizar (humanos y tecnológicos).

DISEÑO DE LAS PRUEBAS Para el diseño de las pruebas. Vista de Datos. que se encuentra en desarrollo. Procesos. Vista Lógica. Descripción de Procesos. ésta compuesta (Información tomada de los términos de referencia y del documento de Arquitectura General Detallada) por:              Modelo Conceptual.    Formatos a utilizar para el registro y análisis de los resultados de las pruebas. la realización de pruebas propias de verificación y validación de datos. Vista de Parametrización del Sistema. 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. Procedimientos para el control de cambios. Vista de Integración con Sistemas Externos. Herramientas a utilizar para la ejecución de las pruebas. Vista de Despliegue. Diseño de las clases y su organización en paquetes y subsistemas. Vista de Implementación. se tendrán en cuenta aspectos que permitirán encontrar defectos en el periodo de desarrollo del software. Vista de Casos de Uso. Requerimientos no Funcionales. Prototipos del sistema 27 . Herramientas a utilizar para la gestión de incidencias.

Estimación de esfuerzo de cada funcionalidad. Plan de desarrollo del producto. Decidir qué casos entrarían en una regresión y cuáles no con mayor facilidad. 28 . el cual permitirá:       Definir y asignar prioridades como. Recortar alcance en forma rápida y ordenada. 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. Plazos previstos para el proyecto. alta.      Inventario de pruebas priorizado. Establecer un orden de trabajo. media o baja. Se estima el tiempo en probar cada funcionalidad.Inventario de las Pruebas: En esta sección se especifica el inventario de las pruebas. Evaluar aspectos técnicos del sistema.

    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. El contenido de este informe estará compuesto de la manera descrita en la “Propuesta de esquema y contenido del Informé de pruebas”.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. Se presentará plan de contingencia para aquellas incidencias de mayor impacto que sean de riesgo para el proyecto. 29 . 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.

sólo puede demostrar que existen defectos en el software. del código. La verificación típicamente incluye por parte de los desarrolladores la revisión de los planes. programadores. y personal de prueba (testers) donde acuerdan con los usuarios los métodos de seguridad prueba a llevar a cabo.CONCLUSIONES Dentro de los principales motivadores de pruebas del proyecto. 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 especificaciones y posteriormente una reunión con los usuarios para evaluar dichos documentos. generalmente incluye personal de diferentes sectores esencialmente analistas. 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. 30 . La validación típicamente incluye las pruebas del software y comienza después que la verificación este completa. Las pruebas no pueden asegurar la ausencia de errores. están. La inspección es una reunión formal luego de la listas de problemas. de los requerimientos. Esto puede ser hecho con listas de chequeos. de la documentación. la necesidad del cliente de optimizar y gestionar la ejecución de sus procesos de negocio. 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. listas de problemas. 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.

BIBLIOGRAFIA Fundamentos de Ingeniería del Software. Análisis de sistema.com/2010/07/00002-unidad-iii-pruebas-y-calidad-delsoftware. http://iutmaragoza. Whitten Bentley.html http://gidis.blogcindario.ing.PDF [Escriba una cita del documento o del resumen de un punto interesante. universidad de San Carlos.edu.cenatic. Unidad de proyecto.ar/downloads/pdfs/Calidad_software. Universidad Politécnica de Madrid Facultad de Informática Calidad del Software.unlpam.] 31 . Utilice la ficha Herramientas de cuadro de texto para cambiar el formato del cuadro de texto de la cita. FUENTES ELECTRONICAS: www.com www. Bertrand Meyer.google.es/boletines. diseño y Metodos. Puede situar el cuadro de texto en cualquier lugar del documento.