No se puede jugar al fútbol sin portero ?O sí?

English version below

A raíz del artículo que escribí hace unos días sobre la analogía del QA con el portero, varios colegas (creo que fueron dos y estaban juntos) me han preguntado: "?Qué opinas sobre las empresas que no tienen roles de QA? ?Sería como intentar jugar un partido de futbol sin portero?" Mi respuesta es que no, no necesariamente. En la mayoría de los casos no es que no tengan un portero, algunas organizaciones han alcanzado tal madurez en su proceso de desarrollo que ya no necesitan un QA dedicado. Generalmente es como si hubieran creado una barrera defensiva tan sólida que no hay contrincante capaz de romperla.

En estos casos, la posición de "portero" no es fija, pero sigue siendo necesaria. Es como en mi infancia, cuando jugábamos al fútbol y nadie quería ser portero porque todos pensábamos que la diversión estaba en meter goles. Para solucionarlo, adoptamos la regla de "mete-gol"(así le decíamos en mi pueblo): quien metía un gol debía jugar como portero hasta que alguien más anotara y lo relevara. En ese juego, el rol de portero era rotativo, y todos participábamos (a menos que no fueras capaz de meter un gol).

Transportando esta idea al desarrollo de software, tenemos un rol de QA que debes asumir cada vez que liberas a producción. Muchas veces, esto se traduce en pruebas automatizadas: si quieres liberar algo (meter un gol), debes asegurarte de que incluya las pruebas necesarias en el pipeline (jugar de portero). Estas pruebas permanecen vigentes hasta que alguien más necesita liberar un cambio en el mismo componente y debe actualizar las pruebas, convirtiéndose en el nuevo "portero".

Este modelo de trabajo es lo que implementan muchas empresas y, en general, promueve la agilidad. Quizás las pruebas automatizadas no logren la misma cobertura que un especialista en QA, pero en algunos sistemas no es necesario un alto nivel de cobertura para asegurar el buen funcionamiento. Incluso si eres capaz de reaccionar muy rápido puede que no te duela tanto recibir un gol si en poco tiempo eres capaz de revertir el marcador, en el software, puede que no te afecte tanto liberar un defecto si rápidamente puedes detectarlo y revertirlo o corregirlo.

Otra variante de mi infancia era el "portero ambulante". En este caso, había un jugador designado como portero, pero solo asumía su rol cuando era necesario. Pasaba la mayor parte del tiempo en el campo contrario, intentando meter goles, hasta que el rival tomaba el balón y entonces corría de vuelta a la portería. En algunas empresas, el equipo de desarrollo funciona así: todos son desarrolladores, pero cuando surge algo crítico, uno de ellos asume el rol de QA y se encarga de validarlo, generalmente desarrolla habilidades de QA más fuertes que el resto del equipo.

Finalmente, la versión más extrema del "portero ambulante" era aquella donde nadie era portero hasta que se necesitaba uno, en ese caso el que estuviera más cercano a la portería tenía que gritar "?portero!" para tener el derecho a meter las manos e intentar evitar el gol. En desarrollo de software, algunas empresas adoptan este enfoque. Un desarrollador escribe código y lo envía a la etapa de QA y cualquier otro desarrollador que esté disponible (el que esté mas cerca de la portería) asume el rol de QA para validar lo que su compa?ero hizo y evitar liberar defectos.

Nuevamente, usando la analogía del portero como el QA del equipo, la clave aquí no es dejar la portería desprotegida. No se trata de desarrollar sin preocuparse por la calidad, en realidad estas estrategias, y otras más, buscan todo lo contrario, que todo el equipo se haga responsable de la calidad de lo que liberan a producción.

