En la automatización de pruebas, los pasos que se han ido dando ha sido evolucionar desde las pruebas desarrolladas con una gran cantidad de código, hasta metodologías, frameworks y herramientas que nos permiten crear pruebas funcionales a alto nivel sin necesidad de grandes cargas de código. En un contexto como el actual en el que se requiere de una gran flexibilidad dentro de los equipos de prueba, es necesario capacidad para crear pruebas de UI que sean mantenibles y escalables. Keyword Driven Testing es un enfoque que separa el diseño del caso de prueba de la ejecución.

Este post se centra en este framework y en dos estrategias para llevarlo a cabo. La primera de ellas con Selenium y la segunda con la herramienta RobotFramework.

En qué consiste KDT

También conocida como Table Driven Testing, es un framework para pruebas software válida tanto para el testing manual como para la automatización. Esta forma de diseñar casos de prueba y ejecutarlos, es un estándar internacional que está definido en la ISO/IEC/IEEE 29119 Software Testing.

KTD Se basa en el uso de un conjunto de palabras predefinidas, relacionadas con las acciones que se han de llevar a cabo para ejecutar los pasos de una determinada prueba como puede ser un click, abrir o cerrar ventanas u otras usadas habitualmente en las pruebas funcionales e2e.

La definición de estas keywords se produce de una forma independiente a las acciones asociadas, lo que provoca la separación del diseño de la prueba respecto a su ejecución. La reusabilidad de las keywords constituye otra de las potencialidades.

Para definir las palabras clave así como para escribir los pasos de una prueba a partir de un conjunto de estas palabras se emplea el lenguaje natual no técnico. Esto implica que, no solo el equipo de QA interviene en su diseño, sino que se puede convertir en un proceso cross a varios equipos como el de negocio o desarrollo. Gracias a esto, se cumple uno de los objetivos de QA en un proceso agile que es el de involucrar a varios equipos en el diseño de las pruebas como también ocurre con BDD para las pruebas de aceptación de usuario.

Qué elementos lo componen

En primer lugar, ¿qué es esto de palabra clave? Pues ni más ni menos que una palabra a la que asociamos una acción o una funcionalidad. Las pruebas basadas en este framework realizan pruebas de UI, por lo tanto podemos definir una palabra clave como “AddText” para definir una acción que implica:
1. Validar que el cuadro de texto está activo.
2. Situar el foco en cuadro de texto.
3. Incluir un texto dado como parámetro.
4. Perder el foco del cuadro de texto.

Keyword Driven Testing ha venido para facilitar la vida a todo el equipo. A negocio le permite crear casos de pruebas de una manera sencilla con palabras simples y no técnicas, a QA y desarrollo les permite crear estructuras desacopladas y más fáciles de mantener.

Para conseguir este desacoplamiento, los planes de prueba han de estar formados por los siguientes elementos.

Figura 1 - Componentes de Keyword Driven Testing

Almacén de palabras clave (Keywords): Las palabras que creamos las guardaremos en un determinado formato para que posteriormente sean accedidas por los scripts.

Almacén de datos: Contiene los datos necesarios para las pruebas y se almacenan en un determinado formato similar al seleccionado para las palabras clave.

Repositorio de objetos: Repositorio de las referencias necesarias a los objetos UI sobre los que se actuará. Pueden estar referenciadas por id, XPath, etc. En este punto es importante señalar que durante la creación del frontal de la aplicación es conveniente que los desarrolladores codifiquen acorde a los estándares e identifiquen los objetos UI de forma adecuada.

Biblioteca de funciones: Contiene la codificación de los flujos de negocio para los distintos elementos UI.

Scripts de pruebas: Son el conjunto de funciones que se llaman desde la biblioteca de funciones para ejecutar el código asociado a una palabra clave.

Cómo se diseña una prueba

El diseño de la prueba que vamos a describir a continuación es para una interfaz web cuyos elementos pueden ser identificados por id.

