fbpx

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; he aquí una adaptación, 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).

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 el LNPS utilizamos 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; y las descripciones pueden modularizarse con rapidez, facilitando el reuso y el mantenimiento efectivo.

Este PDL ve un proceso como una secuencia de pasos, cada uno de los cuales es una actividad (paso que ya no necesita ser refinado), un subproceso (paso que debe ser refinado), un bloque de pasos, una alternación de pasos (como un “switch” en un lenguaje de programación), una repetición de pasos (como un “while” en un lenguaje de programación), o pasos que se ejecutan en paralelo.

En un primer nivel de detalle, la definición de nuestro proceso de pruebas utilizando el PDL en su versión gráfica es la mostrada a continuación, en la cual se observan 8 pasos, cada uno de los cuales es un subproceso (que tiene a su vez su propia definición), y las medias lunas grises de apertura y de cierre enmarcan pasos que pueden llevarse a cabo simultáneamente, de manera que en realidad tenemos una secuencia que incluye los pasos 1 al 4, seguidos por el paso consistente en ejecutar los pasos 5, 6 y 7 en paralelo, seguido del paso 8.

                                                                 

Síguenos en :

Facebook
Facebook
YouTube
LinkedIn