Debate: Programar desde cero o cortar camino para automatizar?

Hace unos días estaba analizando distintas opciones para hacer un framework base para que otros reutilizaran en una empresa. El mismo tenía que contar con Cucumber y apuntar solamente a testing de webservices (SOAP y RESTful APIs). Lo primero que piensa uno en este caso es: Bueno, sumado al reporting de Cucumber, el runner y el manejo de testdata con REST Assured cerramos el círculo.

Es lo normal, cierto? Una instancia estática del request, llamarlo para armar la validación de la respuesta en otro paso...un lujo. Después me acordé que el nivel técnico muchas veces es un tema, y que, si podía simplificarles el uso, lo iba a hacer. Así llegué a Karate, del cuál no voy a hablar ahora (eso va a ir a los tutoriales, cuyo link pueden encontrar arriba a la derecha!), pero para simplificar voy a decirles que lo que hace es darte steps para hacer el .feature ya listos, sin que tengas que definirlos vos. En definitiva: No hace falta programar.

Dependiendo de demasiadas dependencias...

Esto me llevó a un debate en el proyecto: Qué pasa cuando escondemos la complejidad del código al usuario final? Es lo que, en definitiva, hace un programador, cierto? Te da un software que no requiere que vos escribas código para hacer lo que querés hacer. En Testing se está dando mucho esto, con casos como el de Katalon Studio, Karate, el resurgimiento de entre los muertos de Selenium IDE y otros casos. Todos apuntan a que "no programes".

Uno de los aspectos negativos que planteé fue: Hoy ese framework que te ahorra codear está de moda y es gratis...qué pasa cuando en unos años no tenga más mantenimiento y quede obsoleto porque salió otro más lindo? Qué hacés con esa dependencia que usaste hasta en la sopa en tu empresa? Y si deciden que el framework era demasiado lindo para ser gratis y lo pasan a un modelo por suscripción?

De ahí la importancia del Test Engineer para la solución holística: Poder hacer las cosas desde cero. Saber ser flexible ante la complejidad técnica escondida detrás es fundamental para no quedar tan obsoletos como el programa/dependencia/framework que se quedó en el camino.

También es cierto, y más hoy en día, que el software pide más rapidez a la hora de testear. En ese caso, tomar algo que funciona ya de entrada sin tener que lidiar con atar todos los cables, puede ser un punto tan a favor que contrarreste la posible debacle futura. Sin ir más lejos, el futuro es incierto y esto te está solucionando un problema que tenés ahora: Poder responder al ritmo de desarrollo como equipo de testing.

Un tema con muchos matices y opiniones para debatir, sin dudas. Por mi parte, siempre me gusta ver con qué nueva idea surgen estos frameworks, pero también me gusta hacerlos de cero yo. Otro punto a favor de saber la parte técnica es que muchas de estas panaceas de la automatización son conscientes de sus límites y ofrecen la posibilidad de arremangarse y programar lo que no te ofrecen, lo cuál siempre es algo bienvenido.

Y ustedes qué opinan? En sus trabajos usan soluciones hechas en la misma empresa o están atados a muchas dependencias? Dejen su comentario abajo!

The Free Range Tester