De repente, apareció un Quality Engineer

Este artículo está inspirado en “Suddenly, a wild tester appeared – A developer’s guide to caring for software testers” publicado en Ministry of Testing. No es una traducción ni un resumen: es una reinterpretación desde mi experiencia, mi idioma y mi forma de ver los equipos.

Hace poco vi circular ese artículo con un título que me encanta por lo gráfico. Es simpático, sí, pero también bastante certero: muchas veces el tester aparece de golpe en el radar del equipo, como una criatura inesperada que nadie sabe muy bien cómo tratar.

Hoy quiero contar una versión parecida, pero desde mi experiencia y con algunas verdades incómodas arriba de la mesa.

Y aclaremos algo desde el principio: a mí me resulta más útil hablar de Quality Engineers que de testers.

No porque el nombre sea más cool, sino porque cambia el foco. El problema es que muchas veces ese cambio de nombre viene con una suposición implícita:

“Ah, entonces codea.”

Y no. No necesariamente.

Hablo desde un lugar particular

Yo estuve (y estoy) de los dos lados del mostrador.

Soy developer que hace testing.
Soy tester que hace development.

Eso me pone en una posición bastante privilegiada para ver las fricciones, los malentendidos y, sobre todo, las oportunidades perdidas. Me hace empatizar con ambos y querer cachetearlos por igual cuando hacen las cosas mal.

Porque cuando pasás por ambos roles, entendés algo clave:

la calidad no es una fase, ni una persona, ni un ticket que se tira por arriba del tapial.

Es una responsabilidad compartida, incómoda y muy, muy humana.

Cómo funciona (más o menos) la cabeza de alguien de calidad

Las personas que trabajan en calidad suelen ser curiosas, detallistas y bastante "molestas" para el status quo.

Preguntan cosas que nadie quiere preguntar.
Ven casos edge donde otros ven solo el happy path.
Insisten con escenarios que “seguro no pasan”.

Y sí, a veces pueden parecer intensas, dramáticas o rompebolas. Pero no porque quieran molestar, sino porque su trabajo es pensar en lo que puede salir mal cuando todos los demás están concentrados en que funcione.

Si tenés a alguien de calidad con espacio para hablar, foco y cierta seguridad psicológica, pasan cosas interesantes:

• Mejores conversaciones sobre riesgos

• Más claridad sobre requisitos y criterios de aceptación

• Menos sorpresas tarde

• Decisiones más conscientes

Algo que siempre digo a mis equipos para generar bardo hacerlos pensar es:

A un desarrollador le tirás medio problema y lo resuelve de taquito. El tema es que...no sabe que está resolviendo medio problema. Porque su cabeza hace un excelente trabajo en abstraer para poder construir.

El tester...el tester es el que piensa en esa otra mitad.

El silencio no siempre es buena señal

Algo que vi repetirse mucho en equipos es esto:

“El tester es callado.”

Muchas veces no es timidez.
Es desgaste. Están absoluta y totalmente hartos.

Cuando sistemáticamente:

• No los invitan a las conversaciones importantes

• No se enteran de los cambios por tickets sin contexto

• Sus observaciones se ignoran

…llega un punto en el que hablar deja de valer la pena.

Y ahí aparece el silencio defensivo: hacer lo mínimo necesario para no exponerse más.

No porque no importe la calidad, sino porque nadie pelea todas las batallas.

Me pasó hace poco de trabajar con un tester con, fuera de joda, más de 30 años en el lugar. Conocía todo como la palma de su mano. Ahora...no sabía automation ni codear.

Entonces cada vez que el tipo tiraba algo que pensaba que iba a salir mal, todo el mundo se lo sacaba de encima diciendo "ahh...este boludo otra vez diciendo estas cosas jejeje".

Después producción explotaba.

El tester tratado como un nene al que hay que entretener

Esto es incómodo, pero real.

Vi muchas veces cómo al tester que no codea se lo infantiliza:

“Démosle esto para que pruebe”
“Que juegue un rato con la feature”
“Después vemos qué nos dice”

