De qué va este capítulo
SDD explicado para QA, sin instalar nada. Antes de decir qué es, el video aclara tres cosas que no es: no es una herramienta, no es «la IA escribe el código sola» y no es «documentar más».
Antes, el documento de requisitos describía el trabajo, pero no lo producía. La gente lo leía y corregía sobre la marcha. Con SDD la especificación queda arriba y de ella salen el diseño, las tareas, el código y los tests. Se termina la deriva silenciosa, pero también se termina esa corrección sobre la marcha: si la especificación tiene un hueco, ese hueco baja por todo el ciclo igual de convencido.
El ciclo tiene seis fases: idea, especificación, diseño, tareas, implementación y verificación, y cada una produce la siguiente. El trabajo de QA está en las cinco transiciones entre fases, no en la última caja. El ejemplo del video es una especificación que suena completa: «El usuario recibe una notificación cuando su pedido cambia de estado». No dice qué estados, qué pasa si la notificación no se puede entregar ni si el usuario la puede apagar. El diseño, las tareas, el código y los tests heredan el mismo hueco. Todo es coherente y todo comparte el agujero.
La coherencia se hereda hacia abajo; la corrección, no. Por eso QA tiene que entrar desde arriba. En la parada 2 de la serie va la técnica concreta para revisar una especificación. Si prefieres leerlo, el tema está desarrollado en el artículo Qué es el Spec-Driven Development y qué hace el QA si la IA escribe los tests.