Mi querido amigo y amiga de la calidad,
en la primera parte de esta serie te conté los primeros cinco errores: los que tenían que ver con entender los límites entre QA y desarrollo, el propósito de cada tipo de prueba, y el rol de liderazgo que muchas veces no vemos venir. Hoy quiero cerrar la lista con los últimos cinco, y estos tienen algo en común: todos tienen que ver con trabajar con otras personas, no solo con el código.
Si el primer bloque fue sobre entender el “qué” de las pruebas, este bloque es sobre el “cómo” trabajar con un equipo alrededor de esas pruebas. Vamos con ellos.
Error 6: No saber qué comunicar, ni cómo priorizar la información que le daba al equipo
Este error es más silencioso que los anteriores, pero igual de costoso. Al inicio yo reportaba todo con el mismo nivel de urgencia: un bug crítico y un detalle cosmético llegaban al equipo con el mismo tono. No porque no supiera diferenciarlos técnicamente, sino porque no sabía cómo comunicar esa diferencia de forma que el equipo entendiera qué necesitaba atención ya, y qué podía esperar.
¿Cuántas veces te ha pasado que reportas algo importante, pero se pierde entre diez mensajes más de cosas que en realidad no eran tan urgentes? A mí me pasó muchas veces, y el problema no era la cantidad de información, sino que no sabía filtrarla antes de compartirla. Aprender a comunicar no es solo aprender a redactar un buen reporte de bug — es aprender a leer qué necesita saber cada persona del equipo, y en qué momento lo necesita saber.
Error 7: Creer que yo solo podía (o debía) decidir qué era prioritario
Durante un tiempo asumí que, como QA, la decisión de qué bug se arreglaba primero era mía. Al final yo era quien encontraba los problemas, así que suponía que también me tocaba decidir su importancia. ¡Gran error!.
La realidad es que priorizar no es una decisión que le corresponde a una sola persona, y mucho menos en solitario. Cuando empecé a llevar los hallazgos al equipo como una conversación — “esto encontré, esto es lo que creo que implica, ¿cómo lo vemos?” — en lugar de una sentencia ya decidida, todo cambió. Llegar a acuerdos con el equipo sobre qué se soluciona y qué se acepta como riesgo conocido, fue una de las habilidades que más me costó aprender, y a la vez una de las que más impacto tuvo en cómo me percibían como profesional.
Error 8: No tener una visión completa a la hora de planificar las pruebas
Este es, probablemente, uno de los errores más comunes que veo todavía en QAs con los que trabajo. Y lo entiendo perfectamente, porque a mí me costó muchísimo. Planificar pruebas no es simplemente hacer una lista de “cosas que hay que probar” — es tener una visión completa de qué escenarios importan más, cuáles se pueden agrupar, cuáles dependen de otros, y cuáles se pueden dejar fuera sin que eso represente un riesgo real.
Al inicio yo planificaba pensando en cubrir “todo lo que se me ocurriera,” sin ningún criterio detrás. El resultado eran planes de prueba larguísimos, pero con huecos enormes en las áreas que realmente importaban. Aprender a planificar de verdad significó aprender a hacerme las preguntas correctas antes de escribir el plan: ¿qué es lo que más le importa al negocio en esta funcionalidad? ¿Qué es lo que, si falla, tiene el impacto más grande? ¿Qué puedo agrupar en un mismo escenario para no repetir esfuerzo? Esa disciplina de preguntar antes de escribir es lo que separa un plan de pruebas útil de una lista larga que nadie termina de ejecutar.
Error 9: Pensar que más pruebas siempre significaban más calidad
Este lo agrego porque lo he visto una y otra vez, y yo mismo caí en él. Durante un tiempo medía mi trabajo por la cantidad: cuántos casos de prueba escribía, cuántos bugs reportaba, qué tan alto era mi porcentaje de cobertura. Sentía que entre más pruebas tuviera, más “seguro” estaba el producto.
Pero la calidad no se mide en cantidad, se mide en qué tan bien esas pruebas cubren el riesgo real. Puedes tener cien casos de prueba que no cubren el escenario que realmente le va a doler al usuario, o puedes tener veinte casos bien pensados que cubren exactamente lo que importa. Entender esto me obligó a dejar de perseguir números, y a empezar a perseguir cobertura de riesgo.
Error 10: No poner límites cuando me pedían reducir el tiempo de pruebas sin explicar el riesgo
Este último es uno que me costó mucho aceptar, porque tiene que ver con algo incómodo: aprender a decir que no, o al menos a decir “sí, pero con estas condiciones.” Al inicio, cuando el equipo tenía presión de tiempo y me pedían recortar pruebas, yo simplemente aceptaba, sin explicar qué implicaba ese recorte.
Lo que aprendí con el tiempo es que mi trabajo no es solo ejecutar lo que me piden, sino hacer visible el riesgo que se asume cuando se toma esa decisión. No se trata de negarme a recortar tiempo — a veces es una decisión de negocio completamente válida — sino de asegurarme de que quien toma esa decisión la tome sabiendo exactamente qué está dejando sin cubrir. Esa transparencia cambió por completo cómo el equipo confiaba en mi criterio.
Con esto cerramos la lista completa de los 10 errores. Si me preguntas cuál fue el hilo conductor de todos ellos, creo que es este: casi ningún error grande que cometí fue puramente técnico. Los técnicos se corrigen con estudio y práctica. Los que de verdad me formaron como profesional tuvieron que ver con cómo trabajaba con otras personas.
¿Y tú, mi querido amigo y amiga de la calidad? De estos diez errores, ¿cuál fue el que más te costó superar? ¿O hay uno que viviste y que no está en esta lista? Cuéntamelo en los comentarios, que con gusto lo sumamos a la conversación.
Gracias por leer hasta aquí, de verdad. 🙏
