Role Smell: Test Automation Engineer

Este es un rol viene ganando cada vez más popularidad desde el auge de DevOps. Ocurre que en muchas organizaciones el testing lo realiza gente que no sabe programar y por ende no puede automatizar los tests que realizan (en realidad es posible utilizar herramientas del tipo record & play, pero en general esa estrategia tiene muchas limitaciones).

En un par ocasiones trabajé con equipos donde había gente en este rol y sinceramente no me pareció una buena idea. En todos los casos la dinámica de trabajo era:

  • en primera instancia un tester (o varios) definía los casos de prueba y los ejecutaba manualmente
  • luego, generalmente en la siguiente iteración, un automatizador (test automation engineer) se encargaba de automatizar algunos de los casos de prueba previamente definidos

De entrada esto me hizo recordar a la época en que una persona hablaba con el usuario (analista), escribía un documento de casos de uso y luego otra persona (desarrollador) leía el documento y programaba la funcionalidad. Si bien aún hoy hay equipos trabajando de esta forma creo que son minoría. Por algo será.

Otra cuestión que me resultaba poderosamente llamativa era la desconexión total entre estos automatizadores y los desarrolladores.

También ocurría que si en una determinada iteración no había trabajo de automatización, esos automatizadores, a pesar de saber programar, no se ponían a programar la aplicación.

Finalmente lo que para mí resultaba más perjudicial: toda la automatización de pruebas quedaba en manos de estos automatizadores, o sea: los desarrolladores no escribían ningún tipo de prueba automatizada, ni siquiera unitarias. Es bien sabido que para tener un buen flujo de entrega continua es necesario tener pruebas automatizadas, pero también es necesario que parte de ese trabajo de automatización lo hagan los propios desarrolladores comenzando por las pruebas unitarias.

En fin, no digo que tener un rol de Test Automation Engineering sea algo malo ni incorrecto. Solo digo que las dinámicas de trabajo que he visto en equipos que tienen personas en dicho rol, no generan un buen flujo de entrega continua. No digo que siempre sea así, pero sí lo fue en los casos que vi de cerca. Dicho esto, mi recomendación es que si tienes en tu equipo una persona en este rol o estás pensando en incorporarla, tal vez deberías detenerte un momento a pensar en la dinámica de trabajo del equipo.

De feature-branches y Pull-Request a Continuous Delivery

El uso de feature branches en conjunto con pull-request es una práctica muy habitual en la actualidad, a pesar de que en general termina siendo un impedimento para implementar Continuous Delivery. Esto resulta en gran medida curioso porque mucha gente que utiliza feature branches y pull-request cree que hace Continuous Delivery.

Por definición Continuous Delivery implica Continuous Integración lo cual a su vez implica Trunk-Based Development, o sea: no hacer branches que duren más de un día. Siendo conceptualmente estrictos uno podría hacer feature-branches & pull-request y aún así hacer Continuous Delivery, pero entonces los branches y pull-request no deberían extenderse más de un 1 día, situación que no condice con lo que suele verse en la industria mayoritariamente en la actualidad.

Desde hace varios par de meses vengo trabajando con un equipo muy maduro en un sistema que ya está productivo hace años. Trabajan con una dinámica de feature-branches, pull-requests bloqueantes y puesta en producción al final de la iteración. Dado que la iteración dura 2 semanas, esta dinámica implica que todo ítem, por simple que sea, tardar 2 semanas en llegar a producción. A su vez esto provoca que cada release a producción sea bastante grande pues contiene todo el trabajo acumulado durante 2 semanas. Y obviamente, cuanto más grande, más riesgoso. En parte como consecuencia de esto cada release a producción implica un downtime del sistema lo que obliga notificar a los usuarios sobre el tiempo de downtime y al mismo tiempo obliga que el release se realice fuera del horario de oficina para así afectar lo menos posible a los usuarios.

