Elizabeth Urra experta en QA: “La calidad debe construirse desde el diseño y la planificación”

Convencida de que la participación en los proyectos debe ser desde el inicio porque identifica riesgos, facilita la comunicación y será clave en el éxito de un proyecto. De esta manera Elizabeth Urra nos cuenta sobre su rol como especialista QA.

Detrás de cada plataforma o servicio digital que funcione de manera correcta y eficiente es porque hay una estrategia de calidad. En el ecosistema del desarrollo de software, la calidad ya no se evalúa al final del proceso, sino que se construye desde el primer código.

En esta entrevista, Elizabeth Urra, ingeniera en Ejecución en Informática y analista QA de Valio en la Secretaría de Gobierno Digital del Ministerio de Hacienda, nos comparte su visión sobre el enfoque Shift Left Testing, el rol del QA como facilitador colaborativo y cómo estructurar la comunicación con el equipo de desarrollo para prevenir errores antes de que ocurran.

En esta primera parte de la entrevista conoceremos su forma de abordar el rol del QA, metodologías, procesos y colaboración.

Siempre se ve al profesional QA como el asegurador de la calidad, pero más allá de ello, ¿cuál es tu rol dentro del equipo y qué significa ser un facilitador entre desarrolladores, jefes de proyecto (JP) y usuarios finales?

Mi rol es ser una facilitadora de la calidad. No me limito a encontrar defectos antes de liberar código; promuevo prácticas para construir productos de calidad desde el inicio, acompañando todo el ciclo de vida del proyecto. Trabajamos colaborativamente para que todos compartan la misma visión y expectativas. Más que detectar fallas, buscamos prevenirlas, aportar objetividad y facilitar la comunicación entre áreas, identificar riesgos de forma oportuna y aportar una mirada objetiva que contribuya a entregar una solución confiable, alineada con las necesidades del negocio y de los usuarios.

¿Eres más de enfoque tradicional o de la tendencia Shift Left testing? ¿Por qué?

Me identifico totalmente con el Shift Left Testing. Considero que la calidad debe construirse desde el diseño y la planificación, no evaluarse al finalizar. Al involucrar al QA desde el principio, prevenimos problemas, facilitamos la comunicación entre el negocio y el desarrollo, y logramos entregas más eficientes y con menor riesgo.

Afirmas que la participación del QA en un proyecto debe ser desde el comienzo para que el flujo de trabajo sea realmente eficiente, ¿podrías explicar por qué?

Desde el inicio, idealmente en la etapa de levantamiento y análisis de requerimientos.

Tanto las metodologías ágiles como las buenas prácticas promueven que la calidad sea un proceso continuo. Involucrarse tempranamente permite detectar inconsistencias antes de codificar, reduciendo costos y retrabajos. Además, permite preparar con anticipación los escenarios de prueba, definir estrategias y validar que las historias sean verificables.

¿Cómo logras construir una relación de confianza y colaboración con el equipo de desarrollo para que entiendan que no estás ahí para "buscar errores"?

Demostrando que el objetivo no es "buscar errores", sino identificar tempranamente riesgos que afecten al producto. La calidad es una responsabilidad compartida por todo el equipo.

Participo activamente cuando el Product Owner aclara requerimientos para asegurar que Desarrollo y QA entendamos lo mismo. Y al reportar un defecto, evito la documentación extensa: entrego evidencia concreta (pasos para reproducir, capturas, videos o matrices que permitan visualizar rápidamente el escenario y comprender el impacto del defecto) para que el desarrollador resuelva el problema rápidamente. La relación debe basarse en comunicación, respeto y colaboración.

¿Cómo estructuras tus reportes de bugs para que los desarrolladores entiendan el contexto rápidamente sin idas y vueltas eternas?

Estructuro mis reportes de forma simple y precisa con:

• Título claro y descriptivo.

• Ambiente, versión y pasos detallados para reproducir.

• Resultado esperado vs. resultado obtenido.

• Evidencia visual (como capturas de pantalla, videos o registros cuando corresponda)

• La criticidad y el impacto en el negocio, indicando si el defecto bloquea una funcionalidad, afecta a todos los usuarios o si existe alternativa temporal)

Cuando hay múltiples fallas en varios módulos, preparo una matriz resumen por perfil y funcionalidad. Además, relaciono cada defecto con su historia de usuario para dar contexto funcional. Priorizo reportes claros, concretos y visuales para agilizar las correcciones.

¿Cómo manejas la negociación cuando el equipo opina que un comportamiento es "esperado" y tú consideras que es un bug?

Evito las opiniones y me baso en datos y documentación. Escucho la explicación técnica del desarrollador y expongo mi punto con evidencias de las pruebas y su impacto en el usuario. Si se determina que el comportamiento responde a un cambio de requerimiento, me aseguro de que quede documentado para alinear el criterio a futuro. Lo importante es llegar a un acuerdo respaldado por reglas de negocio.