Formal Testing: Un enfoque de pruebas de largo alcance

Me da mucho gusto volver a escribir para ustedes por este medio, estimados lectores, luego de un receso de aproximadamente dos años.

Les escribo esta vez porque considero importante platicarles de algo que ahora veo con bastante claridad que puede ser muy relevante en la industria mundial de la prueba de software durante los siguientes años.

Como quizás recuerden, comencé a escribir en Software Gurú en 2006 a través de la columna “La Prueba de Software”. Para ese año ya tenía ciertos conocimientos y experiencia en esa disciplina: había hecho un posgrado en Alemania, realizado investigación aplicada en el ITESO, asistido a varios congresos en Europa y EEUU, y co-fundado e-Quallity. Durante 5 años estuve escribiendo sobre la prueba de software como se hacía en el mundo, que era, en esencia, como se llevaba a cabo desde hacía varios lustros.

Después de un receso de 4 años, de 2015 a 2018 estuve escribiendo la columna “La prueba de software y los special purpose lenguajes” con el objetivo de mostrar cómo estos lenguajes pueden incrementar la productividad en la industria del software en general y en la de la prueba en particular, porque veía que sobre esta idea estaban gestándose planteamientos que podrían sentar las bases para nuevos enfoques en la Prueba de Software. 

Desafortunadamente surgió la discontinuidad en la revista lo cual, aunado a otras cosas, me complicó continuar escribiendo. Con este artículo pretendo reducir esa brecha.

Así como lo escribimos en SG #4, hoy seguimos viendo que la Prueba de Software involucra…

un proceso en el que se revisa el sistema a probar (el SUT, System Under Testing) bajo condiciones definidas explícitamente, aplicándole (eventualmente con apoyo de software especializado) un conjunto de estímulos (casos de prueba) obtenidos de manera sistemática utilizando técnicas apropiadas, con el objetivo de detectar niveles inadecuados de calidad.

Este proceso debe llevarse a cabo disciplinadamente, y respaldarse en métricas bien definidas. Todas estas actividades y sus resultados deben ser documentados sistemáticamente, en especial las fallas detectadas.

Ahora bien: los SUT que probamos son objetos formales, en el sentido de que fueron desarrollados utilizando algún lenguaje de programación (un tipo especial de Lenguaje Formal) y son por tanto sujetos a compilación; pero hoy en día ese proceso de compilación que se realiza sobre código escrito en un Lenguaje de Programación se extiende a otros Lenguajes de Computadora como los de Especificación, de Arquitectura y de Documentación, posibilitando una automatización y un reuso mayores, más inteligentes y de mayor alcance.

En SG #30 hablamos de los Métodos Formales. Vimos que en ellos se utilizan varios Computer Languages para “desarrollar software libre de defectos por construcción” y enfatizamos su relevancia para el futuro de mediano y largo plazo debido a su gran impacto potencial. Es una disciplina en la que se ha trabajado desde hace más de 60 años y ha generado conceptos, técnicas y procesos que han sido de mucha utilidad en distintas áreas de la industria del software.

Pues bien, hoy el futuro nos está alcanzando y tenemos “Formal Testing”, un enfoque integrador que describiremos a continuación, de muy largo alcance, que incorpora elementos provenientes de la disciplina de los Métodos Formales.

Marco conceptual del Formal Testing

El Formal Testing (Pruebas Formales) es un enfoque en el cual, para la realización de actividades de pruebas, se usan de manera extensiva, intensiva e integrada Computer Languages, una clase especial de Lenguajes Formales que tienen la particularidad de poder ser procesados por Intérpretes o Compiladores de manera eficiente.

Vamos a describir este enfoque yendo del centro hacia afuera en la figura que se muestra a continuación, en la cual…

• el círculo y los dos hexágonos centrales concéntricos contienen las disciplinas fundamentales del Formal Testing;
• los hexágonos inferiores alrededor de los hexágonos centrales contienen prácticas que se aplican comúnmente en Formal Testing;
• los triángulos que parten de los hexágonos inferiores contienen productos obtenidos de aplicar las prácticas;
• los hexágonos y los triángulos superiores contienen elementos que se describirán más adelante;
• “Ls” significa “languages”.

Descripción de Formal Testing

Como se muestra en la figura, en Formal Testing se parte de la base de los Computer Languages, y sobre ella se erigen tres grandes prácticas genéricas relacionadas con actividades fundamentales de pruebas, a partir de las cuales se genera testware. Estas prácticas genéricas son:

