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.
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
4 Comentarios
Creo que siempre dependerá del proyecto pero un mix entre las dos opciones es el que te permite más flexibilidad.
ResponderBorrarSaludos y muy buenos los temas propuestos
Un punto muy a tener en cuenta: Las necesidades del proyecto. A veces, es todo lo que hace falta. Gracias por compartir tu opinión!
BorrarAunque salgan mil programas que no requieran codear, el Tester que automatiza debería saber cómo funcionan detrás de cámara.
ResponderBorrarSi quiere mantener su perfil al día y no cerrarse a propuestas laborales, definitivamente tiene que saber no una, sino varias maneras de hacer las cosas para tener esa flexibilidad!
Borrar