fbpx El Proceso de la Prueba de Software: Lenguajes de Definición de Procesos | SG Buzz

El Proceso de la Prueba de Software: Lenguajes de Definición de Procesos

Publicado en

En este número y el siguiente abordaremos el proceso de la prueba de software. Iniciaremos con el tratamiento formal del concepto, para luego pasar a su aplicación, vinculándolo con la administración de proyectos.

Una Definición Formal

Es común encontrarse en la literatura que aborda el proceso de prueba una referencia al “Modelo-V”. 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; La siguiente gráfica ilustra una adaptación de este modelo, que incluye algunas actividades de cada fase.

Este modelo tiene la ventaja de ser bastante intuitivo: 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.

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.

Una desventaja del modelo es que requiere aún de mucho detalle para ser útil en la práctica. Además, la documentación de procesos es una actividad en sí misma, y 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).

Utilizando el conocimiento que hoy se tiene en el diseño e implementación de lenguajes de computación, se han desarrollado lenguajes que buscan abatir esos problemas; en la literatura se les conoce como Process Definition Languages (PDLs), y en ellos se basan los Business Process Management Systems (BPMSs), a los que se dedicó el número de julio-agosto 2005 de esta revista. Uno de los primeros trabajos en el campo de los PDLs es el de Osterweil[1]. De manera semejante a lo que ocurre con los BPMSs, el utilizar un PDL para definir un proceso de prueba posibilita la generación de un sistema de información que nos permite integrar herramientas CAST y administrar proyectos de prueba de software.

En la empresa e-Quallity hemos desarrollado un PDL para definir nuestros procesos y hemos observado que facilita mucho las actividades de diseño, documentación, análisis, mejora y mantenimiento de los mismos, debido a que la documentación adquiere muchos de los atributos de un lenguaje de computación, entre otros: es posible escribir descripciones más precisas y sucintas, con menos probabilidad de contener ambigüedades; las descripciones pueden modularizarse con facilidad, posibilitando el reuso y el mantenimiento efectivo.

Aquí presentaré un PDL mucho muy sencillo, en el que se omiten algunas cosas por cuestiones de espacio, pero tratando de incluir las ideas esenciales. Por la misma razón de espacio, no utilizaré grafos de sintaxis, sino que haré la definición utilizando BNF, con los terminales en negritas [2] y “λ” denotando la cadena nula; los no-terminales marcados con itálicas entre signos de mayor que y menor que (<Así>), no son definidos con mayor detalle; además no especificaré -entre otras cosas- lo que tiene que ver con el sistema de tipos (básicos, constructores, constantes y variables) ni los mecanismos de paso de parámetros. El PDL es más bien procedural y permite definir procesos dentro de otros procesos (tipo Pascal), posibilitando la generación de una jerarquía de procesos; los niveles permitirían diferenciar entre procesos y procedimientos.

Listado 1

 

En el siguiente número utilizaremos este PDL para documentar formalmente una sección de un proceso de prueba, y lo vincularemos con las fases de la administración de proyectos propuestas por el Project Management Institute.

Referencia
1. Osterweil, L. “Software Processes are Software too”. Proceedings of the ninth International Conference on Software Engineering. Marzo,1987
2. Aho, Ullman & Sethi. Compiladores: Principios, Técnicas y Herramientas. Addison Wesley, 2000
3. BNF and EBNF: What are they and how do they work? www.garshol.priv.no/download/text/bnf.html