Shift-left es probablemente uno de los términos más repetidos en calidad de software en los últimos años. Y también uno de los peores entendidos.
La mayoría lo reduce a “meté testing antes en el pipeline”. Como si mover el check de Cypress del deploy a la PR fuera suficiente. Como si el problema fuera puramente cronológico.
No lo es. El problema es de comunicación.
Lo que shift-left realmente significa
Shift-left no es un cambio de herramientas. Es un cambio de responsabilidad.
Cuando la calidad está toda a la derecha —al final del ciclo— lo que tenés es un equipo que construye y otro equipo que revisa. Devs tiran features por arriba de la pared, QA las agarra del otro lado y dice si sirven o no. Ese modelo no escala, no es eficiente y, sobre todo, es profundamente frustrante para todos.
Shift-left es mover la responsabilidad de la calidad al momento en que se toman las decisiones. Y la mayoría de las decisiones de calidad se toman en una charla, en un refinement, en un documento de diseño. No en un test.
Ahí es donde falta comunicación.
La pared invisible entre devs y QA
He visto este patrón cientos de veces:
El dev termina una feature, la sube, mueve el ticket a “Ready for QA”. QA la prueba, encuentra cosas, las reporta. El dev las corrige, resubmittea. QA vuelve a probar.
Ese loop no es testing. Es ping-pong administrativo.
El problema de fondo es que QA no participó cuando la feature se pensó. No sabe qué decisiones llevaron a ese diseño, no conoce los tradeoffs que se hicieron, no entiende el contexto. Y el dev, a su vez, no sabe qué cosas mira QA, qué criterios aplica, qué espera que el producto haga en cada escenario.
Los dos equipos operan con información incompleta. Y cuando operás con información incompleta, lo que producís son bugs, retrabajo y desgaste.
Calidad no se testea, se construye
Esta frase es un cliché, pero es un cliché porque es verdad.
No podés testear calidad adentro de un producto que fue construido sin pensar en ella. Podés encontrar bugs, sí. Pero encontrar bugs no es garantizar calidad. Es apagar incendios.
La calidad real se construye cuando:
- QA está en la sala cuando se define qué se va a hacer.
- El dev entiende qué escenarios son críticos para el negocio.
- Ambos acuerdan qué significa “terminado” antes de escribir una línea de código.
- Los criterios de aceptación no son una lista genérica que alguien copió del ticket anterior.
Eso no se automatiza. Eso se conversa.
Lo más difícil no es técnico
Acá es donde la mayoría de los equipos se equivocan. Buscan soluciones técnicas a problemas humanos.
Ponen pipelines, linters, SonarQube, tests de integración, reportes de cobertura. Todo suma, no me malinterpreten. Pero si el problema de fondo es que devs y QA no se hablan, ninguna herramienta te va a salvar.
Lo más difícil del shift-left no es aprender Playwright. No es configurar GitHub Actions. No es escribir tests unitarios.
Lo más difícil es crear una cultura donde:
- Un dev puede decir “no sé si esto está bien, ¿lo miramos juntos?” sin sentir que está fallando.
- Un QA puede cuestionar una decisión de diseño en el refinement sin que lo miren como si estuviera fuera de lugar.
- Ambos entienden que el objetivo no es encontrar culpables, es entregar valor.
Eso requiere confianza. Y la confianza se construye con comunicación sostenida en el tiempo.
Cosas concretas que podés hacer mañana
No todo es cultura abstracta. Hay acciones muy puntuales que cambian la dinámica:
Incluí a QA en refinements y groomings. No como oyente pasivo, sino con voz para preguntar, cuestionar y proponer. Si QA recién ve la feature cuando está codeada, llegaste tarde.
Escribí criterios de aceptación en conjunto. No es un formulario que llena el PM. Es un contrato entre dev y QA sobre qué significa que esa feature funcione. Si los dos no lo entienden igual, ya hay un bug antes de empezar.
Hacé pair testing. Así como existe pair programming, sentate con QA a testear juntos. El dev aprende qué busca QA, QA entiende por qué ciertas cosas se hicieron como se hicieron. Las dos direcciones suman.
Dejá de contar bugs como métrica de éxito. Encontrar 50 bugs no es señal de que QA trabaja bien. Es señal de que algo falló antes. Mejor métrica: cuántos bugs encontraron juntos en la etapa de diseño y cuántos se evitaron.
Automatizá lo predecible, conversá lo complejo. Los tests automatizados son para lo repetitivo y lo regresivo. Las decisiones de calidad para lo nuevo y lo ambiguo requieren criterio humano. No confundás qué va en cada carril.
No es un problema de roles, es un problema de proceso
Muchas veces se plantea como “los devs no saben testear” o “QA no entiende de código”. Esa discusión es estéril.
El problema no es que los devs no sepan testear. Es que el proceso los aísla del feedback de calidad hasta que es tarde. Y el problema no es que QA no entienda de código. Es que el proceso los convierte en un filtro al final de la línea en vez de un par en la mesa de diseño.
Cuando cambiás el proceso para que la comunicación sea temprana, los roles dejan de ser compartimentos estancos y pasan a ser perspectivas complementarias sobre el mismo objetivo.
La calidad es de todos o no es de nadie
Un equipo que entiende shift-left de verdad no tiene un “departamento de calidad”. Tiene una cultura de calidad.
Y esa cultura no se construye con herramientas. Se construye con conversaciones.
Empezá por ahí. Sentate con QA —o con tu dev, si estás del otro lado— y preguntale qué necesita para hacer mejor su laburo. Después escuchá. Después actuá.
El resto viene solo.