Cuando un equipo dice “ahora pasa a QA”, suele revelar algo más profundo que una transición en el tablero. La frase puede convertir la calidad en una etapa final y al QA en la última barrera antes de producción. Ese modelo concentra la responsabilidad en una persona, incentiva entregas tardías y hace que los problemas descubiertos al final parezcan defectos de testing en lugar de fallos del sistema de trabajo.
La alternativa no consiste en eliminar QA ni en afirmar que “todos prueban” sin definir cómo. Consiste en distribuir contribuciones concretas y mantener responsabilidad visible. Un Quality Owner ayuda a diseñar ese modelo: no recibe la calidad terminada, sino que facilita las conversaciones, controles y señales que permiten construirla durante todo el ciclo.
Por qué la calidad como fase genera deuda
- Los requisitos llegan con supuestos que nadie convirtió en preguntas.
- La arquitectura se define sin considerar testabilidad u observabilidad.
- Los datos y ambientes se preparan cuando la funcionalidad ya está terminada.
- La automatización se agrega después, con poco tiempo y alto acoplamiento.
- QA recibe varias historias juntas y se convierte en cuello de botella.
- Los defectos se cuentan, pero no se corrige la condición que los produjo.
En estas condiciones, probar más no resuelve el problema. Solo aumenta el esfuerzo necesario para compensar decisiones tomadas sin información de calidad.
Qué aporta cada rol a la calidad
Producto define valor y tolerancia al riesgo
Producto aclara qué problema se intenta resolver, qué comportamientos son críticos, qué impacto tendría un fallo y qué compromisos son aceptables. Sin esta información, el equipo puede verificar criterios y aun entregar algo que no protege el negocio.
Desarrollo construye testabilidad
Quien implementa también decide cuán fácil será observar, aislar y validar el comportamiento. Contratos claros, logs útiles, identificadores de correlación, puntos de inyección y componentes desacoplados reducen el costo de las pruebas y del diagnóstico.
Operaciones aporta realidad de producción
Telemetría, alertas, patrones de carga, degradaciones y recuperación muestran riesgos que un ambiente de pruebas no reproduce completamente. Calidad también es saber qué ocurre después del despliegue.
QA integra riesgos y evidencia
QA conecta las preguntas del negocio con técnicas de prueba, niveles de cobertura y señales observables. Desafía suposiciones, identifica vacíos y ayuda a decidir qué debe comprobarse antes, durante y después del despliegue.
Responsabilidad compartida no significa responsabilidad difusa
Si “todos son responsables”, existe el riesgo de que nadie lo sea. Para evitarlo, cada riesgo importante necesita un propietario, una señal y una respuesta acordada. Por ejemplo, desarrollo puede ser responsable del contrato y sus pruebas; producto, de aclarar reglas y aceptación; operaciones, de la alerta y el procedimiento de recuperación; QA, de hacer visible la cobertura y la incertidumbre.
El Quality Owner no aprueba todo. Mantiene coherente el sistema: identifica huecos, conecta responsables y asegura que las decisiones queden respaldadas por evidencia.
Cuatro momentos para incorporar calidad
Refinamiento
El equipo identifica actores, estados, reglas, dependencias, efectos secundarios y preguntas abiertas. La salida no es solo una historia estimada, sino una comprensión compartida del riesgo. La IA puede ayudar a preparar preguntas, siempre que sus inferencias se marquen como hipótesis.
Diseño e implementación
Se acuerdan contratos, observabilidad, estrategia de datos y niveles de prueba. Las pruebas unitarias, de componente, contrato, API e interfaz se asignan donde entregan la señal más rápida y estable.
Entrega
El equipo revisa evidencia, cambios, riesgos abiertos y mecanismos de reversa. Una decisión de release no debería depender de un único porcentaje, sino de la exposición y de la capacidad de detectar y recuperar.
Producción y aprendizaje
Se observan resultados reales, quejas, incidentes, rendimiento y comportamiento de usuarios. Esa información actualiza el mapa de riesgos y evita que la estrategia se quede congelada.
Una Definition of Done que represente el sistema
Una buena Definition of Done no es una lista genérica. Debe reflejar lo que el equipo necesita para operar el cambio:
- reglas y decisiones actualizadas;
- pruebas ejecutadas en los niveles adecuados;
- contratos compatibles;
- datos y ambientes controlados;
- logs, métricas y alertas suficientes;
- riesgos residuales conocidos;
- plan de despliegue, observación y reversa;
- documentación necesaria para soporte y operación.
No todos los cambios necesitan la misma profundidad. El modelo debe adaptarse al riesgo, no convertir cada historia en un proceso pesado.
Cómo saber si la cultura está cambiando
- Las preguntas de calidad aparecen antes de escribir código.
- Disminuyen los defectos causados por reglas ambiguas.
- El equipo pide señales de producción al diseñar una funcionalidad.
- Las pruebas se distribuyen por nivel y no se concentran en interfaz.
- Los incidentes producen cambios en requisitos, diseño, pruebas y monitoreo.
- QA participa en decisiones de producto, no solo en validaciones finales.
La velocidad no debería medirse por cuánto trabajo “sale de desarrollo”, sino por cuánto valor llega a usuarios sin generar retrabajo y exposición innecesaria.
Del rol de guardián al diseño de confianza
El QA sigue aportando una mirada especializada, pero deja de ser el lugar donde el equipo deposita la calidad. Su influencia crece cuando ayuda a prevenir, diseñar y aprender. Esa es una de las diferencias entre ejecutar un proceso de QA y ejercer Quality Engineering.
Preguntas frecuentes
Si la calidad es de todos, ¿todavía necesitamos QA?
Sí. Compartir responsabilidad no elimina la especialidad. QA aporta técnicas, pensamiento de riesgo, estrategia de cobertura y una mirada crítica difícil de sustituir. Lo que cambia es que no trabaja como receptor final, sino como facilitador y diseñador de una capacidad que el equipo utiliza desde el comienzo.
¿Cómo evitar que la responsabilidad compartida agregue reuniones?
Integrando preguntas y decisiones en espacios existentes. Un refinamiento puede incorporar riesgos; una revisión de diseño puede cubrir testabilidad; el pipeline puede producir evidencia; la retrospectiva puede revisar incidentes. El objetivo no es crear ceremonias de calidad, sino mejorar las decisiones que ya ocurren.
Esta idea parte de la evolución de QA Engineer a Quality Owner. El siguiente paso es construir un sistema que conecte requisitos, automatización y producción.
¿En qué momento participa QA hoy en tu equipo y en cuál debería empezar a participar? Conversemos en LinkedIn.