¿Qué hacer respecto al gap entre Testers y Developers?

Son las 8 de la mañana, recién llego a la oficina. Está diluviando afuera, hace frío y...bueno, en general es medio un bajón de día. Debería ser ilegal que los Lunes llueva.

Pero ahí llega uno de los developers de mi equipo. Un Rumano de más o menos mi edad que está siempre con la energía pum para arriba. ¿Cómo hace? Por ahí son las ingentes cantidades de cafeína que mete en su cuerpo. Así que, para comprobar la teoría, decidimos ir al café justo en frente de la oficina para buscar el primer long black del día.

En el camino me comenta que justo antes de terminar el día anterior, dejó un Pull Request para revisar. Estamos intentando aumentar el Coverage de Unit Testing y le gustaría que lo revise. Una de las ventajas de ir al café este (Coffix en Wellington por si te curiosidad) a las 8.30 de la matina es que todavía no se atiborró de gente y la espera es mínima.

Volvemos con el oscuro líquido a temperatura de mil grados mínimo. Me siento, reviso el Pull Request, dejo unos comentarios, los comento con él, hace push a un par de cambios, estamos listos para hacer un merge.

Otras formas en las que colaboramos Testers y Developers son crear branch del branch de la historia siendo desarrollada y crear el PR contra esa rama que a su vez después va con su PR al master, definir juntos los scenarios, qué incluir en el pipeline, ayudar trackeando logs en AWS...

El primer problema: Los silos

Va a haber veces en las que el equipo de desarrollo levanta una muralla. A veces es porque el equipo entero es de otra empresa, haciendo outsourcing, y medio que son muy celosos de su trabajo por un tema de proteger la imagen. Otras veces va a ser porque no consideran importante a testing.

Lo importante es poder tender ese puente en el que les facilitás la vida. No estás ahí para romper, sino para asegurar que no se vayan de viaje con una rueda pinchada.

Participar en las ceremonias (cuando tienen sentido obvio), ayudar en el refinamiento de las historias...hay BOCHA de cosas que los testers pueden aportar para que el trabajo del Developer sea menos tedioso.

El segundo problema: El (no) conocimiento técnico de los testers.

Todo bien conque todos somos testers y no debería haber segregación por no saber cosas técnicas pero...trabajamos en una industria técnica. Tenés que saber de código. Muchas veces el gap es porque simplemente no se está hablando el mismo idioma. Llegado un punto, el developer ya ni quiere perder tiempo tratando de explicar algo que el tester no va a entender.

Fórmense, hablen el mismo idioma. Cuando estás recomendando extensiones de VSCode y corrigiendo Pull Requests no hay más separación, todos son ingenieros de software.

El tercer problema: La palabrita Testing

Hay proyectos, empresas, individuos que tienen esta manía de fomentar una cultura de responsabilidad dividida. "Dice Testing...así que solo tiene sentido que los testers hagan UNIT TESTING". O...eso es culpa de "Testing! Ellos tenían que encontrar el defecto!".

La calidad es responsabilidad de todos chiquis, que no se nos olvide. Colaboren con las pruebas que hacen los devs, con la orquestación de pipelines, con sus propias pruebas automatizadas de integración y E2E...así fomentamos una cultura de responsabilidad compartida.

El cuarto problema: Automation vs Testing manual

Ok, si me seguís hace tiempo sabrás que este problema me crispa particularmente. Y está muy relacionado con el segundo problema. Pero encima a eso se le suma que, por un lado, los propios testers que automatizan se sienten en la posición de "discriminar" a los que no, mientras que los que muchas veces generan toda una personalidad alrededor del hecho de que son "Testers manuales".

Que testing manual es un cuello de botella, que automation los va a reemplazar...todo eso es motivo de mil discusiones online! La verdad? Un automation tiene que ser un tester manual también, y un manual, en mi opinión...hoy ya debería ser automation también. El flujo de trabajo debería ser siempre explorar la funcionalidad, el sistema manualmente, con pensamiento crítico y curiosidad humana, para de ahí saber definir qué flujos de usuario automatizar, que pruebas de integration hacer, qué Unit Tests debería haber...

Y ustedes, ¿qué opinan? ¿Agregarían algo?