Unified Functional Testing (UFT) y Selenium

En mi primer artículo os hablaré de Unified Functional Testing (UFT) y Selenium, dos herramientas de automatización. En primer lugar, para el que no conozca nada sobre ellas, haré una breve introducción de ambas, seguido de una comparativa y una conclusión personal.

¿Qué es el UFT?

Es una herramienta de HP, ahora Micro Focus, cuya principal propósito es la creación de test automáticos para asegurar la calidad mediante pruebas funcionales y de regresión.

¿Qué es Selenium?

Es un conjunto de API’s de código abierto que son utilizadas para levantar instancias de un navegador, controlarlo y manipularlo realizando acciones sobre el mismo.

Integrado con otras herramientas, es utilizado para realizar pruebas funcionales y de regresión. Las versiones de las herramientas sobre las que me voy a basar son el UFT 14 y Selenium 3.

CARACTERÍSTICAS Y DIFERENCIAS
UFT	SELENIUM
Es un software comercial y tiene una licencia anual.	Es una herramienta gratuita sin licencia.
El lenguaje de programación que utiliza se limita a Visual Basic Script.	Utiliza múltiples lenguajes: Java, Python, Ruby, C#, JavaScript…
Se puede automatizar casi cualquier tipo de aplicación ya que dispone de una gran cantidad de add-ins (complementos) para capturar objetos en aplicaciones de Windows, java, web, .NET, SAP, VB, Oracle…	Tan solo es posible la automatización de aplicaciones Web.
Para capturar los objetos dispone de un agente que localiza el objeto y lo guarda en un repositorio directamente con unas propiedades que coge por defecto que se pueden editar más tarde, dándole múltiples atributos y favoreciendo el control de reconocimiento. El mantenimiento es muy sencillo.	Para localizar los objetos debes utilizar el explorador del DOM (en los navegadores aparece al f12) o un plugin como firebug (solo en Firefox), buscando una característica única del objeto (id, name, xpath, etc) para posteriormente incluirlo en tu test. (Si quieres crear un repositorio lo debes hacer a mano). El mantenimiento es mucho más costoso.
Los test solo pueden ser desarrollados en la propia herramienta.	Puedes desarrollar tus test en herramientas como Eclipse, NetBeans, VisualStudio…
Solo se puede utilizar en Windows.	Admite cualquier sistema operativo, Windows, Linux, Solaris, OS X…
No suele tener problemas de compatibilidad ni mantenimiento con las nuevas versiones de la herramienta.	Cuando se lanza una nueva versión, los test necesitan ser actualizados.
No necesita de ningún framework para el correcto funcionamiento de los test pero puede ser integrado perfectamente con ALM.	Se necesita Eclipse, Selenium y Maven para empezar (por ejemplo) además de necesitar herramientas como JUnit, TestNG… para llevar un control de la ejecución, además de plugins integrados SVN, Git…
Se puede incluir además un reconocimiento de imágenes para objetos que no tengan propiedades adecuadas para su distinción.	No dispone de reconocimiento de imágenes para objetos
Móviles. Para crear mobile tests es necesario tener una licencia distinta del producto UFT.	Hay una API, selendroid que permite desarrollar tests de igual manera que con webdriver en móviles Android.
Reportes. UFT dispone de una herramienta Run Results Viewer en el que se puede cargar el XML de la última ejecución y te da una visión amplia y clara del resultado.	Con herramientas como JUnit y TestNG se puede crear un buen reporte. Es bastante más costoso llevar el control de la ejecución
El tiempo de creación de un script es menor.	Se invierte bastante más tiempo en la creación de un script.
Consume muchos recursos y es aconsejable disponer de un equipo con una CPU y RAM potente.	No consume muchos recursos y puede ejecutarse en cualquier equipo.
Soporte. Dispone de profesionales que te resolverán cualquier duda que te surja lo más pronto posible.	No dispone de un equipo de soporte oficial, pero hay una comunidad extensa que te pueden ayudar a solventar el problema.

Antes de nada, me gustaría resaltar que el tiempo de desarrollo de un script automático es difícilmente medible ya que influyen muchos factores dependiendo de qué tipo de aplicación se quiera probar y la complejidad del test a desarrollar.

Una vez realizada esta comparación, paso a hablar de mi experiencia con ambas herramientas.

SELENIUM

He estado en varios proyectos en los que se trabajaba con Selenium. Uno de los proyectos tenía el framework montado y me tuve que adaptar para el desarrollo y mantenimiento.

En este caso, el framework estaba bastante desactualizado y propuse la opción de incluirle mejoras, la cual fue rechazada debido al concepto de infalibilidad que se tenía sobre éste.

Parece que invirtieron mucho tiempo en su creación y, erróneamente, pensaban ¿si funciona, por qué cambiarlo?

Primero porque afectaba al rendimiento y provocaba bastantes fallos en la ejecución, ya que las nuevas versiones desfasaban el código y generaban problemas de compatibilidad. Finalmente se optó por ir parcheando de una manera inadecuada y quedando hecho una “chapuza”.

Otro proyecto en el que estuve, junto con dos compañeros, montamos un framework bastante estable.

Las posibilidades que ofrece Java junto con Selenium son muy amplias con la limitación de uso a Web. Los proyectos eran creados en Eclipse en lenguaje Java que incluían la integración de Selenium+Testlink+JUnit+Maven+SVN+Jenkins+Otras herramientas.

Los proyectos estaban asociados a un número de tests en Testlink que al lanzarse en Jenkins, los ponía automáticamente al estado correspondiente a la ejecución además de generarse un reporte bastante explícito que incluía capturas de imágenes en una carpeta específica asociada, intentando hacer lo más fácil posible la identificación de algún posible defecto sin necesidad de realizar un análisis minucioso.

En conclusión: esta herramienta es potente y ofrece muchas posibilidades pero está bastante limitada. Su mantenimiento e integración de las herramientas que comprende para un correcto funcionamiento es complejo y costoso, así como el desarrollo de los test.

UFT

Actualmente, estoy en un proyecto donde utilizamos esta herramienta para las pruebas automáticas. Tenemos unas 2.500 ejecuciones semanales, asociadas con 18 proyectos.

Tenemos integrado el UFT con Control-M (una herramienta parecida a Jenkins). Se lanzan a diario pruebas de regresión de 8 aplicaciones. El resto, unas son a petición y otras tienen un día y hora fijado.

Cuando llegué al proyecto la adaptación fue rápida ya que es sencilla la integración de UFT. En este caso disponemos de la herramienta y subversion. De momento no está integrado con ALM. No necesita de un framework complejo para realizar pruebas.

El tiempo de desarrollo de scripts también es mucho menor, ya que mediante el agente se puede realizar el flujo siendo capaz de capturar todos los objetos de una vez.

En conclusión: aunque sea una herramienta que necesite un desembolso inicial, se compensa con el tiempo que ahorras montando el entorno y desarrollando los scripts.

Además de no tener límites a la hora de automatizar. Puedes automatizar cualquier tipo de aplicación. Las limitaciones que puede ofrecer son en cuanto a rendimiento debido a que consume bastantes recursos. Además el lenguaje de VBS no es comparable con otros como Java, Python…y ofrece también limitaciones.

Espero que os haya gustado el Post y está abierto a debate ya que es una opinión personal y basada en la experiencia con estas herramientas. Cualquier comentario y valoración es agradecida.  Gracias por vuestro tiempo.

Daniel Lavara Rojas

Test Engineer | Digital Assurance & Testing | Sogeti Spain