Introducción a las pruebas automatizadas en Informática

TEST DE REGRESIÓN

Las pruebas de regresión son un subconjunto de las pruebas planificadas que se seleccionan para ejecutar periódicamente, por ejemplo, ante cada nueva liberación del producto. Tienen el objetivo de verificar que el producto no ha sufrido regresiones.

¿Por qué se llaman pruebas de regresión?

Está asociado a verificar que lo que estoy probando no tenga regresiones. iQueremos evitar esas regresiones!

Tampoco es válido pensar que las pruebas de regresión se limitan a verificar que se hayan arreglado los bugs que se habían reportado, pues es igual de importante ver que lo que antes andaba bien ahora siga funcionando.

Ejecutar las pruebas de regresión consistirá en ejecutar nuevamente las pruebas previamente diseñadas.

El testing es algo donde uno pone creatividad, atención, busca caminos nuevos, piensa '¿de qué otra forma se puede romper?'. Al chequear simplemente, nos dejamos llevar por lo que alguien ya pensó antes, por esa ya mencionada lista de pasos."

El testing automatizado consiste en que una máquina logre ejecutar los casos de prueba en forma automática, leyendo la especificación del mismo de alguna forma, que pueden ser scripts en un lenguaje genérico o propio de una herramienta, a partir de planillas de cálculo, modelos, etc. Por ejemplo Selenium18 (de las más populares herramientas open source para automatización de pruebas de aplicaciones Web) tiene un lenguaje llamado Selence, brindando un formato para cada comando (acción) que puede ejecutar, y de esa forma un script es una serie de comandos que respetan esta sintaxis. La herramienta además permite exportar directamente a una prueba JUnit19 en Java, y a otros entornos de ejecuciones de pruebas.

A continuación, compartimos algunas ideas tomadas de distintas charlas con varias personas con distintos roles dentro del proceso de desarrollo, como para entender mejor qué es lo que se busca hacer al automatizar este tipo de pruebas.

Perspectivas sobre la automatización de pruebas

Desarrollador: Quiero hacer cambios sobre la aplicación, pero me da miedo romper otras cosas. Ahora, testearlas todas de nuevo me da mucho trabajo. Ejecutar pruebasautomatizadas me da un poco de tranquilidad de que con los cambios que hago las cosas que tengo automatizadas siguen funcionando.

Tester: Mientras automatizo voy viendo que la aplicación funciona como es deseado, y luego sé que lo que tengo automatizado ya está probado, dándome lugar a dedicar mi tiempo a otras pruebas, con lo cual puedo garantizar más calidad del producto.

Desarrollador: Hay veces que no innovo por miedo a romper, principalmente cuando tengo sistemas muy grandes, donde cambios en un módulo pueden afectar a muchas funcionalidades.

Usuario: Cuando me dan una nueva versión de la aplicación no hay nada peor que encontrar que lo que ya andaba dejó de funcionar. Si el error es sobre algo nuevo, es entendible, pero que ocurra sobre algo que ya se suponía que andaba cuesta más. Las pruebas de regresión me pueden ayudar a detectar estas cosas a tiempo, antes de que el sistema esté en producción.

RETORNO DE LA INVERSIÓN

The cost of a single defect in most organizations can offset the price of one or more tool licenses (extraído de "Surviving the Top 10 Challenges of Software Test Automation" de Randall W. Rice).

Costo o inversión en testing

¿Costo o inversión? Generalmente se dice que el testing automatizado permite ampliar la cobertura y alcance de las pruebas, reducir costos, poner el foco de las pruebas manuales en lo que realmente interesa, encontrar defectos más temprano, etc., etc., etc., y de esa forma reducir costos y riesgo. Todo esto parece ser siempre la misma estrategia de marketing que plantean los vendedores de herramientas, sin justificación suficiente.

