Migrar a testing opensource

Si estás pagando por licencias caras en herramientas de testing, quizá algo a considerar es migrar a alternativas de testing opensource para optimizar costos, especialmente en estos días de COVID-19 (en este otro post dejé más ideas para optimizar costos).

Creo que todos estamos de acuerdo que esto requiere una inversión inicial (para realizar la migración) así que la reducción de costos se da más en mediano o largo plazo. 

Las herramientas opensource siempre dan una flexibilidad grande y hay muchas que tienen un nivel de calidad enorme, contando muchas veces con una gran comunidad de fondo que hacen que se pueda contar con muy buen soporte. 

Hay otros casos donde quizá no sea tan conveniente migrar a opensource. Por ejemplo, si bien se puede automatizar las pruebas de una aplicación web GeneXus con Selenium, usar GXtest tiene ventajas que no se obtienen con herramientas que no son específicas. Por otro lado, si un equipo ya está usando JIRA y lo tiene integrado con muchas herramientas, no pensaría en migrar JIRA a Mantis por ejemplo. Pero hay muchos otros casos donde tiene mucho sentido.

Por plantear un ejemplo inicial, si hoy tenés LoadRunner para las pruebas de performance, es muy fácil migrarse a JMeter o Gatling, que desde mi punto de vista son incluso mejores para la gran mayoría de los casos. En el caso de querer migrar de LoadRunner a JMeter, se puede hacer automáticamente con el converter ofrecido por Blazemeter. 

En este post quiero compartir una estrategia a seguir para este proceso:

• Primero ver algunas cosas a tener en cuenta para seleccionar la herramienta opensource.
• Luego, revisar posibles estrategias para migrar sin problemas.

Eligiendo una herramienta de testing opensource

Hay algunas cosas que me parecen muy importantes al momento de elegir a qué herramienta de testing opensource migrar, ya que generalmente vamos a tener muchas alternativas. 

Comunidad

• Revisar si existe una comunidad de fondo, para obtener soporte, consultas, buscar foros, etc.
• Esto es importante también para saber qué tan fácil va a ser conseguir gente capacitada en esta herramienta al buscar contratar personas para el equipo, o equipos tercerizados. 
• ¿Existen capacitaciones para formar a mi equipo?

¿Que tan actualizada está?

• Podríamos revisar el repositorio en GitHub o donde esté hosteado el código de la herramienta. Por ejemplo, en el caso de Taurus podemos acceder acá: https://github.com/Blazemeter/taurus.
• En el repositorio se puede ver la cantidad de contributors, ver cuándo fue el último update, ver lista de issues abiertos, ver cuándo fue el último release y que tan frecuentes son.

Tecnología de base

• Creo que es importante pensar a futuro, si es una herramienta parada sobre Visual Basic, probablemente no tenga mucho futuro, por más que tenga cientos de contributors y hayan liberado una nueva versión hace poco. 

Estas son generalidades, claro que hay muchas cosas más a tener en cuenta y luego tendremos que revisar más cuál es la que más nos conviene en aspectos más particulares. Por ejemplo, si hablamos de testing automatizado a nivel web, tenemos muchas herramientas que cumplen con estas generalidades como Selenium (en diversos sabores), WebdriverIO, Cypress, etc., etc. Para decidir cuál conviene más hay que entrar a comparar más al detalle la compatibilidad con nuestro contexto, tanto a nivel tecnología, skills del equipo, forma de uso que le queremos dar, posibilidad de integración con otras herramientas, performance, etc.

Estrategia para migrar

Una vez que decidiste a qué herramienta, plataforma o conjunto de herramientas migrar, el tema es cómo hacer esta migración sin perder la continuidad de los beneficios que la herramienta actual te está dando. 

Acá algunas ideas:

• Primero buscar si alguien compartió experiencias similares a la migración que queremos hacer, si alguien más ya migró de Load Runner a JMeter por ejemplo.
• Al hacer esta búsqueda, ver si existen herramientas o scripts que ayuden. En particular, para el ejemplo mencionado, nosotros estuvimos trabajando con Blazemeter en un converter (podés ver más al respecto acá).
• Una posibilidad sería también buscar si hay empresas que ayuden a hacer esta migración (obvio que tengo que nombrar que en Abstracta tenemos mucha experiencia haciendo esto 🙂 )
• Por último y diría que de lo más importante, seguir un enfoque risk-based approach, o ROI-based approach. O sea, si estamos hablando de migrar casos de prueba automatizados de una herramienta a otra, analizar cuáles son los casos que más vale la pena migrar primero. 
• Para la migración en sí, las estrategias que se me ocurren son estas (digamos que hablamos de migrar una herramienta de automatización a otra, pero es aplicable para varios casos distintos):
  • Migración big bang: migrar todo de una, trabajar en la migración y hasta no tener todo no sustituir una herramienta por la otra.
  • Migración progresiva: ir migrando caso a caso, y seguir ejecutando con las dos herramientas pero con la nueva los casos migrados, con la vieja los casos aún no migrados. 
  • Migración en paralelo: tener las dos ejecuciones en paralelo de todos los casos en la vieja y de todos los casos ya migrados en la nueva, mientras dura toda la migración. Analizar las diferencias en los resultados. Esta creo que es la mejor solución de ser posible, ya que es ideal para ganar confianza, asegurando que los reportes de ambas soluciones sean iguales. El problema puede ser la disponibilidad del ambiente de pruebas, si tenemos tiempo suficiente para ejecutar dos veces las pruebas. 

Vos, ¿alguna vez hiciste alguna migración? ¿Cuál es tu experiencia con herramientas de testing opensource?