Dado que a mi parecer el equipo está bien consolidado, cuenta con un interesante set de pruebas automatizadas, el producto está estable, hay un proceso formal de testing y release, considero que están en condiciones de transicionar a un esquema de Continuous Delivery y por ello la semana pasada le propuse hacer un experimento. La propuesta es identificar un par de items de backlog, de bajo riesgo, para liberarlos (ponerlos en producción) tan pronto estén listos. De esta forma se entrega valor al negocio más rápidamente y al mismo tiempo el release de fin de iteración es más pequeño y menos riesgoso.

Debut en la era del podcast y de los vivos

El formato «vivo» creo que se popularizó con Twitch y digo creo porque sinceramente no es un formato que suela consumir. El formato «podcast» por su parte, ya lleva un buen tiempo en la red y si bien suelo consumir algunos podcast recién ahora pasé del otro lado para tomar el micrófono y ser protagonista.

Es que ayer salió publicado el episodio #30 del podcast Agile Latam en el cual tuve una interesante conversación sobre testing con Ettiane Salamanca de Inspirit. Pueden encontrarlo en Spotify.

Por otro lado, la semana pasada participé de mi primer vivo junto a Martin Alaimo con quien estuvimos hablando en LinkedIn sobre «Definition of Done«, lo pueden ver aquí.

Mi próxima intervención será durante julio en el podcast de otra empresa amiga.

¿Qué es la Ingeniería de Software Continua?

La ingeniería de Software «tradicional» de la que venimos hablando desde los años 60′, que está descripta en los libros clásicos de la disciplina (Presmann, Sommervielle, etc), incluso la descripta en el cuerpo de conocimiento (SWEBoK) no trata las cuestiones relacionadas a la puesta en producción y la operación. Estas cuestiones, que en los últimos 15 años han tomado cada vez más relevancia debido al rol protagónico que ha tomado en software en el negocio, han sido resueltas en los contextos industriales con un conjunto de prácticas que se han englobado bajo lo conocido DevOps y SRE.

La Ingeniería de Software Continua es el nombre «formal» que se le ha dado en la academia a la inclusión de las prácticas DevOps y SRE en la Ingeniería de Software

Dicho de otra forma y de manera simplificada podría decir:

Ingeniería de Software continua = Ingeniería de Software (tradicional) + DevOps/SRE

Sobre el monotributo tech y los empresarios

La iniciativa del monotributo tech ha recibido muchas críticas por parte de empresarios del sector de software y servicios. En cierto modo es una actitud «muy argenta» que vemos cotidianamente en el fútbol: en lugar de alentar a tu equipo, insultas a tu oponente.

Parece que algunos empresarios en lugar de preocuparse en mejorar la oferta de valor para sus empleados (y no me refiero solamente a remuneraciones), critican una medida por «miedo» a perder empleados. Dicho de otra forma, en lugar de apuntar a que los programadores elijan sus empresas por ofrecer oportunidades atractivas, apuntan a cerrarle puertas a esos programadores de forma que sus empresas sean la única opción.

Personalmente creo que el monotributo tech tiene algunos puntos flojos y varias oportunidades de mejora, pero al margen de eso me indigna la actitud de algunos empresarios.

Materia itinerante: Ingeniería de Software Continua

ingeniería de software continua

Ya voy por la tercera semana del curso de Ingeniería de Software Continua en Exactas y estoy convencido que la experiencia es complemente replicable en otras instituciones. Paso a explicar.

Esta materia la estoy dictando en calidad de Profesor Invitado, la facultad me contrata por tres meses para el dictado de la materia por única vez. La materia es ofrecida a lo alumnos como una materia optativa. El principal desafió que veía en el dictado de la materia estaba dado por el hecho de «venir de afuera» a dictar una materia sin saber el conocimiento con el que los alumnos llegarían a cursar la materia. Obviamente pude poner una restricción de correlatividades para mitigar la situación, pero esa correlatividad la determiné a partir de leer el plan de estudios. Pero muchas veces hay un gap entre lo que dice el plan en teoría y lo que encontramos en la realidad. No porque no se enseñe lo que dice el plan, sino porque en ocasiones no todo lo que el docente pretende enseñar termina siendo aprendido. A su vez los planes de estudio solo mencionan una lista de contenidos mínimos y queda a criterio de cada docente el tiempo y profundidad dedicado a cada tema.