Ahora, si como decía al principio, hay empresas y equipos de desarrollo que han implementado un proceso de desarrollo tan eficiente y robusto que no necesitan un QA dedicado ?Quiere decir que el rol de QA va a desaparecer? No lo creo. Al igual que en el fútbol, no es lo mismo un 4to A vs. 4to B en el torneo de los recesos de la primaria que un Manchester City vs. Real Madrid en la Champions League, quizás en el primer caso puedas darte el lujo de rotar al portero, pero estoy seguro que un Manchester City no se va a arriesgar a poner a cualquiera en la portería. A lo que voy es que, en el software, la mejor estrategia siempre va a depender del contexto y lo cierto es que ninguna empresa que viva de desarrollar software se querrá dar el lujo de ignorar la calidad, ya sea con un QA dedicado o no.

Al final del día, lo importante es, con un rol de QA o sin el, que el equipo completo asuma la responsabilidad de la calidad del software que produce.

You can’t play soccer without a goalkeeper… or can you?

Following the article I wrote a few days ago about the analogy of the QA and the goalkeeper, several colleagues (I think it was two, and they were together) asked me: "What do you think about companies that don’t have QA roles? Would it be like trying to play a soccer game without a goalkeeper?" My answer is no, not necessarily. In most cases, it's not that they don’t have a goalkeeper. Some organizations have reached such a level of maturity in their development process that they no longer need a dedicated QA. It's generally like they’ve created such a solid defensive barrier that no opponent can break through it.

In these cases, the "goalkeeper" position is not fixed but remains necessary. It's like in my childhood, when we played soccer and no one wanted to be the goalkeeper because we all thought the fun was in scoring goals. To solve this, we adopted the rule of "mete-gol" (this is how we used to call it in my hometown): whoever scored a goal had to play as goalkeeper until someone else scored and took over. In that game, the goalkeeper role was rotational, and everyone participated (unless you couldn’t manage to score a goal).

Translating this idea to software development, there is a QA role that you must take on every time you release to production. Many times, this translates into automated testing: if you want to release something (score a goal), you must ensure that it includes the necessary tests in the pipeline (play as goalkeeper). These tests remain in place until someone else needs to release a change to the same component and must update the tests, becoming the new "goalkeeper."

This working model is implemented by many companies and generally promotes agility. Perhaps automated tests don’t achieve the same coverage as a QA specialist, but in some systems, a high level of coverage isn’t necessary to ensure proper functioning. If you're able to react quickly, it might not hurt much to let in a goal if you're able to reverse the score in a short time. In software, it might not hurt to release a defect if you can quickly detect and fix it or roll it back.

Another variant from my childhood was the "roving goalkeeper." In this case, there was a designated goalkeeper, but they only assumed the role when needed. Most of the time, they played in the opponent’s half, trying to score goals, until the opponent got the ball and then they would rush back to the goal. In some companies, the development team works this way: everyone is a developer, but when something critical arises, one of them takes on the role of QA and handles validation, usually developing stronger QA skills than the rest of the team.

Finally, the most extreme version of the "roving goalkeeper" was when no one was the goalkeeper until needed. In that case, whoever was closest to the goal would have to shout "goalkeeper!" to get the right to use their hands and try to stop the goal. In software development, some companies adopt this approach. A developer writes code, sends it to the QA stage, and whichever developer is available (the one closest to the goal) takes on the QA role to validate what their teammate has done and prevent defects from being released.

Again, using the analogy of the goalkeeper as the QA of the team, the key here isn’t to leave the goal unprotected. It’s not about developing without worrying about quality. In fact, these strategies, and others, aim for the opposite: that the entire team takes responsibility for the quality of what they release to production.

Now, as I mentioned at the beginning, there are companies and development teams that have implemented such an efficient and robust development process that they no longer need a dedicated QA. Does this mean that the QA role is going to disappear? I don’t think so. Just like in soccer, a 4th grade A vs. 4th grade B recess match is not the same as Manchester City vs. Real Madrid in the Champions League. In the first case, you might be able to rotate the goalkeeper, but I’m sure Manchester City wouldn’t risk putting just anyone in goal. What I’m getting at is that in software, the best strategy will always depend on the context, and no company that relies on software development will want to take the risk of ignoring quality, whether with a dedicated QA or not.

At the end of the day, what matters, with or without a QA role, is that the entire team takes responsibility for the quality of the software they produce.