Hace poco escuché esto de un gran amigo, al que le tengo un gran respeto técnico. A él siempre le gustó programar, pero por cuestiones de la vida terminó en el campo de la calidad de software y el testing por dos o tres años. Ahí estuvo haciendo pruebas de performance y pruebas funcionales automatizadas. Hace unos días me confesaba que ahora que está liderando un equipo de desarrollo (ya lleva 10 años trabajando en el rubro, fuimos compañeros de facultad), siente que esos años en el área de calidad le dan una visión que lo alimentan muchísimo. En particular, él ve que si no fuese porque pasó por esas experiencias laborales hoy no le daría la importancia que le da a ciertas tareas, y es así como se pregunta cómo sería él siendo un líder sin haber pasado por ahí. Es así que yo llego a la conclusión que hoy tenemos muchos líderes de equipos, que no estudiaron ni siquiera en su carrera la importancia del testing y el control de calidad, y no tuvieron el aprendizaje en su trabajo tampoco, entonces seguimos propagando algunas formas de trabajo que no son las más adecuadas. Quiero creer que esto es cada vez menos común, pero se sigue viendo.
Gracias a esta experiencia, mi amigo llegó a impulsar dentro de su equipo una serie de acuerdos, que según me contaba, los desarrolladores más juniors al comienzo no estaban muy conformes, pero luego le fueron viendo valor y al cabo de dos o tres meses (solamente) se ven todos muy convencidos y contentos con la forma de trabajo. Esto incluye:
- Integración continua.
- Pruebas unitarias, cobertura de branches al 80%.
- Revisión de código por pares.
- Verificación automática de calidad de código.
- Pruebas funcionales y de performance automatizadas.
Cosas básicas para impulsar la calidad de cualquier desarrollo.
