QA de Diseño como Puerta de Liberación trata los chequeos de calidad de diseño como bloqueadores duros de liberación en lugar de cortesías pre-lanzamiento. La puerta es el compromiso estructural que dice: los defectos de diseño no se entregan. Los chequeos detrás de la puerta (regresión visual, cumplimiento de tokens, auditorías de accesibilidad, revisión heurística) son los que le dan dientes a ese compromiso. Sin la puerta, el QA de diseño degrada a "lo que el diseñador alcanzó a atrapar antes de que el PR se mergeara"; con la puerta, la calidad de diseño tiene el mismo piso de cumplimiento que la calidad de código.
Curtis (2023) en EightShapes escribió el artículo canónico de practicantes sobre QA de componentes como un proceso de liberación de sistema de diseño. Su movimiento central es tratar el QA como un paso obligatorio antes de la liberación de componentes, con un conjunto definido de chequeos (funcionalidad, estados visuales, accesibilidad, cobertura de navegadores) que deben pasar para hacer merge. El artículo replantea el QA de una idea defensiva posterior a una parte estructural del flujo de contribución.
El Storybook Visual Testing Handbook formaliza el patrón de automatización: cada variante de componente se vuelve una historia, cada historia se vuelve una prueba visual, y la prueba corre en cada PR. Los equipos que adoptan el patrón reportan 60-80% menos regresiones de diseño post-liberación porque la puerta atrapa lo que la revisión manual pierde. La combinación de compromiso estructural (Curtis) más cumplimiento automatizado (Storybook + Chromatic / Percy / similar) es lo que hace que el QA de diseño realmente funcione como una puerta de liberación.
El principio: Define qué bloquea el merge. Automatiza el chequeo. Bloquea el merge cuando el chequeo falla.