Todos hemos visto que un bug se escape a producción un viernes por la noche. El SDET es la persona que trata eso como una falla de ingeniería, no como mala suerte.
Qué es un SDET, después de todo
SDET significa Software Development Engineer in Test. Traduciendo el cargo: es un ingeniero de software cuya especialidad es la calidad. No es alguien que «prueba después de que todo está listo», sino quien construye las herramientas, los frameworks y las automatizaciones que hacen posible que la calidad ocurra de forma repetible.
La idea central es esta: el SDET escribe código para probar código. Y observa el producto completo —API, base de datos, cola, frontend, pipeline—, no solo la pantalla.
SDET no es QA manual con otro cargo
QA manual y SDET comparten el objetivo —un producto que funciona—, pero el método es diferente. El QA manual explora el sistema como usuario, encuentra lo inesperado y valida los flujos y la experiencia: es un trabajo valioso que no va a desaparecer.
El SDET toma lo repetitivo y determinista y lo transforma en código que se ejecuta solo con cada commit. Una regresión que antes requería dos horas de clics se convierte en dos minutos de pipeline. La diferencia no es «mejor o peor»: por un lado están las pruebas manuales y exploratorias; por otro, la automatización y la infraestructura.
Tampoco es solo el desarrollador que escribe pruebas
Todo buen desarrollador escribe pruebas unitarias para su propio código. Eso no lo convierte en SDET. El foco cambia el ángulo.
El desarrollador de producto piensa: «cómo hago que esto funcione». El SDET piensa: «de cuántas maneras puede fallar y cómo demuestro que no falló». Trabaja en las fronteras: integración entre servicios, datos de prueba, entornos, contratos de API y flakiness. Construye el test harness que utiliza todo el equipo. Es desarrollo de verdad, solo que el «producto» es la confianza en el sistema.
La mentalidad: la calidad es un problema de ingeniería
Aquí está el corazón del papel. La calidad no es una etapa al final, sino una propiedad que se diseña desde el principio.
El SDET piensa en riesgos: ¿qué duele más si se rompe? ¿Dónde vale la pena invertir en automatización y dónde no? Odia las pruebas que pasan cuando deberían fallar y las que fallan sin motivo: el ruido destruye la confianza. También es crítico por profesión: asume que todo puede romperse y diseña para detectar rápidamente cuándo ocurre. Es escepticismo aplicado, no pesimismo.
Las habilidades que exige el papel
En la práctica, el SDET necesita:
- Programación de verdad. Dominar un lenguaje (Python, Java, JS/TS...), estructuras de datos y código limpio. Una automatización deficiente se convierte en deuda técnica.
- Automatización y frameworks. Playwright, Selenium y Cypress en el frontend; pruebas de API y de contratos; construir abstracciones, no solo guionizar clics.
- CI/CD. Una prueba que no se ejecuta en el pipeline casi no existe. Es necesario entender GitHub Actions, GitLab CI, la paralelización y los gates de merge.
- Fundamentos. HTTP, bases de datos, Docker, algo de redes y observabilidad. Para probar el sistema hay que entender el sistema.
No hace falta dominarlo todo el primer día. Hay que estar dispuesto a aprender continuamente, porque el papel toca toda la stack.
Por dónde empieza la carrera
Existen dos caminos comunes. Uno parte del QA manual y aprende a programar, reemplazando poco a poco los clics por código. El otro parte del desarrollo y cambia el foco hacia la calidad y la infraestructura de pruebas. Ambos funcionan.
Un comienzo honesto: automatiza un flujo que hoy pruebas manualmente. Después, intégralo al CI. Luego, hazlo confiable. La progresión va desde SDET júnior hasta SDET sénior y especialista en calidad o SET; además, la base de ingeniería también abre puertas hacia platform y SRE.
SDET no es un QA «potenciado» ni un desarrollador «de segunda». Es la ingeniería de hacer que el software demuestre, por sí solo y todo el tiempo, que todavía funciona. Si los viernes por la noche te dan escalofríos, este papel consiste en dormir tranquilo.
