Criterios para la realización de pruebas/Plan de pruebas VERIFICACIÓN Y VALIDACIÓN DOCENTE: PRESENTA: SANTOS MEDEL AGUILAR
Introducción La producción de software enfrenta uno de los grandes problemas, que es fundamental para el desarrollo de las tecnologías de la información como lo es el costo de desarrollo y la calidad con que estos son entregados a usuarios finales para su uso.
Verificación y validación La verificación y validación es el nombre que se da a los procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes. La V&V es un proceso de ciclo de vida completo, inicia con revisiones de los requerimientos y continua con las revisiones del diseño y las inspecciones del código hasta la prueba del producto
OBJETIVOS V&V Detectar y corregir los defectos tan pronto como sea posible en el ciclo de vida del software. Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el programa de tiempos. Mejorar la calidad y fiabilidad del software. Mejorar la visibilidad de la gestión del proceso de desarrollo. Valorar rápidamente los cambios propuestos y sus consecuencias.
Diferencias Verificación vs Validación ValidaciónVerificación ¿Estamos construyendo el producto concreto? La validación es un proceso más general, donde se debe asegurar que el software cumple con las expectativas del cliente. ¿Estamos construyendo el producto correctamente? El papel de la verificación comprende en comprobar que el software ésta de acuerdo con su especificación.
Pruebas - Tipos Las pruebas de un sistema aseguran que los requerimientos se cumplan, validan de modo sistemático cada requerimiento. Se requiere una escritura de pruebas considerable para la validación de cada requerimiento. Prueba de interfaz Prueba de sistema Prueba de utilidad Prueba para los requerimientos de interfaz de usuarios Pruebas de instalación
Puntos a saber para las pruebas 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.). Riesgos, etc.
Preparación de las pruebas En esta fase se identifica acuerdan y especifican los atributos y características de calidad que se van a probar. El objetivo es diseñar las pruebas para que tengan la mayor probabilidad de encontrar defectos con la mínima cantidad de esfuerzos y tiempo.
Productos de la prueba En esta fase se pretende ver un resultado de las pruebas realizadas y poder obtener los siguiente para seguir una valoración adecuada. o Pruebas exploratorias. o Pruebas de regresión. o Pruebas de compatibilidad. o Pruebas de integración. o Pruebas de aceptación.
Criterios y planificación de pruebas La planificación puede ser de la siguiente manera. Planificación general: Objetivos, complejidad, cronograma, responsabilidades, etc. Planificación técnica: Estándares, herramientas, infraestructura, procedimientos. Criterios: Tiempo asignado, test con resultados esperados, etc.
Plan de pruebas Su propósito es explicar el alcance, enfoque, manejo de riesgo de un proceso de pruebas. Un plan de pruebas incluye: o Identificador del plan o Alcance o Ítems a probar o Estrategias o Etcétera.
Estructura de los casos de prueba la forma de verificar las funcionalidades de un software son el punto de partida para la preparación de los casos de prueba y elegir el procedimiento adecuado. Las funcionalidades pueden separarse en dos grupos. Cuando las entradas deben completarse antes de que el sistema se lance a realizar una función, básicamente sin retroalimentación que pueda influir en el usuario. Es el caso de una sola variable, una solo acción a través de un botón, incluye la lectura de lista de datos cuyo proceso se realiza cuando la lista ha terminado.
PLAN DE PRUEBAS
Introducción Permite tener una planeación de la aplicación de las pruebas y el tipo de pruebas que harán que el sistema funcione correctamente Al momento de liberarse por completo, se crea seguridad en los usuarios finales de que el sistema no fallará Existen dos actividades fundamentales para la etapa de pruebas: las pruebas de componentes y las pruebas del sistema En la primera se prueban las partes del sistema por separado En la segunda se prueban los componentes ya integrados, el sistema como un todo
Objetivos del proceso de pruebas Demostrar al desarrollador y al cliente que el software satisface sus requerimientos. En este caso, se debe tener por lo menos una prueba para cada requerimiento que se haya documentado. Para describir defectos en el software en el que el comportamiento de éste es incorrecto. Se contemplan comportamientos indeseables en el sistema, tales como: caídas en el sistema, cálculos incorrectos, entre otros.
Incluye: Objetivo del Plan Objetivo de las Pruebas Marco del Plan de Pruebas Alcance del Plan de Pruebas Descripción del módulo para pruebas Definición y Desarrollo de pruebas Resultados de las Pruebas Casos de Prueba: Se le llama así al diseño de entradas y salidas esperadas para probar el sistema. El objetivo de su diseño es crear un conjunto de casos de prueba que sean efectivos para descubrir defectos en los programas y muestren que el sistema cumple con los requerimientos
Incluye… Programación de la aplicación de las pruebas Cronograma en Project Seguimiento y reporte por defectos: Se debe contar con un formato en donde se vayan anotando los defectos encontrados en cada uno de los módulos del sistema y de forma global, también se reportarán las correcciones realizadas así como el responsable de hacerlo con la finalidad de dar un correcto seguimiento a los resultados de las pruebas
CONTROL DEL PROYECTO
Introducción El control implica comparar la ejecución con la planeación Si se encuentran desviaciones, se debe prever la acción correctiva necesaria para ejecutarla Si no se encuentran desviaciones, se continúa con las siguientes actividades que se tenían previstas
Durante el control: Se debe ir a la par que la ejecuciónReportar avancesIdentificar las desviaciones al Plan Documentar previamente los cambios de acuerdo al Plan, proponiendo estrategias para corregir Registrar las lecciones aprendidas
Herramientas y su uso durante el Control: AHerramienta¿Cómo servirá durante el Control? AlcanceWBSPara identificar el trabajo ejecutado y compararlo contra lo planeado Al momento de ejecutar, se seguirá esta estructura para confirmar el alcance realizado. Rec. HumanosMatriz de Roles y Funciones Para monitorear el desempeño de los participantes en el proyecto y ajustar sus roles y funciones, según sea requerido. ComunicaciónMatriz de Comunicación Para distribuir la información del proyecto en pro de una comunicación efectiva. TiempoPrograma del Proyecto Monitorear el apego al programa del proyecto e identificar desviaciones y corregirlas. RiesgosMatriz de Admón. de Riesgos Confirmar el seguimiento a la matriz y tomar la acción requerida.
CIERRE DEL PROYECTO
Introducción Una vez que el proyecto ha llegado a su término, se debe continuar con el cierre Esta fase se considera importante entregar una serie de documentos con la finalidad de realizar una entrega ordenada y formal de toda la información generada durante el desarrollo del proyecto, así como dar por concluido los acuerdos legales (si existieron) y las evaluaciones de desempeño. De acuerdo con esto existen dos tipos de cierre: el contractual y el administrativo
Cierre del proyecto Dentro del cierre administrativo se deben incluir una serie de documentos (CHAMOUN, 2002) tales como: Reporte Final: Permite de una manera rápida tener un panorama de la información más importante del proyecto, algunos documentos que incluye son: Presupuesto Final Programa Final Directorio de participantes Cartas de cierre para los patrocinadores y gerentes del proyecto Reporte de control de cambios, entre otros.
Cierre… Programa de desfase del equipo: Este documento permitirá no generar estrés entre los participantes durante las fases finales del proyecto debido a la incertidumbre de la permanencia en el trabajo, o por involucrarse en otro tipo de situaciones externas al proyecto. Aspectos como la salida del equipo, evaluaciones sobre su desempeño, entregas finales antes del despido, son algunos ejemplos de lo que se puede incluir. Archivos del proyecto: Se pueden entregar de forma impresa y ordenada en carpetas así como de manera electrónica. Algunos documentos a incluir son el plan del proyecto, bases de datos actualizadas (si se cuenta con ellas), lecciones aprendidas, contratos, entre otros.
Conclusión
Fuentes consultadas Rodríguez, A. I. (Mayo de 2009). Facultad de Informática Universidad Politécnica de Madrid. Obtenido de &V_pruebas%20unitarias.pdf