Es interesante apuntar lo que se plantea en un artículo20 de Paul Grossman, publicado por un importante proveedor de la industria del software y hardware, donde se habla de los beneficios de la automatización de pruebas en términos financieros, más que nada para dar más argumentos a quien quiere visualizar o mostrar el valor que tiene este tipo de inversiones (ya que verán al final que no se trata de un gasto, sino de una inversión para ganar no solo en calidad sino en ahorro de dinero).En cierta forma pondremos esos beneficios en duda.

Para saber si "invertir" analicemos si esa inversión es un costo que tiene la calidad, o si también significará ahorros en otros costos asociados a la falta de calidad. Para esto tenemos que verlo en números para entender y creer.

Para las pruebas, aunque sean "automáticas" y "ejecutadas por una máquina", vamos a necesitar gente capacitada. Además, no es la idea reducir el personal dedicado a testing, pues el test manual aún se necesita, y las pruebas automatizadas requieren cierto esfuerzo para su construcción y mantenimiento

Lo más importante es que al automatizar podemos expandir dramaticamente el alcance de las pruebas con el mismo costo (con la misma inversión), y eso es algo que financieramente da ventajas claras: conservar los costos y aumentar el beneficio.

Ejemplo hipotético de inversión en pruebas

Veamos con un ejemplo hipotético que sea más entendible por alguien que decide sobre las finanzas de una empresa:

Un tester ejecuta manualmente pruebas 8 horas por día y se va a su casa. En ese momento el testing se detiene. Con el test automatizado se puede estar ejecutando pruebas 16 horas más por día (en el mejor caso claro ... ), bajo el mismo costo, lo cual reduce el costo de las horas de test. Paul Grossman plantea que un tester en promedio cuesta 50u$s la hora (¡ojalá en Uruguay fuera igual!) y si es senior cuesta 75u$s (idivino!). Siendo así serían 400u$s o 600u$s respectivamente por día, pero en el segundo caso serían 16 horas más que en el primero (esto es porque considera que el senior es el que sabe automatizar, el otro solo se considera para test manual). Además, los test automatizados corren más rápido que los test manuales, en promedio digamos que 5 veces más rápido (generalmente, es más, pero no exageremos). Si hablamos de un equipo de 10 personas, 5 senior y 5 para test manual, tenemos un costo mensual de 105.000u$s (168hs por mes, o sea 8 horas por 21 días, 42.000 en test manual y 63.000 de testers senior). Esto en principio nos da un total de 1.350 horas a un costo de 78u$s la hora (acá se está considerando que de las 168 horas mensuales de trabajo, se estará ejecutando 135, lo cual podría suponerse como razonable si se considera cualquier overhead como enfermedad, vacaciones, capacitación, etc.). Si ponemos a 3 de los senior a automatizar, el costo seguirá siendo el mismo pero tendríamos 16hs x 3 seniors x 21 días x 5 veces más test por hora, lo que nos da un agregado de 5.040 horas mensuales equivalentes a horas de test manual. Si consideramos el resto del equipo haciendo pruebas manuales (7 x 135) son 945 horas más, lo que da en total 5.985hs de test con un costo de 17,5u$s la hora (105.000u$s / 5.985 horas). Esto es un beneficio expresado en términos financieros, que se entiende fácilmente. Pasamos de pagar la hora de test de 78u$s a 17,5u$s, o visto de otro modo, aumentamos las horas de prueba de 1.350 a 5.985 bajo el mismo costo. Se muestra el resumen de este razonamiento en la Tabla 10.

Manual Automatizado Horas 10 x 135 = 1.350 horas Horas 3 x 21 x 16 x 5 = 5.040 horas 7 x 135 = 945 Total: 5.985 horas Costos 78u$s por hora Costos 17,5u$s por hora TABLA 10 - COMPARACIÓN DE COSTOS POR HORA

Claro que SÍ, y veremos ahora cómo encontrar más errores nos ahorra costos, aunque nos da más trabajo (es algo obvio, pero hagamos más cuentas para visualizarlo mejor).

