El portero en el desarrollo de software

A lo largo de mi carrera en el área de calidad de software he llegado a usar muchas veces la analogía del rol de un QA Engineer con la posición de un portero en un equipo de fútbol. Me gusta mucho ésta analogía dado que, aunque ambos forman parte del mismo equipo, sus responsabilidades y su manera de jugar es muy distinta a las del resto del equipo.

El portero, al igual que el QA Engineer, tiene la tarea de evitar que algo negativo ocurra. En el caso del portero, es evitar que el balón entre en la portería; en el caso del QA Engineer, es prevenir que los bugs lleguen a producción. Pero, ¿qué sucede cuando el portero se convierte en el protagonista del partido?

Cuando un portero es el héroe porque detiene muchos tiros hay un claro indicador de que el equipo está jugando mal, la defensa no está cumpliendo con su trabajo y el portero se ve obligado a salvar al equipo una y otra vez. Generalmente este escenario es insostenible, eventualmente el portero se cansará, cometerá un error y el equipo recibirá un gol. Si ése, o esos goles recibidos en dicho caso, se vuelven críticos y se llega a perder el partido será muy tentador culpar al portero, pero la verdadera pregunta es: ¿por qué el equipo permitió que llegaran tantos tiros a su portería?

Trasladando éste escenario al mundo del desarrollo de software, cuando un QA Engineer está constantemente encontrando defectos y se convierte en el héroe del equipo a menudo es un indicador de que el proceso de desarrollo necesita atención, el equipo está dejando pasar demasiados errores y, al igual que con el portero, el QA Engineer no puede atraparlo todo, tarde o temprano algo se pasará por alto y un bug llegará a producción, pero no sería justo culpar únicamente al QA Engineer, en su lugar deberíamos mirar cómo está funcionando el equipo en su conjunto.

En el fútbol el escenario ideal es que el portero no sea el centro de atención, de hecho, es mejor si apenas se nota su presencia durante todo el partido, pero aun así, ningún equipo se atrevería a jugar sin un portero, es más, seguramente todos los equipos buscan tener al mejor portero de la liga, incluso si no tiene que hacer una sola atajada en toda la temporada. De manera similar, en el desarrollo de software, lo que quieres es que a tu QA Engineer le cueste mucho trabajo encontrar bugs, porque significaría que el proceso de desarrollo es tan sólido que es muy difícil que algo se escape hasta el QA, pero aun así, siempre quieres tener al mejor QA Engineer en tu equipo listo para intervenir cuando sea necesario.

La tarea de un Líder de QA es crear un entorno donde el QA Engineer no sea necesario, lo que significaría que los procesos de desarrollo son tan sólidos que no permiten que los errores lleguen hasta QA. A la par, el líder de QA deberá preocuparse por desarrollar al mejor QA de la industria para su equipo, porque la realidad es que el software, al igual que el fútbol, lo hacemos los humanos y, cómo comúnmente se dice, es de humanos equivocarse.

The goalkeeper in software development

Throughout my career in the field of software quality, I've often used the analogy of a QA Engineer's role to that of a goalkeeper in a soccer team. I like this analogy because, although both are part of the same team, their responsibilities and ways of playing are very different from the rest of the team.

The goalkeeper, like the QA Engineer, has the task of preventing something negative from happening. In the case of the goalkeeper, it's to stop the ball from entering the goal; in the case of the QA Engineer, it's to prevent bugs from reaching production. But what happens when the goalkeeper becomes the star of the match?

When a goalkeeper is the hero because he makes many saves, it's a clear indicator that the team is playing poorly; the defense isn't doing its job, and the goalkeeper is forced to save the team repeatedly. Generally, this scenario is not sustainable; eventually, the goalkeeper will get tired, make a mistake, and the team will concede a goal. If that goal, or those goals, turn out to be critical and the team loses the match, it may be tempting to blame the goalkeeper. But the real question would be: why did the team allow so many shots on goal in the first place?

Translating this scenario to the world of software development, when a QA Engineer is constantly finding defects and becomes the team's hero, it often indicates that the development process needs attention. The team is letting too many errors slip through, and just like the goalkeeper, the QA Engineer can't catch everything. Sooner or later, something will be overlooked and a bug will make it to production. But it wouldn't be fair to solely blame the QA Engineer; instead, we should examine how the entire team is functioning.

In football, the ideal scenario is for the goalkeeper not to be the center of attention; in fact, it's better if his presence is barely noticed throughout the entire match. But even so, no team would dare to play without a goalkeeper. Moreover, every team would likely want to have the best goalkeeper in the league, even if he doesn't have to make a single save all season. Similarly, in software development, what you want is for your QA Engineer to have a hard time finding bugs because that would mean the development process is so solid that very little slips through to QA. But even so, you always want to have the best QA Engineer on your team, ready to step in when needed.

The role of a QA Leader is to create an environment where the QA Engineer isn't needed, which would mean the development processes are so solid that errors don't reach QA. At the same time, the QA Leader must focus on developing the best QA in the industry for their team because the reality is that software, like football, is made by humans, and as the saying goes, to err is human.