Mi descubrimiento al cabo de estas 3 semanas de clase es que logré estructurar el curso de forma tal de bajar la dependencia con materias anteriores. Esto me lleva a intentar replicar esta experiencia de Profesor invitado en otras instituciones. A partir de esto estoy en la búsqueda de instituciones que quieran tenerme como profesor invitado para dictar el curso de Ingeniería de Software Continua. Más aún, podría dictar la materia en conjunto con un profesor de la institución de forma tal que ese profesor pueda seguir dictando la materia luego de mi visita. Mi motivación para hacer esto pasa por validar los materiales y metodología de enseñanza en diversos contextos.

Dicho todo esto, invito a aquellas instituciones que estén interesadas en hacer esta experiencia a que me contacten por aquí para ver si podemos trabajar en conjunto (y pueden ser instituciones de cualquier provincia/país). Aquí pueden ver el programa de la materia.

Charla Aceptada: Recorrida de prácticas técnicas para gente no téncnica

Desde el año pasado vengo trabajando en intentar transmitir la importancia de ciertas prácticas técnicas fundamentales para la entrega continua a aquellos que se encuentran trabajando con equipos de desarrollo de software y que no tienen un background técnico. En este sentido el año pasado diseñe un curso que ya he dictado dos veces y del cual ya tengo agendada una tercera edición.

En la misma línea del curso, envié una propuesta de charla a la conferencia internacional de Agile de la Agile Alliance. La propuesta fue aceptada y mi charla «Technical Practices Walkthrough for Non-technical People» está agendada para el jueves 27 de Julio a las 15:45. Para aquellos que asistan al evento nos vemos en Orlando y para los que no, tengo pensado hacer un Meet-up online en castellano para la comunidad hispano-parlante. Aún no tengo definida fecha ni plataforma, pero en cuanto la tenga lo publicaré aquí.

Sobre videos juegos como Trabajos finales de carrera

Más de una vez algún alumno me planteó la intención de hacer un video juego como trabajo final de carrera en FIUBA pero hasta el momento he tenido la oportunidad de dirigir solo un trabajo de este tipo. Sin embargo ese único caso, el video juego Fira de Facu Gertsner y Mati Feld, me permitió entender varias cuestiones del tema.

Hacer un juego implica al menos 3 cuestiones. En primer lugar tenemos la idea, el argumento, las reglas, en gran medida un trabajo creativo. En segundo lugar tenemos la parte artística: imágenes, sonido, animaciones, etc, lo tiene un parte creativa pero también una parte técnica. Finalmente está la programación. Podríamos ir un poco más allá y pensar en cuarta cuestión: la coordinación de tres cuestiones anteriores. La importancia y complejidad de cada una de estas cuestiones varia dependiendo del tipo de juego. Claramente la tarea de un ingeniero pasa por la programación pero también podríamos agregar la gestión.

Cuando un alumno se plantea hacer un juego como trabajo final debe considerar estas cuestiones. Asimismo, dependiendo también del tipo de juego, la programación puede no ser una tarea trivial. Otra vez dependiendo del tipo de juego puede ser necesario aprender algún lenguaje y/o framework particular y la mayor complejidad aquí no pasa por aprender el lenguaje/framework, sino por el hecho de tener que estimar y hacer un plan de trabajo sin tener un conocimiento del lenguaje/framework.

Teniendo en cuenta todo esto yo veo al menos 3 formas de plantear el trabajo final:

  1. La primera opción es tomar el paquete entero y hacer «todo», lo digo entre comillas porque la parte de artística podría hacerlo el alumno o bien la podría subcontratar pues es una cuestión que excede a lo que se espera de un estudiante de ingeniería.
  2. Una segunda opción es aprender el lenguaje/framework en la previa, o sea, dejar esa parte de investigación/aprendizaje fuera del alcance del trabajo final. En términos del esfuerzo total, la cuestión pareciera no cambiar pero hay una diferencia grande: si nos mandamos de una a hacer todo (opción 1) corremos el riesgo de armar un plan para X tiempo/esfuerzo y que luego termine llevando mucho más. En cambio, si hacemos la investigación en la previa, eso nos debería dar una mayor certeza para la planificación del proyecto disminuyendo así los riesgos de desvio.
  3. Otra opción podría ser no hacer el juego en sí, sino hacer un prototipo que si bien puede sonar a poco, puede igualmente ser un trabajo considerable si hay que aprender un framework como Unreal.