Es conocida en ingeniería de software la gráfica que muestra el costo de corregir un defecto detectado según en la etapa que se haya encontrado (desarrollo, integración, beta testing, producción). De hecho, he leído en un foro que querían hacer una apuesta sobre cuántas charlas (en una determinada conferencia) iban a comenzar mostrando esa gráfica. ¡ Si será popular!

En la Tabla 11 se muestra un estudio de cuantas horas en promedio cuesta corregir un defecto según la etapa, y considerando costo por hora, cuánto cuesta en dólares. Esto no está considerando siquiera los costos ocultos que hay como la pérdida de imagen, confianza, e incluso el desgaste del equipo.

Lo que se desprende de esto es algo ya muy conocido: cuanto antes se encuentren los bugs, mejor. Y como vamos a tener testers que trabajan 24hs al día, ejecutando más rápido, es más probable que se encuentren más errores antes de pasar las versiones a beta testing o a producción. Es difícil estimar cuántos, pero por cada bug que se encuentre más temprano se ahorrará al menos 200u$s .... ¡ nada mal! Esto se puede ajustar al precio que cuesta la hora de los desarrolladores en su equipo y seguirá siendo rentable.

Valor del test automatizado

A modo de resumen podemos decir que hay dos cosas a las que el test automatizado le agrega valor:

• Business value: Da valor al negocio mejorando la calidad, evitando problemas de operativa, pérdida de imagen de clientes e incluso evitando problemas legales.
• IT value: Mejora el trabajo del grupo de IT ya que le simplifica las tareas rutinarias, permitiendo que con el mismo costo hagan mucho más y mejor.

¿CUÁNDO SE HACEN VISIBLES LOS RESULTADOS?

Tal vez uno piense que si las pruebas me encuentran un error es ahí cuando estoy encontrando beneficios, entonces voy a poder medir la cantidad de bugs detectados por las pruebas automatizadas. En realidad el beneficio se da desde el momento de modelar, y especificar con un lenguaje formal las pruebas a realizar. Luego, la información que da la ejecución de las pruebas también aporta un gran valor.

NO es solo útil el resultado de error detectado, sino el resultado de OK que me está diciendo que las pruebas que ya automaticé están cumpliendo lo que verifican. Un artículo de Methods and Tools23 dice que se encuentran gran cantidad de bugs al momento de automatizar los test cases. Al automatizar uno debe explorar la funcionalidad, probar con distintos datos, etc. Generalmente lleva un tiempo en el que uno está "dándole vueltas" a la funcionalidad a automatizar. Luego, para probar que la automatización haya quedado bien se ejecuta con distintos datos, etc. En ese momento ya estamos haciendo un trabajo de testing muy intenso.

El riesgo es que las pruebas automatizadas noesten cubriendo todas las funcionalidades (paradoja del pesticida). Dependencia con la calidad de los test. Tal vez tengo mil pruebas, y por eso creo que tengo un buen testing, pero esas pruebas quizá no verifican lo suficiente, son superficiales o todas similares.

El valor de automatizar no se ve en la cantidad de pruebas ni en la frecuencia con que ejecuto esas pruebas, sino por la información que proveen 24 (que complementa la información que nos aporta un tester que ejecuta en forma manual).

¿POR QUÉ Y PARA QUÉ AUTOMATIZAR?

Pasemos a hablar ahora directamente de automatización de pruebas. Si nos basamos en una definición tradicional de automatización

• Mejora la calidad, pues hay menos errores humanos.
• Mejora la performance de producción, pues con las mismas personas se puede lograr mucho más trabajo, a mayor velocidad y escala, y en ese sentido mejoran el rendimiento de las personas.

Llamamos "acumulatividad nula"25. las features crecen cada vez mas a lo largo del tiempo (de una versión a otra), pero el test no (no conozco de ninguna empresa que a medida que desarrolle más funcionalidades contrate más testers).

Esto es un problema, pues significa que cada vez más se nos da la situación de tener que elegir qué testear y qué no, y dejamos muchas cosas sin probar. El hecho de que las features vayan creciendo con el tiempo, implica que el esfuerzo en testing debería ir creciendo