ROI & PAYBACK de la Automatización de Pruebas

ROI vs. PAYBACK

Cuando se piensa en la automatización como posible solución en un proyecto de testing, se hace necesario un estudio de viabilidad que nos indique qué rentabilidad vamos a obtener, y cuándo podremos considerar que estamos amortizando la inversión realizada.

En general, este estudio de viabilidad o no se realiza, o se realiza de manera muy general, o incluso se hace partiendo de premisas incorrectas o falsos mitos sobre la automatización. Veamos en primer lugar dos conceptos a tener en cuenta:

• ROI (Retorno de la inversión): Es el beneficio que obtenemos de la automatización puede ser calculada de diferentes formas:
• % de beneficio obtenido: según la siguiente formula (Beneficio -Inversión)/Inversión. No obstante, también es posible encontrar el ROI de la automatización expresado directamente en horas de trabajo.
• Horas totales de ejecución manual ahorradas
• Costo total de ejecución manual ahorrado

• PAYBACK: Indica el tiempo que tardamos en obtener un beneficio de la inversión realizada. En el caso de la automatización, nos indicaría a partir de qué momento la inversión realizada en la automatización es amortizada.

Ambos conceptos, deben ser evaluados objetivamente y mediante parámetros adaptados a nuestro proyecto. Pasar por alto este estudio podría llevarnos a sorpresas no deseadas pero que son muy habituales. 

De manera general, la automatización supone una inversión que rentabilizaremos a medio plazo cuando el ahorro en horas de ejecución manual supere el tiempo invertido en la automatización. 


Es decir, la automatización supone unos costos (en licencias, infraestructura, scripting, etc...). Esta inversión será amortizada a lo largo del tiempo a costa de las horas de ejecución manual que ya no son necesarias. Es importante hacer constar que para el cálculo del ROI, es necesario conocer el costo del esfuerzo invertido en la ejecución manual de los casos de prueba. Sin ese dato, será muy difícil poder evaluar la viavilidad de un proyecto de automatización.

JMeter . Análisis plugin HTTP Simple Table Server

Hola de nuevo. Tras este periodo de tiempo sin publicar, se nos ha vuelto a iluminar la cabeza con una idea (de ahí ese molesto fogonazo que vemos de vez en cuando) , actualizando la entrada correspondiente al uso de máquinas remotas como inyectoras

Hasta ahora, como habíais visto en nuestro artículo referente a los equipos externos,  estos  se encontraban con una limitación muy importante comparados con otras herramientas  para pruebas .

Los ficheros de datos debían estar duplicados en la misma ruta  indicada  en el script en todas y cada una de las máquinas remotas.

Como uno se puede imaginar, esto obligaba a duplicar dichos ficheros y copiarlos. Sin embargo en la página de http://jmeter-plugins.org , hemos analizado el comportamiento de un plugin  categorizado como “Extra” que permite aplicar una alternativa para solventar esta limitación

Plugin HTTP Simple Table Server.

Este elemento,  tipificado dentro de la jerarquía del contenido del Extra Set como “Otros” , permite publicar  por el protocolo HTTP  un fichero , de manera que se puede acceder a los contenidos del mismo  en modo de base de datos

•       Lectura de un elemento
•       Escritura de un elemento
•       Estado actual del fichero
•      Tamaño del fichero

Es decir permite ciertas operaciones de consulta, inserción y estado, de modo que los registros o filas que contiene pueden ser usados en la operativa de un script  de JMeter.

El plugin se basa  en un pequeño servidor web que puede ser arrancado bien desde el modo de interfaz de usuario de JMeter, bien por línea de comandos o configurarlo en las propiedades de JMeter de manera que arranque de manera automática cada  vez que se inicie JMeter

Para hacer más ligero este documento, llamaremos al plugin como HTTP STS

Configuración

Independientemente del método de ejecución de este servidor, este necesita indicar varios parámetros para su uso

• Puerto TCP de operación
• Directorio de datos.

Arranque