En lo personal creo que en todos los casos el alcance del trabajo debe incluir la distribución del juego, no necesariamente en un marketplace de juegos pero al menos en una página web donde resulte accesible al público en general.

Aclaro: lo que menciono aquí es una opinión personal, o sea: no es una posición oficial de la institución.

Resultado de la segunda edición del curso de Prácticas Técnicas para Scrum Masters

Hace un par de semanas completé el dictado de la segunda edición de este curso. Quedé muy conforme con los ajustes realizados luego de la primera edición y considero que el formato utilizado será el mismo en la siguiente edición: 5 encuentros de 2 horas cada uno.

En esta segundo edición, además de agregar un quinto encuentro, también agregué varias actividades para sumar así un total de 20 actividades extra clase. Según reportaron los mismos participantes, la dedicación promedio semanal fue de 3 horas lo cual hace que la dedicación total del curso ascienda a 25 horas (10 horas de encuentros online y 15 horas de actividades extra clase).

La evaluación del taller por parte de los participantes fue muy positiva.

Sin duda que hay algunas cuestiones que mejorar pero en términos generales estoy muy conforme y contento con el resultado. Comparto algunas frases que los participantes dejaron en el formulario de feedback:

«Me encantó el curso, me fue de mucha utilidad para comprender conceptos de los cuales no tenía conocimiento y que me permiten comunicarme mejor con los equipos a los que acompaño«

«Me gusto mucho el curso, la parte de devops fue la más esclarecedora junto con el mapa de las formas de quebrar o realizar slicing de una Historia de Usuario, fue excelente.«

Para aquellos interesad@s en participar de la próxima, ya tenemos fecha y está abierta la inscripción, pueden ver más info aquí.

Alternativa a Heroku: fly.io

Hace un tiempo escribí sobre Render como alternativa a Heroku. Luego de eso mi colega LucasM me recomendó probar fly.io y así lo hice.

Me gustó. Aún no termino de entender completamente cómo funcionan algunas cuestiones, lo pude hacer andar. No es que me funciona de casualidad, lo hice andar tal como indica la documentación, pero por esa «manía de control», hay algunas cuestiones «internas y/o de bajo nivel» que quisiera entender mejor.

Una condición importante que teníamos al buscar alternativas a Heroku era que la plataforma ofreciera una opción gratuita sin necesidad de poner una tarjeta de crédito. Fly.oi cumple con esto, pero hay una pequeña «trampita»: hay que crear la cuenta de fly.io asociándola a GitHub. Según entiendo esto es porque fly.io busca verificar la identidad del usuario y eso lo hace a partir de la tarjeta de crédito o bien confiando en Github. Así que si no quieren poner una tarjeta de crédito, asegurense de crear su cuenta de fly.io a partir de su cuenta de GitHub (ver imagen adjunta).

La experiencia de usuario que provee fly.io es muy similar a la de Heroku: se crea una aplicación, se la conecta con un repo y listo. No exploré si es posible disparar automáticamente un deploy ante cada commit porque no es nuestro caso de uso. Lo que hacemos es disparamos los deploy explícitamente usando la herramienta de línea de comando de fly.

Hasta donde investigué la plataforma termina corriendo un contenedor docker: si el repositorio de código fuente es de algunos de los frameworks soportados (rails, django, etc), fly genera un Dockerfile automáticamente y buildea la imagen al momento del deploy. También es posible proveer un Dockerfile propio que fly se encargará de builder, lo cual da la posibilidad de ir más allá de los frameworks/lenguajes soportados nativamente. Finalmente también es posible proveer una imagen ya buildeada.

La plataforma también provee servicio storage (basado en PostgreSQL y Redis entre otros) y la posibilidad de usar custom domains incluso en la modalidad gratuita.

A probarlo.