Como si fuera tirarle cosas para que se mantenga ocupado y piense que está trabajando, mientras las decisiones reales ya se tomaron en otro lado.

No siempre hay mala intención. A veces es ignorancia, a veces comodidad. Pero el resultado es el mismo: impacto desperdiciado y que el tester se sienta alguien inútil.

Qué cambia cuando hablás de igual a igual

En los equipos donde mejor me fue (y donde vi mejores resultados) pasó algo bastante simple:

Tenía conversaciones de igual a igual.

No conversaciones de “pasame los bugs”, sino:

• Conversaciones técnicas

• Conversaciones sobre diseño

• Conversaciones sobre riesgos

• Conversaciones sobre por qué algo se hace así

Ayudé con tareas de desarrollo.
Participé en discusiones de arquitectura.
Colaboré en escribir mejores unit tests.

Y algo interesante empezó a pasar:

El tester dejó de ser “el que encuentra errores” y pasó a ser alguien que eleva la calidad antes de que el error exista.

Sí, esto genera presión (y está bien)

Este tipo de dinámica también genera presión.

Presión para que el tester aprenda.
Presión para entender mejor el sistema.
Presión para que el tester mejore habilidades técnicas.

Si sos un tester leyendo esta guía, no te estoy castigando. Te estoy invitando a que mejores. Por tu propio bien.

Y ojo: no estoy diciendo que todos tengan que convertirse en developers full‑time.

Estoy diciendo que para que la dinámica cambie, todos tienen que poner algo:

• El developer tiene que abrir el juego

• El Quality Engineer tiene que animarse a meterse

• El equipo tiene que dejar de pensar en roles como compartimentos estancos

Frases que dicen mucho y que pueden caer MAL

“El tester todavía no es necesario.”
¿Según quién? La mayoría de las veces, cuanto antes participe alguien de calidad, mejor. No seas gato y meté a tus testers lo antes posible en la conversación

“Funciona en mi máquina.”
Felicitaciones. Te transformaste en uno de los memes más populares de testing. Ahora sentémonos a entender por qué no funciona en otro lado.

“Esto es muy técnico, no te preocupes.”
Mala idea. No subestimes el conocimiento técnico de alguien solo porque no codea. Peor...no pienses que porque es un tester, no lo va a entender. Conozco muchos testers que entienden mejor el código que los propios desarrolladores.

“Tirá el ticket y que lo prueben.”
Eso no es trabajo en equipo. Es delegar sin contexto. Es una forrada.

“Sin vos estaríamos perdidos.”
Agradece, sí. Pero mejor todavía: involucrá antes. Estoy super en contra de esos mensajes condescendientes. Al menos yo los veo así. Onda..."ahh, AHORA SI SENTIMOS QUE HICISTE ALGO UTIL" y flores. Dejame de joder. Valorá siempre.

Quality Engineer no es tester con branding nuevo

Cambiar el título no alcanza. Lo vi de primera mano. El tipo que mencionaba arriba, ese que tenía mil años de experiencia ahí...era llamado Quality Engineer. A nadie le importaba.

Si a la persona de calidad:

• Se la involucra tarde

• No se la escucha

• No se la invita a pensar

…el nombre vale lo mismo que nada.

La diferencia real aparece cuando:

• Se la trata como par técnico

• Se valoran sus preguntas incómodas

• Se entiende que calidad también es diseño, prevención y criterio

Para cerrar

Si sos developer: hablá más con la persona de calidad. No para explicarle cosas, sino para pensarlas juntos.

Si sos tester o Quality Engineer: no esperes permiso eterno para involucrarte. La incomodidad inicial suele ser la puerta a un impacto mucho mayor.

Y si sos parte de un equipo: acordate de esto:

la calidad no aparece al final. Aparece cuando dejamos de tratarnos como roles y empezamos a tratarnos como profesionales que quieren hacer software mejor.

¿Suena goma? Si. ¿Es cliché? También. Pero eso no lo hace menos cierto.

Compartí esta guía con tus compañeros developers y cebale unos mates 🧉 mientras la lee.