Como Automatizador en el mundo del Testing te has preguntado ¿Es viable la automatización de una aplicación de escritorio, Web o Mobile en el negocio o proyecto donde te encuentras?

Partamos de los inicios, sin centrarnos aún en la aplicación de escritorio ¿Realmente revisas la viabilidad previa al inicio de una Automatización? ¿o inicias desarrollo de tu estrategia de pruebas E2E sin importar la ganancia a futuro de tu artefacto en entrega?

Emprendamos conociendo que la razón de ser, de automatizar, es controlar la ejecución de las pruebas, realizando la comparación de resultados obtenidos versus los resultados esperados.

Con la definición anterior, podríamos intuir entonces que el objetivo de Automatizar es:

  • Disminuir el esfuerzo invertido en procesos repetitivos
  • Incrementar la eficiencia en el proceso del Testing
  • Multiplicar la velocidad del Testing en la etapa de ejecución
  • Hacer uso de la reutilización de artefactos de pruebas previamente diseñados

De esta manera automatizar nos ayuda a reducir los riesgos de fallos, incrementar la productividad y nos enfocan a pruebas con la inclusión completa del proceso de negocio.

Entendamos entonces a que se refiere Pruebas del proceso del negocio:

Cuando hablamos de un proceso de negocio estamos teniendo en cuenta la solución tanto funcional como técnica, verificando los requerimientos definidos por los dueños del producto e ingenieros técnicos.

En el proceso de construcción de software, ¿qué tan importantes son las pruebas? ¿O son un cuello de botella adicional, al equipo de desarrollo antes de promover a producción?

Aunque en esta ocasión nuestro enfoque sea las pruebas Automatizadas en aplicaciones de escritorio, hagamos un alto en el camino, y definamos en una frase los tipos de pruebas más importantes:

Unitarias:  Pruebas de código de cada componente

Modulares:  Interacción entre componentes del aplicativo

Integración:  Integración entre módulos o sistemas

Regresión:  Asegurar que no haya nuevos errores en áreas del software que no se han modificado

E2E: Procesos de negocio de principio a fin

Aceptación: Necesidades reales del usuario

Ahora, miremos los criterios más fuertes que cada automatizador debe tener antes de afrontar alguna aplicación en un proyecto, y poder concluir si nos volcamos a participar como equipo de automatización generador de valor en la calidad del software:

Criterio 1:  Un alto nivel de repetitividad de pruebas, procesos u operaciones

Criterio 2: Tiempo de permanencia de la aplicación que permita obtener el retorno sobre la inversión

Criterio 3: La automatización de pruebas es viable con aplicaciones estables, que no se alteren fácilmente con los cambios

Criterio 4: Poco tiempo y un alto esfuerzo para la realización de las pruebas

Criterio 5: Aplicaciones criticas o aplicaciones que presenten cambios de alto impacto para el negocio

Criterio 6: Alta frecuencia en recepción de versiones (Release)

Importante: Desde nuestra experiencia en el mundo del software, y más aún en el mundo DevOps, podemos intuir que en los casos en los cuales la Automatización cuesta mucho tiempo y la ejecución de las pruebas requiere de mucha capacidad y desgaste, la orientación a automatizar debe ser mínima.

 

¿En qué momento sabremos si mi equipo de Automatización de Pruebas es realmente experto en sus funciones ?

 Antes de llegar a este nivel, debimos haber realizado el filtro según los criterios anteriores, y haber decidido dar inicio al montaje de un equipo de alto rendimiento de Automatización, o también llamado en algunas organizaciones equipo PITT (Paralell independent Testing Team).

 

Un equipo de Automatización de alto Rendimiento consta de 3 procesos importantes:

  1. CONSTRUCCIÓN: Es donde se debe tener un panorama muy amplio de la cobertura que vamos a tener según la cantidad de procesos de negocio de las aplicaciones del proyecto, previo al inicio desarrollo de los artefactos. 
  • Analizar el proceso de negocio
  • Analizar componentes existentes para reutilización
  • Crear componentes para el proceso del negocio
  • Pruebas por componente
  • Armar el flujo técnico para los componentes
  • Pruebas de flujo exitoso y fallido

 2. EJECUCIÓN: Dar inicio a la ejecución y estabilización de las pruebas E2E de los procesos de negocio construidos anteriormente.

  • Creación de la data
  • Adecuación de DataDriven
  • Adecuación del ambiente
  • Estabilización de los Scripts o artefactos creados

3. MANTENIMIENTO: Se identifican los cambios en las transacciones que ya se tienen automatizadas, analizando el impacto y realizar los cambios necesarios a nivel de flujo, colocándolos a punto para que se puedan ejecutar nuevamente. 

  • Analizar el cambio del proceso de Negocio
  • Analizar los componentes existentes para reutilización
  • Analizar afectación del cambio en los componentes
  • Crear o modificar componentes por proceso de negocio
  • Pruebas por componente
  • Pruebas de flujo exitosa y fallido

Durante estos tres procesos tomados como los mas relevantes para los automatizadores que hacen parte de un equipo maduro de Automatización, es indispensable contar con un valor agregado, que es la Gestión y el orden llevado a cabo antes, durante y después de cada proceso. Dentro de las tareas de Gestión tenemos:

  • Definición y priorización del Backlogg
  • Gestión de las historias de usuario en VSTS
  • Informe de seguimiento del equipo PITT
  • Análisis del impacto de proyectos y día a día
  • Diligenciamiento de indicadores y métricas
  • Gestión de ambiente
  • Gestión de Data

Por último, hagamos un paralelo de las diferencias mas marcadas que encontramos en las tres aplicaciones principales que encontramos en los proyectos TI: 

APLICACIONES

DRIVER

MAPEO ELEMENT

VELOCIDAD EN EJECUC

PARALELIZACIÓN

Escritorio

WindowsApplicationDriver

ApiumDesktop

Menos veloz que las demás aplicaciones

Mayor complejidad

Web

WebDriver Selenium (ChromeDriver – GrekoDriver)

Inspector de cada navegador

Mayor Velocidad

Fácil de Paralelizar

Mobile

Apium

ApiumDesktop

Mas veloz que las aplicaciones de escritorio

Mayor complejidad

 

Como conclusión podemos decir que antes de tomar una decisión de Automatizar o No, debemos conocer cuál es la viabilidad económica versus la factibilidad tecnológica con el fin de generar un aporte de valor importante al proyecto donde nos encontremos y no un eslabón impenetrable debido a las demoras en las ejecuciones, por causa de un mal análisis al momento de la toma de decisiones sobre la aplicación automatizar.