1. La definición de Procesos utilizando Lenguajes de Definición de Procesos, Lenguajes Naturales Restringidos, y Lenguajes de Documentación. Esto posibilita, entre otras cosas:
   1. La adecuación automática de sistemas como los de Work-Flow, que implementen el proceso especificado en el PDL para que los testers lo apliquen utilizando componentes parametrizados de esos sistemas.
   2. La generación automática de documentación sobre el proceso (v.gr. representaciones gráficas parciales) o de perfiles de testers involucrados en ese proceso (v.gr. en lenguaje natural restringido).
   3. La optimización de recursos (tiempo, en particular) en proyectos que se ejecutan siguiendo el proceso, utilizando métricas de productividad y restricciones de cada proyecto (como tiempo y dinero).
2. El desarrollo de muchos de los casos de prueba de Caja Negra utilizando Lenguajes de Especificación, con los cuales se desarrollan modelos del producto a probar para que a partir de ellos se generen casos de prueba (sub-enfoque conocido como Formal Model Based Testing). Esto abre la posibilidad de automatizar, entre otras cosas:
   1. La generación de casos de prueba, en particular de Performance, de Unidad, de Integración y de Sistema, tanto manuales (en algún lenguaje natural restringido) como automatizadas (en algún Scripting Language).
   2. La minimización del conjunto de casos de prueba generados, la secuenciación de los mismos, y su eventual concretización (si se generaron casos de prueba abstractos, i.e. en el Lenguaje de Especificación).
   3. La estimación del esfuerzo de pruebas requerido para un proyecto en cuestión, considerando métricas de los perfiles de los testers involucrados y los casos de prueba generados.
3. La realización de muchas de las pruebas de Caja Blanca utilizando componentes de Compiladores (como analizadores léxicos, sintácticos y semánticos) para hacer Análisis del Código del programa (escrito en algún Lenguaje de Programación), de la arquitectura (escrita en algún Lenguaje de Arquitectura), o de la especificación del producto a probar (escrita en algún Lenguaje de Especificación). Esto hace posible:
   1. Encontrar inconsistencias, errores u omisiones en el código (algo que se va dificultando a los humanos a medida que el código se vuelve más extenso y complejo).
   2. Generar métricas para guiar actividades de pruebas (como las de complejidad), que permitan por ejemplo probar proporcionalmente más aquellos componentes que son más complejos.
   3. Detectar y mostrar las posibilidades de propagación de problemas entre distintos niveles de abstracción (algo aún más difícil para los humanos que lo mencionado en el inciso a).

Adicionalmente a estas prácticas genéricas, cada organización puede desarrollar y aplicar prácticas específicas para cubrir sus necesidades con Computer Languages particulares (eventualmente propietarios). Precisamente para estas prácticas específicas dejamos en la figura los hexágonos superiores punteados y sus correspondientes triángulos.

Impacto del Formal Testing

En alguna columna mencionamos que con un Computer Language podemos encapsular conocimiento de una disciplina. Con Formal Testing los testers tienen a su alcance de manera integrada conocimiento de varias actividades centrales de prueba de software, encapsulado en forma de varios Computer Languages.  

Esto habilita por un lado una automatización de orden superior, pues se cuenta con información altamente estructurada (cadenas que son elementos de Lenguajes Libres de Contexto), y por otro una mayor automatización de más actividades en áreas de proceso de Modelos de Calidad Especializados en Pruebas. Todo ello facilita un incremento significativo de la productividad, pues  –entre otras cosas–  muchos casos de prueba de caja negra se pueden desarrollar más rápidamente, de manera más ordenada, y con mayor visibilidad y flexibilidad sobre ellos (v.gr. es posible seleccionar solo un subconjunto de ellos), y muchas pruebas de caja blanca se pueden llevar a cabo automáticamente, con resultados que pueden utilizarse para distribuir eficientemente el esfuerzo de pruebas.

Los beneficios de las prácticas del Formal Testing son acumulativos y pueden agregar valor a lo largo de todo el proceso de pruebas.

Bibliografía

Para profundizar en los temas centrales aquí mencionados pueden consultar las columnas referidas en el texto. Si desean profundizar más, he aquí una lista adicional de referencias:

1. Wing, J.: A Specifier’s Introduction to Formal Methods. IEEE Computer, páginas 8-24; Septiembre de 1990
2. Hopcroft, J., Motwani, R., Ullman, J.: Introduction to Automata Theory, Languages and Computation. Pearson Education Limited; 2014.  
3. Aho, A., Lam, M., Sethi, R., Ullman, J.: Compilers: Principles, Techniques and Tools (Second Edition). Pearson Education Limited; 2014.
4. Piccineli, G.: A Process decomposition technique for distributed WorkFlow Management. Springer Science + Media; 1999.
5. Utting, M, Pretschner, A., Legeard, B.: A taxonomy of model-based testing approaches. John Wiley & Sons, Ltd; 2011. DOI: 10.1002/stvr.
6. Kuhn, T.: A Survey and Classification of Controlled Natural Languages. Association for Computational Linguistics, Volumen 40, Número 1, 2014