Desde  la interfaz de  usuario, se puede incluir un HTTP STS como un elemento No de Prueba sobre el Workbench o “Banco de trabajo” de un script de JMeter

Incluir STS desde Banco de Trabajo

Esta manera  de incluirlo hará que sólo esté disponible mientras si se encuentre arrancado en modo gráfico, deteniéndose una vez que cerremos el script o detengamos el interfaz de JMeter

Arrancar STS desde JMeter GUI

Automatización de Pruebas en App Mobile con MonkeyTalk (y II)

En la anterior entrada hemos visto los primeros pasos para configurar un framework de automatización de pruebas para dispositivos móviles con Monkeytalk, ahora nos centraremos en las actividades propias del proceso de automatización como son la grabación de scripts, la construcción de casos de test, la ejecución y el análisis de resultados.

La selección de una herramienta adecuada a nuestros objetivos y que cubra las necesidades técnicas es un proceso de clave que debe ser evaluado en el momento que nos planteemos la automatización.

2 Framework de Automatización (cont.).

• Grabación:  Al igual que en cualquier otro proceso de automatización, la grabación de nuestros casos de prueba es una herramienta potente para obtener la base de nuestros scripts. En el caso de dispositivos móviles, la podemos realizar directamente desde un dispositivo (emulado o real), sobre un Sistema Operativo concreto (IOs o Android) y a través de diferentes conexiones entre nuestra herramienta y dispositivo sobre el que grabamos (USB, WiFi o Emulador).

Automatización de Pruebas en App Mobile con MonkeyTalk (I)

1 Introducción.

El éxito de las aplicaciones móviles, presenta uno de los mayores retos en el área de la automatización de pruebas: ¿cómo conseguir automatizar las pruebas funcionales con independencia de la tecnología de la app (Web o Nativa), del sistema operativo (Android, IOs, etc..) y del extraordinario número de terminales que se encuentran en el mercado?

Las ventajas que presenta la automatización se hacen mucho visibles cuando nos movemos en el mundo "mobile". La posibilidad de disponer de nuestros scripts listos para la ejecución en paralelo en un conjunto grande de dispositivos (reales o emulados) de diferentes características supone un ahorro de tiempo que sin lugar a dudas debe ser valorado adecuadamente. 

En el siguiente vídeo se puede observar el resultado de la "demo" que hemos preparado para elaborar esta entrada ejecutando una TestSuit automática de manera desatendida sobre dispositivos de muy diferentes características:

• Dispositivo Real Samsung Galaxy Trend con Android 4.0.
• Dispositivo Real Tablet Acer Iconia A100 con Android 4.0.
• Dispositivo Emulado Nexus 5 con Android 2.2.

En esta entrada vamos a ver un framework de automatización de pruebas para apps mobile con la herramienta de automatización MonkeyTalk, cuyas principales características son:

Loadrunner 11.5. Virtual User Generator, entendiendo conceptos

Como diria Fray Luis de León y su "como deciamos ayer.." , seguimos con este análisis de la herramienta Loadrunner en su versión 11.5 . Ahora, con el análisis de los cambios que se incluyen en su generador de scripts Virtual user Generator

1. Script y Solution. 
2. Diferencias de la interfaz
3. Ejecutando

Script y Solution

Nada más arrancar el Virtual User Generator podemos ver  que se nos presenta una interfaz algo alejada de la distribución en marcos de uso que veniamos viendo hasta las versiones 9.X.  La razón fundamental es que ahora el entorno está basado en la interfaz de entorno de compilación y desarrollo Eclipse .

Nada más iniciar la creación de un nuevo script que refleje una navegación a probar , podemos ver que se invoca un nuevo concepto "Solution". Por lo que hemos podido ver hasta ahora, , su utilidad radica en poder combinar varias navegaciones más allá del uso de subtransacciones y nuevos Action para reflejar un flujo lógico de uso .

Solution con un sólo script protocolo Siebel Web

Podemos incluso incluir en una sola "solution" varios script de distintos protocolos que