Este artículo expondrá los subprocesos de la disciplina de pruebas que más carga de trabajo les ocasiona a sus ejecutores, y mostrará cómo la técnica propuesta otorga velocidad a la ejecución de dichas actividades, logrando una notable disminución en el tiempo total del proceso. Basada en el concepto: “marco de ejecución de pruebas automatizadas”. Esta técnica logra que los proyectos que la implementan, obtengan la calidad deseada en el tiempo estimado.
Las dos áreas de mayor oportunidad
¿Cuántas veces les ha ocurrido que sus diseñadores de prueba no terminan de diseñar y/o detallar sus casos, cuando éstos ya deben empezar a ejecutarse? ¿Cuántas veces llevan el 40 ó 50% de la ejecución de las pruebas y están a unas horas del compromiso de liberar un sistema a producción?

Estos escenarios ejemplifican los dos subprocesos de pruebas, que más tiempo, implican en un proyecto de desarrollo de software: el diseño de los casos de prueba y la ejecución de éstos. Es por ello que cualquier solución que intente agilizar dicho proceso, debe enfocarse primeramente en agilizar la definición y ejecución de casos de prueba.

Luego de hacer varios intentos en la búsqueda de la eficiencia en la disciplina de pruebas, he llegado a la conclusión de que no se pueden obtener pruebas con una cobertura aceptable, sin hacer uso de una herramienta para la implementación de pruebas automatizadas.
Y es que es humanamente imposible, realizar todas las pruebas requeridas para que un sistema tenga una calidad aceptable, en los tiempos que se colocan como meta, los proyectos actuales. A medida que van creciendo las funcionalidades de un sistema, con el correr del tiempo y las iteraciones de desarrollo, la cantidad de casos de prueba a ser construidos y ejecutados, aumenta exponencialmente; esto se traduce irremediablemente en tiempos de pruebas mayores y metas de proyectos incumplidas.

Por esto, considero que cualquier proyecto de software con cierta importancia, debe implementar pruebas automatizadas como soporte al proceso de pruebas, y para implementar esto recomiendo aplicar el concepto del marco de ejecución de pruebas.

El marco de ejecución
La solución que describo se implementa utilizando una herramienta de pruebas automatizadas que permita crear lo que se conoce como un “marco de ejecución de pruebas automatizadas”.

Con esto me refiero a que la herramienta debe permitir leer de una fuente de datos externa que contenga los casos de negocio que diseñaron los analistas y sumarlo a los casos de pruebas que diseñen los ingenieros de pruebas, para luego volcarlos a la aplicación.

El marco de pruebas automatizado debe ser capaz de analizar, si luego de introducir todos los datos leídos, el resultado que muestra el sistema es el esperado.

Lo interesante de la metodología se basa en que, tanto la cantidad de campos que contenga la fuente de datos externa, como la cantidad de casos de pruebas a ejecutarse, pueden variar sin que esto afecte al proceso. Es decir, el marco de pruebas será capaz de volcar a la aplicación, los casos de pruebas, teniendo como entrada una fuente de datos de entrada dinámica. La figura 1 ilustra a grandes rasgos el funcionamiento de esta técnica.

Figura 1. Marco de pruebas automatizadas

Con esto se logran dos cosas muy importantes que contribuyen a mitigar los riesgos antes mencionados.
1. Los analistas del sistema generan una parte importante de los casos de prueba.
2. La ejecución de las pruebas ya no depende esencialmente de la intervención humana, ya que se puede automatizar.
Factores críticos de éxito
El error más común es, leer un artículo de estas características y lanzarse a comprar una herramienta de automatización de pruebas, y entregárselas al equipo esperando los resultados aquí descritos. El hacerlo, no sólo lleva a la frustración personal de cada uno de los involucrados en el proyecto, sino al escepticismo por parte de la organización, hacia la automatización de pruebas. Para resolverlo, deben tenerse en cuenta una serie de puntos:

La curva de la “JOTA”. Es muy frustrante comenzar un proyecto pensando en que pasaremos de A a C sin pasar por B. Toda innovación tiene un punto en el que el equipo o persona, baja la productividad debido al tiempo de aprendizaje.

En los proyectos de automatización de pruebas, muchas organizaciones abandonan los esfuerzos de implementación cuando se encuentran en el punto B, por desconocimiento de la curva de aprendizaje. Es de suma importancia, antes de comenzar el proyecto, diseñar la curva y estipular los tiempos previstos para transitar desde A hacia C detallando expresamente el punto B.

Figura 2. La curva Jota

Contar con personal con experiencia en desarrollo. Un factor crítico en la implementación de un marco de pruebas es, tener la participación en el equipo de trabajo de recursos humanos con habilidades de desarrollo, preferentemente en el lenguaje de programación de la herramienta de automatización. El no tomar al proyecto de automatización como un proyecto de desarrollo, es uno de los errores más graves que se comete al encarar una implementación de este estilo; debido a que una mala arquitectura en el desarrollo del marco de pruebas, no permitirá el éxito del proyecto.

Pensar que con la automatización se descartarán las pruebas manuales. Muchas organizaciones piensan que luego de la finalización de este proyecto, prescindirán de los probadores manuales, y entonces no prevén contrataciones para el área de pruebas.

Existen tipos de pruebas en las cuales la automatización no es una técnica factible. (Ejemplo: ver si la barrera de una caseta se levanta al emitir el ticket). Incluso en aquellas pruebas que pueden automatizarse, es conveniente que en una etapa inicial del desarrollo, se efectúen manualmente.

Conclusión
El marco de automatización de pruebas es un concepto que en el ámbito de la investigación se maneja desde hace varios años, pero me he dado cuenta que pocas organizaciones están familiarizadas con esta técnica.

Me he preguntado el por qué de este hecho, y no he dado con una respuesta certera. Tal vez se deba a que las herramientas en la antigüedad no eran lo suficientemente flexibles como para que los programadores se sintieran cómodos, y se animaran a crear un marco como el que describo. Sin embargo, las herramientas en la actualidad son muy poderosas, incluso algunas de ellas ya permiten la introducción de código en lenguajes tan conocidos y potentes como Java y .Net.

Creo que la verdadera razón, es que no se ha dado suficiente difusión a esta técnica. Espero que escribir un artículo en un medio de distribución masiva como este, pueda ayudar a generar conciencia en las organizaciones del valor real de esta práctica.

Acerca del autor
Ariel Sucari, es gerente de consultoría en Itera, cursa el MBA ejecutivo de la universidad de las Ámericas Puebla, graduado de la Universidad CAECE en Buenos aires, Argentina. Ha participado y coordinado proyectos de la disciplina de pruebas, en Inglaterra, Estados Unidos, Venezuela, Argentina y México, durante los últimos 8 años.