¿Frenar o reorientar lanzamientos? La verdadera misión del QA bajo presión

Tener todos los elementos sobre la mesa y tomar decisiones basadas en datos son clave para que el rol del QA pueda equilibrar la urgencia de las entregas con la rigurosidad técnica y resguardar la experiencia del usuario. Así lo explica nuestra analista QA Elizabeth Urra, quien es ingeniera en Ejecución en Informática.

En esta segunda parte de la entrevista, Elizabeth profundiza sobre cómo gestiona la presión en momentos críticos, el valor de la empatía en equipos técnicos, asertividad de comunicar con claridad y la importancia estratégica del rol QA como puente con el negocio.

Elizabeth Urra, ingeniera en ejecución en informática, analista QA en Valio.

¿Cómo equilibras la urgencia de salir a producción con la necesidad de mantener un estándar alto de calidad junto al líder de proyecto?

Se logra con comunicación constante y gestión de riesgos. QA debe dar visibilidad temprana sobre el

estado de las pruebas. Ante tiempos ajustados, priorizamos: evaluamos con el jefe de proyecto (JP), Product Owner y Desarrollo la criticidad de cada defecto para definir qué debe corregirse de inmediato y qué se posterga. Nuestro objetivo no es frenar una liberación, sino entregar datos objetivos para que el equipo tome decisiones conscientes sobre el riesgo.

Reportar un bug crítico a horas de un despliegue es estresante. ¿Cómo manejas la asertividad para comunicar sin alarmar al JP ni desmotivar al desarrollador?

Mantengo la calma y me enfoco en hechos e impactos, no en personas. Informo al JP o líder técnico presentando objetivamente el fallo, cómo reproducirlo y su impacto en el negocio. Con el desarrollador mantengo una postura colaborativa; le entrego evidencia clara sin buscar culpables para que pueda enfocarse en la solución. Para mí, la asertividad significa comunicar los hechos con claridad, respeto y evidencia, sin dramatizar la situación ni minimizar el riesgo. De esa forma se mantiene la confianza del equipo y se toman decisiones pensando siempre en la calidad del producto y en el impacto para el usuario final.

¿Cómo compatibilizas la empatía con la rigurosidad técnica?

La rigurosidad está en validar con criterio y respaldar cada hallazgo con evidencias. La empatía está en la forma de comunicarlo: con respeto y entendiendo la carga del equipo. No abordo el problema diciendo que el desarrollador "se equivocó", sino explicando el impacto del error para resolverlo juntos. Cuando el QA es visto como un apoyo, la comunicación fluye y las fallas se corrigen más rápido.

El equipo de QA suele estar bajo mucha presión en los cierres. ¿Qué soft skills consideras indispensables en esos momentos?

Destaco la comunicación clara, la capacidad de colaborar y negociar basada en evidencias, la empatía y la resiliencia. Mantener la cabeza fría significa priorizar las funcionalidades de mayor riesgo e impacto para el usuario, basando las decisiones en datos concretos, aunque el tiempo sea limitado.

¿Cómo aporta el QA una visión de negocio o de cara al usuario final?

El QA es un puente entre el negocio, el desarrollo y el usuario final. Un desarrollo puede ser técnicamente correcto, pero si no es intuitivo o rompe reglas del negocio, no cumple su objetivo. Validamos que el producto funcione bien, pero sobre todo que resuelva la necesidad real del usuario y aporte valor operativo.

¿Por qué un proyecto exitoso no puede prescindir de un QA? Si decidieran prescindir, ¿cuál crees que sería el motivo?

Si prescindieran de mi rol, haría una autocrítica sobre si logré aportar valor, prevenir problemas y facilitar el trabajo del equipo. El QA demuestra su valor cuando es un aliado estratégico. Cuando se logra esa sinergia, la calidad pasa a ser responsabilidad de todos y el rol deja de percibirse como un costo.

Si un bug crítico llega a producción y el usuario lo detecta, ¿cómo gestionas ese momento de alta presión?

Entendiendo que en software complejo no existe la cobertura al 100 %. Ante un incidente, actuamos con transparencia y realizamos un análisis de causa raíz junto al equipo (revisando si faltaron criterios, datos de prueba o cobertura) para evitar que vuelva a ocurrir. Transformamos la falla en una oportunidad de mejora.

Un buen QA no se mide por nunca dejar pasar un defecto, sino por su capacidad para gestionar el riesgo, reaccionar de forma profesional ante un incidente y transformar esa experiencia en una mejora para el equipo y para el proceso. Esa actitud genera confianza tanto en el equipo de desarrollo como en el jefe de proyecto, porque demuestra compromiso con la calidad.