Mi querido amigo y amiga de la calidad,
Estaba notando que hay un grupo importante de personas que están muy interesadas en entrar al mundo de IT. Y esto no es una aspiración sencilla, con la llegada de la IA muchas personas han optado por asignar tareas a estos métodos y por supuesto QA no escapa de ello.
Llevo tiempo pensando en escribir esta serie porque muchos de ustedes me escriben preguntas que, sin saberlo, son exactamente las mismas dudas que yo tenía hace años, y que estoy seguro que ahora con las nuevas herramientas, este conocimiento servirá no solo para dar contexto en sus proyectos, sino para mejorar sus prompts y los resultados que obtienen del trabajo. Así que decidí ser honesto y contarles los errores que cometí — es probable que a ti te llegue a pasar lo mismo, y mi propósito es que puedas hallar información útil en lo que te comparto hoy.
Este es el primero de una serie de artículos donde voy a ir desarrollando varios temas desde mi experiencia y con ayuda de bibliografías que me han servido mucho para enriquecer mi perfil y tratarlos con más profundidad. Empecemos.
Error 1: No entender dónde terminaban mis responsabilidades y dónde empezaban las del desarrollador
Esta fue, honestamente, la que más me costó. Al inicio yo pensaba que QA y desarrollo eran dos mundos separados por una línea bien clara: ellos programan, yo pruebo lo que ellos programan. Punto.
Lo he vivido en equipo tras equipo: esa línea no existe, o al menos no de la forma en que yo la imaginaba. La calidad no es una posta que se pasa al final del proceso, es una responsabilidad compartida desde el principio. ¿Y sabes qué fue lo que realmente me hizo click? Entender que los criterios de aceptación no son solo una guía para que yo sepa qué probar — también le sirven al desarrollador para entender cómo debería plantear sus propias pruebas unitarias.
Cuando dejé de pensar en “esto es mío, esto es tuyo” y empecé a pensar en “esto es lo que necesitamos cubrir entre los dos”, todo cambió. Las conversaciones con el equipo de desarrollo dejaron de sentirse como una negociación y empezaron a sentirse como una construcción conjunta. Creo que en parte esta visión es heredada de los proyectos predictivos, donde cada fase debe finalizar antes de empezar otra, en cambio en agilidad, cada etapa está integrada en cada iteración, lo que permite una mayor colaboración.
Error 2: Pensar que si algo ya estaba cubierto en pruebas unitarias, no tenía sentido volver a probarlo en End to End
Esta pregunta me perseguía: “si el desarrollador ya probó esto con un unit test, ¿por qué yo tengo que volver a probarlo en un flujo completo?” Sentía que estaba duplicando trabajo, que estábamos perdiendo tiempo probando lo mismo dos veces.
La respuesta que me cambió la perspectiva fue simple pero profunda: cada tipo de prueba te da un feedback diferente. Una prueba unitaria te dice “esta pieza funciona de forma aislada.” Una prueba de integración te dice “estas piezas se comunican bien entre sí.” Una prueba End to End te dice “el usuario real puede completar lo que necesita hacer.” Y una prueba de contrato te dice “los servicios que dependen entre sí están de acuerdo en cómo hablarse.”
Ninguna reemplaza a la otra porque ninguna responde la misma pregunta. Cuando entendí esto, dejé de ver la pirámide de pruebas como una jerarquía de “más importante” a “menos importante”, y empecé a verla como lo que realmente es: una estrategia de cobertura donde cada capa cubre un riesgo distinto.
Error 3: Creer que todas las pruebas dependían de tener una interfaz para hacer clic
Este error viene directo de mi falta de experiencia técnica al inicio. Como no tenía una interfaz visual para interactuar, sentía que no había nada que probar todavía. “¿Cómo voy a planificar pruebas si no hay pantalla?”, pensaba.
La verdad es que ahí fue cuando entendí que gran parte del trabajo de QA sucede antes de que exista una sola pantalla. La planificación de pruebas empieza con los requisitos, con la arquitectura, con entender qué componentes se van a comunicar entre sí y qué puede salir mal en esa comunicación — mucho antes de que haya algo que puedas “ver.”
Aprender sobre arquitectura de software y sobre programación orientada a objetos me ayudó muchísimo aquí, porque me permitió entender el sistema no como una pantalla, sino como un conjunto de piezas que interactúan. Y una vez que entiendes eso, puedes empezar a diseñar pruebas — unitarias, de integración, de contrato — sin necesidad de tocar una sola interfaz.
Error 4: No entender que cada tipo de prueba tiene un propósito distinto (y por eso las aplicaba mal)
Este error está muy conectado con el anterior, pero merece su propio espacio porque fue un cambio de mentalidad completo. Durante mucho tiempo apliqué las pruebas casi por costumbre, no por estrategia. Hacía End to End porque “así se hacía siempre,” sin preguntarme realmente qué riesgo estaba cubriendo con eso.
Todo cambió cuando empecé a diseñar pruebas pensando primero en la pregunta: ¿qué quiero saber con esta prueba? Si la respuesta era “quiero saber si esta función aislada hace lo que debe,” ahí iba una prueba unitaria. Si era “quiero saber si el usuario puede completar su flujo de principio a fin,” ahí iba una End to End. Ese simple cambio de pregunta transformó cómo diseñaba, cómo priorizaba, y sobre todo, cómo explicaba mi trabajo al resto del equipo.
Error 5: Pensar que la calidad era un tema técnico, y no también un tema de liderazgo
Este error tardé más en verlo, porque no se nota tanto como los anteriores. Yo pensaba que mi trabajo era técnico: diseñar pruebas, ejecutarlas, reportar bugs. Punto. Lo que no entendía era que una parte enorme de mi crecimiento como QA vino de aprender a ser un referente de calidad dentro del equipo, y de empoderar a las demás personas para tener conversaciones abiertas sobre posibles errores y sus riesgos.
¿Y sabes qué fue lo que más me costó aceptar? Que no todos en el equipo ven el riesgo de la misma forma, y que eso no significa que alguien esté equivocado. DevOps prioriza la automatización, porque su enfoque está en que todo fluya rápido y de forma confiable en el pipeline. Negocio prioriza las pruebas exploratorias y sin guion, porque quiere entender cómo se comporta el producto en escenarios reales que nadie documentó. Desarrollo, muchas veces, prioriza la prevención y reparación temprana de errores, porque su enfoque está en la salud del código.
Todos tienen razón desde su perspectiva. El problema es que si cada quien defiende su prioridad como si fuera la única válida, terminas con una estrategia de calidad fragmentada, donde nadie ve el panorama completo. Lo que a mí me ayudó fue entender que mi rol no era imponer mi visión de calidad por encima de las demás, sino facilitar que estas perspectivas se sentaran en la misma mesa y construyeran juntas una estrategia compartida.
Y aquí quiero conectar esto con algo que mencioné al inicio: hoy en día puedes preguntarle a una IA qué es una prueba unitaria, cómo se diferencia de una de contrato, o qué framework de automatización usar. Ese conocimiento técnico, en gran parte, ya está a un prompt de distancia. Pero facilitar una conversación real entre DevOps, negocio y desarrollo sobre qué riesgos importan más y por qué, leer las tensiones del equipo, y ganarte la confianza para que te escuchen como referente de calidad — eso no te lo da un prompt. Esa es la parte de nuestro trabajo que se vuelve más valiosa, no menos, en la medida en que la IA nos resuelve lo técnico.
Lo que me ayudó a salir de estos errores
No llegué solo a estas conclusiones. Hubo bibliografía que fue clave en este proceso, y quiero compartirla porque sé que a muchos de ustedes también les puede ayudar:
- [ Ingeniería del Software. Un Enfoque Práctico, 5ta edición — Roger S. Pressman]
- [ Leading Quality: How Great Leaders Deliver High-Quality Software and Accelerate Growth — Ronald Cummings-John y Owais Peer]
- [The Clean Coder — Robert C. Martin, específicamente aborda las pruebas desde la perspectiva del desarrollo]
Y estos son solo tres, porque en el camino leí muchos más. Si quieres, en el próximo artículo de la serie te cuento cuáles otros libros marcaron mi forma de entender el testing.
¿Y tú, mi querido amigo y amiga de la calidad? ¿Cuál de estos errores te suena más familiar? ¿O tienes uno propio que no está en esta lista todavía? Cuéntamelo en los comentarios, que con gusto lo puedo sumar a la conversación.
Gracias por leer hasta aquí.
