h1

Automatización de pruebas: una introducción

12/19/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

“f u cn rd ths, u cn gt a gd jb n sftwr tstng.”

El año se está terminando, y en México el puente Guadalupe-Reyes prácticamente significa el cierre de este 2014. Sin embargo, en vez de decir “estamos hechos; nos vemos en 2015”, todavía salen detalles aquí y allá en el trabajo que nos impiden relajarnos completamente: somos víctimas de una importante rotación de personal así como fechas de liberación, seguidas de un freeze. Aunque algunos recursos dejen la empresa, ciertos entregables deben estar terminados durante el transcurso de las próximas dos semanas.

Nuestro Coco es el proceso de pruebas, que para algunos proyectos debe llevarse a cabo de forma enteramente manual, lo que ha resultado en una ardua labor por parte de los testers y hasta de los mismos desarrolladores. Sin embargo, de momento no hay mucho que podamos hacer para cambiar esta situación, pues el ambiente sobre el que estamos trabajando es enteramente del cliente, y ya que aquél cerró su ciclo fiscal hace poco menos de un mes, ya no dispone del presupuesto necesario para adquirir una suite de pruebas automatizadas que permitan aligerar la carga de trabajo, al menos en lo que resta del año.

Aplicando un poco de pensamiento crítico, ¿acaso las pruebas automatizadas son tan buenas como dicen? ¿No será más práctico emplear a un ejército de testers que adquirir una herramienta? ¡Yo tenía la idea de que con JUnit y TDD es más que suficiente! ¿Qué consideraciones deberemos tomar si nos decidimos por el camino de la automatización? Es así como presento una pequeña introducción a la automatización de pruebas y algunos consejos para no dejarnos engañar por herramientas que se autodescriben como el non plus ultra, apoyando a tomar una decisión racional con respecto a una actividad que de forma ideal debería tomar el 20-25% del tiempo total necesario para generar un entregable técnico.

Algunas ideas erróneas sobre el automated testing

Primero que nada, es necesario aclarar ciertas falacias que han plagado la industria por años, gracias a elaborados trucos de marketing. En el excelente artículo Test Automation Snake Oil (con un título equivalente a “El fraude de la automatización de pruebas”) el autor e ingeniero de software James Bach describe algunos “supuestos peligrosos” que nos pueden llevar al desastre:

  • Las pruebas consisten en una secuencia de acciones. Una manera más útil de pensar en las pruebas es como una secuencia de interacciones entremezclada con evaluaciones; algunas son predecibles y objetivas, mientras otras son complejas, ambiguas y volátiles.
  • Una prueba significa repetir las mismas acciones una y otra vez. La variabilidad es una de las grandes ventajas de las pruebas manuales.
  • Podemos automatizar acciones de prueba. Probablemente la parte más difícil de la automatización es interpretar los resultados de la prueba, separando anomalías inofensivas de problemas graves. Un ejemplo clásico es el error de división del Intel Pentium.
  • Una prueba automatizada es más rápida ya que no necesita ninguna intervención humana. Todas las suites de pruebas automatizadas requieren de intervención humana, aunque sólo sea para diagnosticar los resultados y corregir pruebas erróneas.
  • La automatización reduce el error humano. Sí, se reducen algunos errores. Aquellos que los seres humanos hacen cuando se les pide llevar a cabo una larga lista de actividades mentales y táctiles aburridas. Pero otros errores se amplifican.
  • Podemos cuantificar los costos y beneficios de las pruebas automatizadas vs. manuales. La realidad es que las pruebas manuales y las pruebas automatizadas son dos procesos diferentes, en lugar de dos maneras diferentes para ejecutar el mismo proceso.
  • La automatización conducirá a un “importante ahorro en costos laborales”. Los costos de desarrollo de la automatización, de operación de las pruebas automatizadas, del mantenimiento de la automatización conforme el producto cambia y de cualquier otra tarea que es requerida por la automatización, deben sopesarse contra los costos de diseño, configuración e implementación de pruebas manuales. Usualmente la automatización resulta ser más costosa.
  • La automatización no dañará el proyecto de prueba. Ciertamente, es peligroso automatizar algo que no entendemos. Si no tenemos una clara estrategia de pruebas antes de la introducción de la automatización, el resultado será una gran masa de código de prueba que nadie entiende completamente.

Siendo así las cosas, la automatización se define como una técnica que facilita las labores repetitivas, liberando a los testers de actividades tediosas para permitirles concentrarse en lo que verdaderamente importa: la funcionalidad de negocio que el usuario espera.

Automatizando

Los testers son percibidos con frecuencia como los cuellos de botella durante la entrega de productos de software. Así, se les exige probar más y más código en cada vez menos tiempo. Por otro lado, conforme diferentes versiones de un código son liberadas, la nueva funcionalidad debe probarse en conjunto con las características previamente existentes, por lo que el ciclo de pruebas tiende a volverse cada vez más lento. Hoy por hoy, ya existen herramientas que permiten reducir los tiempos de prueba mediante una interfaz gráfica de usuario, mientras otras herramientas facilitan la ejecución de pruebas de desempeño – que anteriormente tenían que implementarse mediante un ejército de testers simulando los usuarios de una aplicación.

