Administración de Procesos de Pruebas Cuevas Hernández Felipe Neri

Las pruebas son una parte esencial del proceso de desarrollo, ya que verifican y validan que un programa, un subsistema o una aplicación realizan las aplicaciones para las cuales fue diseñada. Las pruebas también determinan si las unidades que están siendo probadas operan sin problemas de funcionamientos ni efectos adversos sobre otros componentes del sistema.

Las pruebas constituyen un método más para poder verificar y validar el software. Se puede definir la verificación como [IEEE, 1990] el proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Por ejemplo, verificar el código de un módulo significa comprobar si cumple lo marcado en la especificación de diseño donde se describe. Por otra parte, la validación es el proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. Así, validar una aplicación implica comprobar si satisface los requisitos marcados por el usuario.

Podemos recurrir a la clásica explicación informal de Boehm de estos conceptos: Verificación: ¿estamos construyendo correctamente el producto? Validación: ¿estamos construyendo el producto correcto?

El proceso de prueba El proceso de prueba comienza con la generación de un plan de pruebas en base a la documentación sobre el proyecto y la documentación sobre el software a probar. A partir de dicho plan, se entra en detalle diseñando pruebas específicas basándose en la documentación del software a probar. Una vez detalladas las pruebas (especificaciones de casos y de procedimientos), se toma la configuración del software (revisada, para confirmar que se trata de la versión apropiada del programa) que se va a probar para ejecutar sobre ella los casos.

La depuración puede corregir o no los defectos. A partir de los resultados de salida, se pasa a su evaluación mediante comparación con la salida esperada. A partir de ésta, se pueden realizar dos actividades: La depuración (localización y corrección de defectos). El análisis de la estadística de errores. La depuración puede corregir o no los defectos. El análisis de errores, para realizar predicciones de la fiabilidad del software y para detectar las causas más habituales de error y mejorar los procesos de desarrollo.

PRUEBAS DE SOFTWARE realizando una serie de pruebas para minimizar la presencia de defectos y validar que dichos productos cumplan con la funcionalidad esperada. Buscamos que los productos sean confiables,  eficientes, usables y funcionales.

Pruebas de Aceptación Pruebas formales realizadas con el fin de que el usuario o el cliente pueda dar por bueno el sistema. Pruebas de Integración de Sistema Pruebas realizadas con el fin de encontrar fallos en las interfaces entre nuestro sistema y otros con los que interacciona. Pruebas de Sistema El objetivo es probar el sistema de forma completa verificando que los procesos de negocio se pueden realizar correctamente

Pruebas de Integración de Componentes Se verifica que la integración entre diferentes componentes se realiza de acuerdo con las especificaciones. Pruebas de Componente o Unitarias Se realizan pruebas de forma individual sobre componentes del software para los cual se dispone de documentación con su especificación independiente.

El Modelo en V Requisitos de usuario Pruebas de aceptación Especificación de requisitos Diseño modular Especificación lógica del módulo Pruebas de sistema Pruebas de integración Pruebas de unidad Pruebas de aceptación Código

la prueba comienza haciendo revisiones técnicas a los requerimientos y bosquejando los primeros casos de prueba de aceptación, pasando luego a revisar que la arquitectura satisfaga los requerimientos y a definir los primeros casos de prueba de sistema; después se revisa la modularidad del diseño y se bosquejan casos de prueba de integración, para luego pasar a revisar los algoritmos y a desarrollar los casos de prueba de unidad. Mediante este modelo se describe a un nivel muy alto de abstracción las fases del ciclo de desarrollo en las que (idealmente) se involucra la prueba.

Las actividades de prueba de la línea izquierda de la “V” se llevan a cabo en paralelo al desarrollo de software e involucran también la revisión de apego a estándares; las de la línea derecha involucran la terminación del diseño de los casos de prueba y la aplicación de los mismos.

Desventaja Requiere de mucho detalle para ser útil en la práctica. La documentación de procesos es una actividad en sí misma. Los documentos generados suelen ser muy propensos a quedar rápidamente inconsistentes (a causa de los cambios) y/o sin actualizar (por la dificultad para realizar esos cambios).