• En primer lugar, tenemos que analizar qué pantallas hay que probar y por qué elementos de UI están formadas.
• Debemos crear una biblioteca de objetos a partir de los elementos identificados en el paso anterior, para ello obtenemos el id, xpath, etc de los elementos utilizando herramientas como XPathFinder o SeleniumHQ IDE. Esta biblioteca la podemos almacenar en formato Excel, texto plano, …
• Seguidamente, se definen las palabras clave que realizarán acciones sobre los distintos elementos de la interfaz como por ejemplo ClickBoton, AbrirNavegador, etc... así como los parámetros necesarios para la cada una de ellas. En el caso de ClickBoton será el id del botón que tendremos en la biblioteca de objetos. En el caso de AbrirNavegador será el navegador y la url.
• Se crean los tests, test set y test plan a partir de las palabras clave que hemos definido y los almacenamos en el mismo formato donde se han guardado las palabras clave.
• A continuación, se codifica una librería de funciones que contiene los flujos que vinculan las palabras clave con las funciones a las que llaman.
• Por último se codifican las funciones que son llamadas desde la librería de funciones y que ejecutan las diferentes acciones sobre los elementos UI.

Tabla 1- Pros y Contras de KDT

Ejemplo con SeleniumHq y Excel

Generalmente para implementar este tipo de pruebas se usa una combinación del framework SeleniumHq WebDriver, para la codificación de las funciones, y de la librería de funciones y Excel, como almacén para los restantes elementos que forman la arquitectura.

El resto de herramientas que conforman el entorno de pruebas es:

Estrategia de pruebas:

El objetivo de la prueba es ejecutar un conjunto de pasos que se ha definido en el excel sobre la web www.google.es para su validación.
Aparte del libro Excel para la definición de la prueba, se usa Java+Selenium para la codificación de los scripts. Para conocer el XPATH de los distintos objetos implicados en la prueba hemos usado el addon de Chrome XpathFinder.

Las acciones que llevaremos a cabo son pruebas funcionales E2E, para ello definiremos dentro de un libro Excel una hoja para incluir los keywords, otra hoja para el plan de pruebas y una tercera para datos, aunque para este ejemplo no la usaremos. La forma de incluir estos elementos puede ser distinta a como aquí lo planteamos. El repositorio de objetos puede ser incluido en un fichero de configuración.

Para la automatización de los scripts usaremos Selenium Webdriver y Java, lanzando la prueba desde el método main ubicado en la clase Executor.

Descripción funcional de la prueba:

El plan de pruebas que vamos a codificar está formado por los siguientes casos de prueba:

• Abrimos el navegador Chrome
• En el TextBox incluimos la palabra "atSistemas" y damos a la búsqueda.
• En el listado que se muestra pinchamos sobre el link atsistemas.
• Abrimos el navegador Firefox.
• En el TextBox incluimos la palabra "atSistemas" y damos a la búsqueda.

Codificación de la prueba

(Descarga del código completo)

Creamos un libro Excel, que ubicaremos en la carpeta resources una vez que creemos el proyecto.
Dentro de este libro creamos las siguientes hojas que contendrán:

• Keywords: Contiene fundamentalmente los objetos web y las acciones de estos objetos. Las keywords se han formado con la unión de (objeto+accion).

Figura 2- Imagen de Excel con Keywords

Cada una de estas keywords valen para todos los tests y tendrán un método asociado.

• Plan de pruebas: Que contendrá todos los casos de prueba. En este caso dentro del propio plan y como parámetro incluimos el repositorio de objetos (LocatorType / Locator Value). Podremos incluir sucesivas pestañas en el Libro Excel para los diferentes planes de prueba que queramos incluir.

Figura 3- Definición del plan de pruebas

Las casillas con N indican que no se están usando en este plan de pruebas.

• Repositorio de objetos: Para este ejemplo se han definido dentro del propio Excel, en la columna LocatorValue y define la ruta necesaria para ser accedidos.
• Datos: Se podrá usar para incluir más datos en las pruebas. Por ejemplo, en una prueba de login podremos acceder a la aplicación de varios perfiles.

Una vez que disponemos de los todos los elementos definidos en el entorno de pruebas, creamos un proyecto maven con el arquetipo estándar.

Figura 4- Estructura del proyecto maven

Creamos el siguiente conjunto de clases que definen las funciones que componen la librería, la lógica para trabajar con hojas Excel y el método principal que lanza todas las pruebas:

• ActionKeywords, que contendrá lo que hemos denominado librería de funciones. Cada una de las keywords tiene una función asociada.

• ExcelUtility que contiene todas las funciones que parsean el contenido de las hojas Excel.

• Clase Execution que contiene el método main desde donde se lanza todo el plan de pruebas.

