SDET suena a un puesto inventado para que el perfil de LinkedIn se vea más bonito, pero el rol es real y resuelve un problema molesto: la calidad no puede ser responsabilidad de un equipo que aparece solo al final.
SDET no es QA con otro nombre
El QA clásico recibe la feature terminada y se dedica a buscar dónde falla. El SDET entra antes, escribe código y trata la calidad como parte del producto. La diferencia no está en la herramienta, sino en el momento y la mentalidad.
Ser responsable de la calidad significa preocuparse por la testabilidad de la arquitectura, por lo que es fácil o imposible de verificar y por el costo de cada prueba. Encontrar bugs es una consecuencia, no el objetivo.
Estrategia antes de empezar a automatizar
El error más común es automatizar todo lo que aparece por delante. Seis meses después tienes 800 pruebas E2E lentas en las que nadie confía y que todo el mundo ignora.
La estrategia consiste en decidir qué vale la pena automatizar, en qué nivel y qué dejar fuera. Una prueba que nadie lee cuando falla es peor que no tener ninguna: genera una falsa sensación de seguridad y, además, exige mantenimiento.
La pirámide (y por qué la mayoría la construye al revés)
La pirámide de pruebas es simple: muchas pruebas unitarias, algunas de integración y muy pocas E2E. Rápidas y baratas abajo; caras y frágiles arriba.
La mayoría de los equipos construye el cono de helado: una pila de pruebas E2E frágiles y casi nada de pruebas unitarias. Se ve bien en el informe de cobertura y resulta insoportable en la práctica: cada deploy se convierte en una lotería. Si tus pruebas de UI son la primera línea de defensa, algo se desvió mucho antes.
Una prueba flaky es deuda, no un detalle
Una prueba flaky es la que pasa y falla sin que hayas cambiado nada. Parece inofensiva. No lo es. Entrena al equipo para ignorar el rojo y, el día que algo se rompa de verdad, nadie va a mirar.
Regla estricta: una prueba flaky se arregla o se elimina de la suite. Dejar "solo esta" ahí es como dejar una ventana rota: en poco tiempo la mitad de la suite será ruido y el CI se convertirá en decoración que todos aprenden a ignorar.
Automatización sin CI es teatro
Una prueba que solo se ejecuta en tu máquina no protege a nadie. Su valor aparece cuando se ejecuta en cada pull request y bloquea el merge si falla.
Una suite rápida y confiable en el pipeline cambia el comportamiento del equipo: puedes refactorizar sin miedo porque el CI avisa de inmediato. Una suite lenta e inestable produce el efecto contrario: todos aprenden a hacer skip y a pulsar "merge" de todos modos.
Cuándo las pruebas manuales siguen ganando
La automatización no elimina las pruebas manuales; cambia su enfoque. Un robot es excelente para repetir tareas y pésimo para juzgar. Las pruebas exploratorias, la usabilidad y ese "esto se siente raro" que nadie escribió en el requisito pertenecen al territorio humano.
Un buen SDET automatiza lo repetitivo para liberar tiempo de las personas para lo que exige criterio. Probar manualmente el mismo flujo por milésima vez no es dedicación: es desperdicio.
SDET trabaja CON desarrollo, no contra él
Un SDET que lanza bugs por encima del muro y desaparece se convierte en enemigo del equipo. El buen enfoque es el contrario: acercarse. Ayudar a los desarrolladores a escribir pruebas, revisar la testabilidad en el PR y hacer que la calidad sea fácil de conseguir.
Cuando funciona, la frontera entre "quién desarrolla" y "quién prueba" desaparece. Todos se convierten en responsables de la calidad, y el SDET es quien entrega las herramientas para que eso suceda.
Al final, un SDET no es la persona que pulsa el botón de probar en el último minuto. Es quien hace posible que todo el equipo entregue rápido sin romperlo todo, y eso vale mucho más que cualquier informe de bugs bien presentado.
