En algunas áreas TI, aún no existen consensos respecto a qué tecnología son mejor para realizar labores, esto es un tema que trae de cabeza a algunos Tester como Michael Fritzius, CTO de Arch DevOps.

Fritzius indica que los candidatos obvios son Java y Python, sin embargo estos son remanentes de cómo se realizaron pruebas en el pasado. Los desarrolladores tuvieron la tarea de crear sus pruebas, por lo que escribieron scripts de prueba que usaban idiomas que ya conocían.

El CTO considera que, en la actualidad, los desarrolladores deberían dedicar su tiempo a producir código nuevo. Lo que significa que los Tester están a cargo del proceso de prueba. Y eso significa que pueden elegir qué lenguajes usarán para escribir sus scripts de automatización de prueba.

Para aquellos que están en conflicto sobre el uso del mismo lenguaje tanto para codificar como para evaluar. Ya sea que use Java o Python o
Fritzius para crear una página web, finalmente está creando código HTML.

Así que se debe tener en claro la diferencia entre los lenguajes front-end y back-end. Es lo mismo aquí, y es por eso que Michael Fritzius recomienda utilizar Ruby para escribir código de automatización de prueba.

• Ruby se destaca como una herramienta especializada

Al igual que Java y Python, que tienen sus propias fortalezas y audiencias preferidas, Ruby es un lenguaje muy poderoso para usos específicos. Por ejemplo, Python es excelente para engullir cachés de datos sin clasificar y procesarlos de manera eficiente. Es por eso que es popular en entornos no estructurados como la ciencia de datos.

Por su parte, Ruby, debido a que es un lenguaje basado en matrices, funciona particularmente bien con conjuntos de datos ordenados.

¿Y sabes qué es un conjunto de datos ordenado? Una página web. Siempre hay un flujo lógico en la estructura, y siempre hay una manera de localizar lo que estás buscando.

• Ruby tiene una curva de aprendizaje corta

Los nuevos profesionales de automatización de pruebas están tratando de aprender dos cosas a la vez: qué es la automatización de pruebas y un lenguaje de secuencias de comandos. Este es un problema compuesto. Si puede eliminar algunas de las barreras, eso permitirá que los nuevos evaluadores progresen más rápido, no solo a través de la acumulación de pruebas, sino también en la escala profesional.

• Ruby permite hacer más cosas que un lenguaje compilado

Ruby tiene algunas funciones especializadas que otros lenguajes no tienen. Por ejemplo, puede hacer métodos en tiempo de ejecución. Esto es como escribir el código en sí mismo: no es necesario saberlo todo o tener todo completamente definido cuando comienza. Esto simplifica y acelera la escritura de su script de automatización de prueba.

Y, lo más importante, si intentas hacer este tipo de bootstrapping con un lenguaje compilado, inmediatamente te gritarán fuera del auditorio. Simplemente no puedes hacerlo.

• ¿Cuándo podrías considerar a Ruby?

Dos preguntas te ayudarán a decidir si debes escribir sus scripts de automatización de prueba en Ruby u otro lenguaje. El primero es sobre los desarrolladores.

¿Quién va a realizar la prueba? Si son los desarrolladores, entonces, por supuesto, permíteles escribir la automatización de prueba en el lenguaje con el que se sientan cómodos. Sin embargo, si se trata de un conjunto separado de evaluadores, entonces eres candidato para Ruby.

Y la segunda pregunta está relacionada:

¿Los evaluadores quieren aprender automatización? Si no, y si todos son buenos con las pruebas manuales, no se preocupe; No es necesario aprender Ruby, Python, Java ni nada.

Sin embargo, si los evaluadores (y su administración) están interesados ​​en acelerar el proceso de prueba a través de la automatización, entonces tiene sentido considerar a Ruby. Porque si estás en ese bote, es probable que tus evaluadores no tengan experiencia en aprender ningún idioma.

• ¿Pero la automatización de las pruebas no eliminará mi trabajo?

Algunos Tester podrían temer que agregar automatización a las pruebas significaría que ya no son necesarios. Eso puede haber sido un miedo cuando las líneas de ensamblaje se introdujeron por primera vez, pero los profesionales son parte de agregar automatización, demostrarán que son parte integral del calendario de lanzamiento.

No se eliminarán porque ayudarán a la empresa a acelerar todo, desde el alcance hasta el lanzamiento.