El diseño de esta arquitectura puede ser diferente, podemos tener clases de prueba con @test y lanzarlo con jUnit, creando una factoría para las diferentes keywords.

El flujo que sigue la ejecución sería el que se muestra en la siguiente imagen:

Figura 5- Flujo de ejecución de pruebas con KDT

Ejemplo con RobotFramework

¿Existe una manera más sencilla de hacer todo esto? La respuesta es, sí. Existen herramientas gratuitas y de pago que nos permiten crear pruebas con el framework Keyword Driven Testing como es el caso de Microfocus UFT, Ranorex Studio o como la que usaremos para nuestro artículo RobotFramework.

En primer lugar vamos a conocer un poco la herramienta. RobotFramework es un framework open source para la creación de pruebas de aceptación y que nos permite la creación de procesos robotizados (RPA).

El entorno estará formado por los siguientes elementos:

Estrategia de pruebas

El objetivo de la prueba es el mismo que en el caso anterior. Ejecutar un conjunto de pasos que se ha definido sobre la web www.google.es para su validación.
Una vez que tengamos el entorno RobotFramework disponible, definiremos los distintos elementos que configurar las pruebas diseñadas con KDT.

Descripción funcional de la prueba

El plan de prueba que vamos a codificar está formado por los siguientes casos de prueba:

• Abrimos el navegador Chrome.
• En el TextBox incluimos la palabra "atSistemas" y damos a la búsqueda.
• En el listado que se muestra pinchamos sobre el link atsistemas.
• Abrimos el navegador Firefox.
• En el TextBox incluimos la palabra "atSistemas" y damos a la búsqueda.

Configuración del entorno

• Instalamos Python para nuestro sistemas operativo desde la página oficial.
• Configuramos las variables de entorno para Python.

• Instalamos el sistema de gestión de paquetes Pip e instalamos RobotFramework pip install –upgrade robotframework

• Instalamos en eclipse el plugin que nos permitirá trabajar con RobotFramework

Figura 6- Plugin de Robot para eclipse

Configuración de los casos de prueba

• En primer lugar cambiamos dentro de eclipse a la vista RobotF.
• File > New > Robot Project.
• Sobre el proyecto creado, creamos una Robot Test Suite. Contendrá el conjunto de pruebas que vamos a ejecutar.
• El editor dispone de un conjunto de palabras reservadas. En primer lugar creamos las diferentes secciones, lo podemos hacer directamente en la pestaña Source (Settings, Test Cases, Variables, Keywords, etc) o usar las pestañas que nos ofrece eclipse-read.
• Dentro de la sección Settings incluiremos las librerías que vamos a usar. En este caso usaremos las siguientes:

• En la siguiente sección incluimos los steps de los test que queremos ejecutar.

• En el siguiente punto generamos las variables que usaremos como valores de entrada de nuestros tests y le asignamos valores.

• En último lugar creamos las keywords. En este caso agrupan un conjunto de steps y nos permiten reutilizar estos bloques en diferentes tests.

Una vez terminada la configuración, podemos ejecutar las casos de prueba que se han creado. En este artículo no se ha abordado toda la potencialidad que nos ofrece este framework, por lo que se aconseja profundizar en todas las funcionalidades que nos ofrece.

Para ejecutar los casos de prueba dentro de un contexto de integración continúa usando como servidor de integración continua Jenkins disponemos de un plugin que nos permite visualizar el resultado de las ejecuciones.
En primer lugar se debe establecer la configuración del job una vez instalado el  plugin que nos permitirá ver el resultado de las ejecuciones de los tets desde jenkins.

Figura 7- Ejecución de test suite Robot en Jenkins

Figura 8- Configuración de reportes de RF en Jenkins

Figura 9- Reporte de RF en Jenkins

Figura 10- - Reporte ampliado de RF en Jenkins

Conclusión

KDT permite hacer el proceso de pruebas funcionales automatizadas de una manera integradora para las distintas áreas del proyecto, lo que mejora sustancialmente la definición de las pruebas.

De cara a conseguir este objetivo, se han mostrado unas pinceladas sobre Robotframework, una herramienta que contiene una funcionalidad mucho más amplia de la que aquí se muestra y que permite al equipo de QA diseñar planes de prueba de una manera rápida y sin necesidad de disponer de grandes conocimientos de codificación de pruebas.

Si te ha gustado, ¡síguenos en Twitter para estar al día de nuevas entregas!