Pruebas automáticas de GUI versus pruebas unitarias/integración

Haciendo un símil con una casa, podríamos decir que una prueba unitaria consiste en verificar que los ladrillos de una casa están en buenas condiciones. Una prueba de integración sería verificar que los tabiques encajan bien unos con otros, es decir, sin fisuras de por medio. Una prueba de GUI sería verificar que la persona vive de forma confortable en ella. Esto implica muchos detalles : que puede desplazarse por la casa sin impedimentos (¿qué pasa si sufre algún tipo de minusvalía física?), que hay suficientes habitaciones para toda la familia, que las habitaciones son amplias, que es luminoso, etc.

Aunque, si queremos ser más precisos, habría que añadir a la analogía expuesta que el habitante de la casa también se dedica a verificar los ladrillos y los tabiques. Por tanto, realmente, las pruebas de GUI verifican todo : desde las piezas hasta el producto en su conjunto.

En este artículo no voy a comparar las pruebas de GUI con las manuales porque es obvio que las segundas apenas ofrecen ninguna ventaja. Pero sí que es interesante compararlas con  otros tipos de pruebas automáticas como las unitarias y de integración porque la mayoría de empresas de desarrollo de software las utilizan.

Por tanto, la pregunta a plantear es : ¿merece la pena invertir recursos en añadir las pruebas de GUI en el proceso de creación de software? 

O, vayamos un poco más lejos : ¿podemos sustituir las pruebas unitarias y de integración por pruebas de GUI? Y, si podemos, ¿me resultará más rentable? Es decir, menos tiempo por recurso dedicado a mecanismos de prueba. Obviamente, sin perder calidad del software. 

Bueno, empecemos por la primera pregunta. En mi opinión, sí merece la pena añadir pruebas de GUI. Yo empezaría por los flujos más habituales y los más críticos dentro del sistema. Con el tiempo, lo iría ampliando hasta cubrir aquella porción del producto que considere pertinente. Cubrir el 100% de los flujos seguro que requerirá una inversión considerable de tiempo y esfuerzo. Por eso,tal vez, resulte más óptimo centrarse en los críticos. Una vez implementadas las pruebas de un número considerable de flujos será el momento de evaluar si en nuestro caso las pruebas de GUI nos aportan un valor añadido.

Respecto a la segunda pregunta,es difícil dar una respuesta tajante. Es obvio que cuanta mayor diversidad de pruebas se realicen,menor probabilidad existe que el error alcance el entorno de producción. Así que,está claro, la respuesta fácil es : "hagamos todos los tipos de pruebas y asunto zanjado". Ya, pero : ¿qué coste tiene eso? ¿Estoy duplicando esfuerzos en el desarrollo de las pruebas? 

Respecto a la tercera pregunta, en mi opinión,es más rentable el diseño y desarrollo de las pruebas de GUI que las unitarias o de integración. Lo argumento a continuación donde se explicitan las ventajas y desventajas entre las pruebas automáticas de GUI y las unitarias / integración.

Ventajas de las pruebas de GUI

1 – Las pruebas de GUI permiten probar flujos de usuario completos (end to end). Es decir, se simulan las interacciones del usuario con el software verificándose cómo se comporta nuestro software ante dichas acciones directas (simuladas). Las consecuencias son :

• Se está probando lo que realmente va a suceder en entorno de producción, no solo que un método devuelve lo que corresponde cuando se le pasa un determinado valor (lo que hace una prueba unitaria).
• En una única prueba se pueden validar miles de líneas de código.   

Por otra parte, en la mayoría de ocasiones cada uno de esos flujos se pueden asociar directamente con casos de uso reales, facilitando al equipo de QA el proceso de verificación de los casos de prueba (test cases).

2 – En general, el tiempo dedicado a desarrollar pruebas de GUI es mucho más productivo que el tiempo dedicado a desarrollar pruebas unitarias o de integración. En dos aspectos :

• Con el mismo tiempo invertido en su creación, una prueba automática de GUI prueba más porciones de código que una prueba unitaria o de integración.
• Las pruebas automáticas de GUI las puede desarrollar un perfil no experto en programación. Por ejemplo, un becario o un componente del equipo de QA.

3 – Una herramienta de automatización de GUI no solo puede utilizarse para verificar nuestro software sino también para automatizar cualquier tipo de tarea repetitiva dentro de los procesos de la empresa (sea de tipo administrativa, configuración de sistemas, etc.), siempre y cuando este proceso se ejecute en un sistema informático.

Desventajas de las pruebas de GUI

1 – Los cambios de resolución de pantalla o estéticos (temas) podrían afectar al correcto funcionamiento de los scripts, obligando a corregirlos. En aquellas aplicaciones donde estos cambios sean frecuentes y de alcance global en la aplicación, es poco recomendable utilizar pruebas automáticas de GUI.
Nota: Esta desventaja no afecta a todos los tipos de herramientas de prueba de GUI sino solo a aquellas que utilicen reconocimiento de patrones visuales, como hace SikuliX.

2 - Las pruebas automáticas de GUI habitualmente solo se podrán ejecutar para verificar  una aplicación en concreto. Es poco habitual que varias aplicaciones compartan flujos comunes a nivel visual. Sin embargo, las pruebas unitarias tienen un uso más amplio ya que pueden verificar todo el código compartido entre multitud de aplicaciones muy diversas entre sí.

3 – Las pruebas automáticas de GUI se ejecutan más despacio que los tests unitarios o de integración, requiriendo usualmente horas. Esto es una gran desventaja ya que en caso de error este tarda más tiempo en detectarlo y, por consiguiente,se tarda más tiempo en solucionarlo. Esto supone un impedimento considerable principalmente en equipos de desarrollo que utilicen metodologías ágiles. Sin embargo, en equipos que utilicen metodologías clásicas (p.e. cascada)  las consecuencias son menos importantes.

En el próximo artículo haré una comparativa entre SikuliX y otras herramientas de pruebas automáticas de GUI.