En un intento de hacer más con menos, no hay más remedio que usar estas herramientas en los proyectos. La automatización de pruebas consiste en el uso de herramientas de software especializadas que permiten controlar la ejecución de pruebas, comparación de resultados reales contra resultados previstos, creación de las condiciones previas para la ejecución de pruebas, así como otras funciones de control y presentación de reportes. Comúnmente, la automatización de pruebas busca automatizar procesos manuales y repetitivos ya existentes que siguen una metodología de pruebas formal. La mayoría de las herramientas de prueba pueden ayudar a automatizar tareas como la instalación del producto, creación de datos de prueba e interacción con la interfaz de usuario; el objetivo principal consiste en simplificar las pruebas de regresión: es decir, se genera un repositorio de casos de prueba detallados que son repetibles y que se ejecutan en su conjunto cada vez que haya un cambio en la aplicación. Esto se hace para asegurar que ningún cambio traiga consecuencias imprevistas. Es importante recalcar que la automatización de pruebas es algo caro y debe considerársele como un complemento – no un reemplazo – de las pruebas manuales. Sólo a largo plazo o en productos de software con ciclos de mantenimiento muy extensos puede llegar a ser más rentable que trabajar con grupos de testers dedicados.

Pros y Contras

No todo es miel sobre hojuelas, sin embargo. Previo a adoptar una herramienta de automatización de pruebas es necesario tomar en consideración que el verdadero costo de la automatización se mide por el número de pruebas manuales que no estamos ejecutando y por lo tanto, el número de incidencias o bugs que estamos dejando pasar. Eventualmente, la decisión entre automatizar o seguir procesos manuales deberá llevarse a cabo contestando las siguientes preguntas: ¿Si automatizo esta prueba, qué pruebas manuales puedo perder? ¿Cuántos errores de usuario pueden escaparse al no ejecutar dichas pruebas? ¿Cuál será su severidad? De acuerdo al ingeniero de pruebas y autor Brian Marick:

Una prueba está diseñada para un propósito determinado: revisar si algunos aspectos de una o más características funcionan. Cuando una prueba automatizada detecta incidencias, deberías asumir que encontrarás errores que parecen no tener nada que ver con el propósito original de la prueba. Gran parte del valor de una prueba automatizada radica en lo bien que se puede hacer eso.

Marick, Brian. (1998). “When Should a Test Be Automated?” uml.org.cn.

En caso de decidirse por la automatización, deben incluirse medidas para investigar si la incorporación de dicha herramienta será beneficiosa para el proyecto, teniendo en cuenta los requisitos de prueba, ambiente de pruebas disponible, personal capacitado, entorno de usuario, plataforma del proyecto, así como las características de la aplicación a ser validada. También es importante realizar las estimaciones y modificación correspondiente al plan de proyecto para garantizar el tiempo mínimo indispensable para la instalación de la herramienta, así como la jerarquía de requerimientos; es necesario realizar pruebas de concepto (Proof of Concept – PoC) con las potenciales herramientas y utilerías de prueba, validando la compatibilidad con el ambiente aplicativo y buscando soluciones alternativas a problemas de incompatibilidad que surjan durante esta PoC. En términos generales, algunos de los pros y contras de adoptar herramientas de automatización de pruebas serían los siguientes:

Pros:

  • Si es necesario ejecutar una serie de pruebas en múltiples ocasiones, para un gran número de usuarios.
  • Código que cambia con frecuencia, buscando detectar regresiones en el momento oportuno.
  • Ejecutar pruebas durante los escenarios principales para detectar regresiones de forma periódica. Por ejemplo: en un build nocturno o nightly build.
  • Matriz de pruebas de grandes dimensiones, como un producto destinado a diferentes idiomas en plataformas y sistemas operativos diversos.
  • Ejecución en paralelo sobre diferentes máquinas – mientras que las pruebas manuales tendrían que ejecutarse secuencialmente.

Contras:

  • La automatización es demasiado costosa (tiempo y/o presupuesto). Escribir los casos de prueba y configurar la herramienta siempre es más costoso al principio que correr las pruebas de forma manual.
  • No se pueden automatizar referencias visuales. Por ejemplo, si la herramienta no permite detectar el tipo de letra o color, será necesaria una prueba manual.
  • No se pueden automatizar pruebas al azar, por lo que es imposible detectar verdaderos errores de usuario.
  • Ambientes complejos donde una herramienta no sea suficiente para probar la aplicación en su conjunto. Por ejemplo, aplicaciones multiplataforma.

Conclusiones

La automatización puede ofrecer grandes beneficios, siempre y cuando recordemos que “testing” no sólo significa probar lo mismo una y otra vez hasta el cansancio: éste implica evaluar los resultados de acuerdo a diferentes entradas y concentrarse en aquellas incidencias que restan valor agregado al cliente. Luego, tenemos que ser muy cuidadosos con el tipo de herramienta que utilizaremos, pues ninguna de las herramientas encontradas en el mercado actual hará el trabajo por nosotros. Finalmente, es importante tener una clara idea de qué tareas puede simplificar y la utilicemos como un complemento de las pruebas manuales, ya que:

Un tonto con una herramienta sigue siendo un tonto.

Grady Booch (n. 1955), ingeniero de software estadounidense, co-autor del Lenguaje Unificado de Modelado (UML).

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: