SikuliX frente a otras herramientas de pruebas automáticas de GUI

Existen en el mercado muchas herramientas de pruebas automáticas de GUI. En la Wikipedia se puede ver una lista extensa. Cada una con sus pros y contras. Algunas con notable éxito como Selenium,AutoIT o SilkTest y otras casi desconocidas. Todas ellas son rivales de SikuliX ya que su objetivo es el mismo : probar el software tomando como punto de partida la interfaz gráfica de usuario.

Pero hay una diferencia sustancial que condiciona tanto las ventajas como los inconvenientes que mencionaremos más abajo : SikuliX busca los componentes visuales mediante reconocimiento de patrones mientras que la mayoría del resto de competidores suelen utilizar o bien una búsqueda por nombre del componente visual o bien por posición en pantalla.

A continuación desgloso las ventajas y desventajas que, a mi entender, tiene SikuliX frente a otras herramientas.

Ventajas de SikuliX

1– Se distribuye como código abierto.

2 - Es gratuito.

3 - El entorno de ejecución de pruebas (testing environment) es multiplataforma. Es decir, el sistema que ejecuta los scripts de SikuliX puede ser Windows, Linux o Mac.La mayoría de herramientas se ciñen a una plataforma concreta.

4– El entorno probado (tested environment) es ilimitado ya que puede verificar cualquier tipo de software. Es decir, no está focalizado en páginas webs o en apps de móvil o en aplicaciones de escritorio. Solo hay una condición : el entorno probado se ha de visualizar de alguna forma en el  entorno de ejecución. P.e. mediante VNC o ejecutando un emulador.La mayoría de herramientas se ciñen a un tipo de aplicación concreto (p.e. páginas webs o aplicaciones móviles).

5 - No exige conocimientos técnicos avanzados para desarrollar los scripts. Es suficiente con nociones básicas de Python (en el caso que se desarrollen los scripts desde el IDE de SikuliX) o  de Java (en el caso que se creen con un IDE externo como, por ejemplo, Eclipse). También se puede programar en otros lenguajes como Ruby o Javascript. Más información en la web de SikuliX.

Desventajas de SikuliX

  1 – Es posible que un script de SikuliX deje de funcionar si se modifica la resolución de pantalla o el tema (tapiz) del entorno probado.
Esto se debe a lo que he mencionado antes : como SikuliX busca los componentes visuales a partir de reconocimiento de patrones, un cambio estético puede provocar que no encuentre el componente. Evidentemente, tiene un grado de toleracia configurable a la hora de reconocer los patrones pero en algunos casos ni tan siquiera reduciendo esta toleracia se puede solucionar.

Obviamente, una alternativa consiste en crear una versión del script para cada resolución pero puede llegar a ser muy costoso en función de los cambios que se requieran y de las resoluciones a adaptar. Otras herramientas de automatización suelen buscar los componentes visuales a partir del nombre o de su posición en pantalla. Esto les abstrae de los cambios estéticos pero les vincula a un nombre concreto o a una posición.
El motivo es el mismo que el mencionado en el punto anterior : el renderizado de componentes  puede ser (ligeramente) diferente en función del navegador. Estas (ligeras) diferencias pueden provocar que SikuliX no encuentre algunos componentes en pantalla.
El motivo también es el mismo que el mencionado en el punto 1.

2 - En el caso de aplicaciones web, es posible que algunos scripts dejen de funcionar si se modifica el navegador web que se usa durante las pruebas.

3 - Es posible que un script deje de funcionar si se cambia el tipo de fuente de un determinado texto.

4 - El equipo encargado actualmente del desarrollo del producto es pequeño.

5 - No hay una empresa importante detrás que dé soporte o una cierta garantía de continuidad.

6 – Tiene como prerrequisito la instalación del JRE en el entorno de ejecución. Es una desventaja pequeña pero no deja de ser un requisito del producto.

Está claro que las desventajas son considerables y hay que tenerlas en cuenta. En función de los requisitos que se deseen establecer en el entorno de ejecución de las pruebas, esas desventajas pueden suponer una limitación o no.

En el siguiente artículo hablaré sobre los posibles usos de las pruebas automáticas de GUI. En general, sin focalizarlo en SikuliX.

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.

Empecemos...

Con el presente artículo inicio este blog para hablar sobre la herramienta Sikuli. Para aquellos que nunca hayan escuchado hablar de ella, la presentaré : es una herramienta de pruebas automáticas de interfaz gráfica de usuario (GUI, como acrónimo en inglés).

Pero, ¿por qué dedicarle un blog? Porque creo que esta herramienta tiene un gran potencial así que considero que merece la atención de los profesionales que desarrollan y prueban software. Y qué mejor manera de apoyar su difusión que hablar sobre ella, bien sea aclarando dudas o aportando contenido sobre sus funcionalidades. 

Inicialmente fue desarrollada por el Usable Programming Group del MIT y actualmente lo lidera Raimund Hocke junto con una comunidad de desarrolladores. Cuando Raimund tomó el proyecto, lo renombró como SikuliX así que a partir de ahora utilizaré el nuevo término para referirme a él.

Su licencia de uso es la del MIT, cuyos detalles se pueden consultar en esta web. Para resumirlos en pocas palabras, se permite cualquier tipo de uso tanto del software como del código generado pero se ha de añadir una nota de licencia.

Las pruebas se guardan en scripts que son ejecutables tanto desde el IDE como desde línea de comandos. Se pueden utilizar diversos lenguajes de programación para su desarrollo : Python, Java,.... 

Actualmente existen dos ramas activas de desarrollo : la 1.1.x  y la 2.x . A lo largo de este blog se utilizará la primera de ellas porque la segunda aún se encuentra en una fase muy preliminar.

Tras esta introducción inicial,en el próximo artículo haré una comparativa entre las pruebas automáticas de GUI y las unitarias / integración.