El testing como ciudadano de primera

Sin duda Agile, y más específicamente XP, hicieron esto, pero no fueron los únicos.

En la época «pre-agile«, el testing estaba en manos de un grupo de personas «externas» al equipo de desarrollo. Agile cambio esto en varios sentidos, por un lado puso de relieve el testing como un trabajo de todos y junto con eso puso gran parte del testing en manos de los developers. Al mismo tiempo puso a los testers a trabajar codo a codo con los developers dentro del equipo de desarrollo y a la pasada cambió las tareas cotidiadas de los testers incluyéndolos en otras cuestiones como ser las plannings y los refinamientos, etc. Hasta aquí creo que no hay novedad, cualquier practicante en la actualidad sabe esto (consciente o inconscientemente).

Pero hay otro hecho que me parece ha pasado desapercibido. Resulta que estoy ayudando a un equipo de un cliente a mejorar su proceso de delivery y en ese contexto estamos agregando tests automatizados, cosa que el equipo nunca hizo. Su solución consiste en una aplicación móvil construida con Ionic y un conjunto de servicios construidos con node/loopback. Personalmente había hecho algunas cosillas con Ionic pero nunca había trabajado con Loopback. Para mi sorpresa, ambos framework traen soporte (guias, ejemplos, etc) para hacer pruebas automatizadas de distinto tipo. Más aún, el scaffolding de Ionic ya genera el esqueleto de pruebas cuando uno genera un componente. Esta sorpresa me hizo caer en la cuenta que hoy en día la gran mayoría de los frameworks de desarrollo ya traen soporte, documentación y ejemplos para hacer pruebas automatizadas. Esto que puede parecer «normal» en la actualidad pero creanme que no era así hace ~20 años cuando yo empezaba a dar mis primeros pasos con automatización de pruebas. Recuerdo varios proyectos lidiando para agregar pruebas a aplicaciones AspNet/C#.

Creo que unas de las herramientas pioneras en este sentido fue Smalltalk (¿squeak?) y luego Rails. Me parece que hoy en día todo frameworks/sdk viene con soporte para hacer pruebas automatizadas: Rails, Django, Java/Spring, NetCore, Nest.js, Next.Js, Android Sdk, por nombrar algunos populares. Es cierto que tal vez no todos los developers escriben pruebas, pero el hecho que las herramientas los habiliten representa una posición de la industria: los developers deben escribir pruebas y es de esta forma el testing se ha convertido en un ciudadano de primera categoría.

Pipelines en Testearla

El próximo mes de septiembre estaré participando en la conferencia Testearla organizada por la gente de Crowdar (JaviRe y sus colegas).

La conferencia será 9 y 10 de septiembre, el 9 online y el 10 presencial en Plaza Galicia (Ciudad de Buenos Aires). La entrada es gratuita pero requiere registración. Al margen de la agenda de sesiones, que se ve muy interesante, en el evento también habrá espacios de networking.

Adicionalmente, el 11 habrá una jornada intensiva de entrenamiento de la cual estaré participando. Habrá 4 sesiones y yo daré una de ellas. Mi sesión será «Principios y Patrones para el diseño de Pipelines», veremos la teoría y la pondremos en práctica con algunas herramientas. Será la primera vez que dicte este sesión, pues si bien parte del contenido suelo darlo en mi materia de Ingeniería de Software, para este caso agregaré algunas cuestiones nuevas surgidas de mis últimas experiencias. Esta jornada de entrenamiento tiene cupos limitados y es paga.

¡Nos vemos en Testearla!

Ingeniería de Software: de Ruby a TypeScript

Desde hace varios años en mi curso de Ingeniería de Software @ UNTreF venimos usando Ruby como lenguaje de programación. Una elección con la que estábamos muy conformes. Pero el cambio de plan de estudio del año pasado, cambió radicalmente el perfil de nuestros alumnos y ello nos llevó a replantear varias cuestiones de la forma en que dictamos la materia. Entre ellas el lenguaje de programación.

Dado el perfil de los alumnos pensamos que trabajar con un lenguaje de tipado estático podía resultar más conveniente para explicar algunas cuestiones (cuestiones que previamente no teníamos que explicar porque las estudiaban en materias anteriores). Inicialmente consideramos C# pero luego de algunas pruebas decidimos descartarlo. Finalmente la semana pasada decidimos ir con TypeScript. Yo vengo de armar un programa de entrenamiento para pasantes en uno de mis clientes y considero que TypeScript dió muy buen resultado. Mis colegas estuvieron de acuerdo así que ahí vamos.

Complementando TypeScript el stack de desarrollo que vamos usar está conformado por VScode + yarn + eslint + jest + cucumber + express (nada muy novedoso).

En un par de semanas les cuento que tal nos va.

Proyecto nuevo, código viejo

La semana pasada comencé a trabajar en un proyecto nuevo. El objetivo es hacer un «refactor» de un sistema que tiene varios años de vida y al mismo tiempo agregarle algunas capacidades nuevas basadas en IA. El sistema consta de 1 componente central construido en javascript, dos «satelites» en php y varias APIs externas algunas bajo el control de otros equipos de la misma organización y otras bajo el control de otras organizaciones.

En el equipo somos unas 10 personas: un Product Owner, cuatro devs todo terreno con dedicación full time, un dev referente técnico con dedicación parcial, un tester full-time, una persona de UX, un persona de infra con dedicación on-demand y yo con dedicación parcial en el rol de coach dev. Los miembros del equipo vienen de trabajar en distintos equipos de la organización y nunca trabajaron todos juntos como equipo.

El proyecto debería durar aproximadamente unos 3 meses.

Estamos haciendo iteraciones semanales con todas las ceremonias (review-retro-planning) de corrido los días miércoles. Estamos haciendo dailies que logramos mantener ~10 minutos.

En la primera iteración no hicimos una estimación formal, simplemente agarramos un conjunto de 17 ítems que consideramos podrían llegar a completarse en 1 semana (spoiler: a los dos días ya no dimos cuenta que llegamos a completar todo, ja!).

Continuará…