Generar pruebas a partir de diseños de Figma antes del código
Genere pruebas a partir de diseños de Figma antes de que exista el código: desarrollo guiado por pruebas para la interfaz, QA de diseño sin selectores y comprobaciones que siguen al diseño.
10 min de lecturaPor el equipo de GUI Test Studio
¿Por qué generar pruebas a partir de diseños de Figma?
Sus diseñadores ya escribieron la especificación más precisa que tiene su equipo.Un archivo de Figma dice lo que debe mostrar cada pantalla: las palabras de cada botón, los iconos, el orden de los campos, la pantalla que llega después de un clic.Sin embargo, la mayoría de los equipos escribe sus pruebas de extremo a extremo semanas después, a partir de la aplicación terminada, y mientras tanto comprueba el diseño a ojo.
El desarrollo guiado por el diseño invierte ese orden.Es desarrollo guiado por pruebas en el que el diseño, y no el código, es la especificación de la que sale la primera prueba.Usted genera las pruebas a partir de los diseños de Figma el mismo día en que se aprueba el diseño.La prueba falla mientras la función no existe.Se supera el día en que lo desarrollado coincide con el diseño.A partir de entonces, vigila que lo desarrollado siga fiel al diseño cada vez que cambian el diseño o el código.
Este artículo explica el desarrollo guiado por pruebas, por qué las pruebas de extremo a extremo en código no pueden escribirse primero, qué son el QA de diseño y la deriva del diseño, y cómo GUI Test Studio, una suite de pruebas de extremo a extremo para aplicaciones de escritorio y aplicaciones web, convierte un diseño de Figma en una prueba que se ejecuta.
TDD, ATDD y BDD en un minuto
Las tres son formas de escribir primero la prueba.Se diferencian en aquello a partir de lo que se escribe la prueba y en quién la lee.
| Práctica | La prueba se escribe a partir de | Quién la lee |
|---|---|---|
| Desarrollo guiado por pruebas (TDD) | Una pequeña parte del comportamiento que debe tener el código | Los desarrolladores |
| Desarrollo guiado por pruebas de aceptación (ATDD) | Los criterios de aceptación que el equipo acordó con el negocio | Todo el equipo |
| Desarrollo guiado por el comportamiento (BDD) | Escenarios en palabras sencillas, a menudo escritos como Given, When, Then con una herramienta como Cucumber | Todo el equipo |
El ciclo del TDD tiene tres tiempos.Rojo: escribir una prueba que falla, porque el comportamiento aún no existe.Verde: escribir el código justo para que se supere.Refactorizar: mejorar el código mientras la prueba lo mantiene correcto.
Adelantar así las pruebas se suele llamar shift-left testing.Un defecto encontrado antes de que una función se publique cuesta menos de corregir.Una prueba escrita primero es también una especificación que nadie puede malinterpretar.
¿Por qué no se puede escribir una prueba de extremo a extremo antes del código?
El TDD funciona bien con las funciones del código y las API.En la interfaz de usuario, normalmente se detiene.El motivo es la forma en que las pruebas de extremo a extremo en código encuentran las cosas en la pantalla.
Una prueba de Selenium, Playwright o Cypress encuentra cada elemento mediante un localizador: un id, un selector CSS, un XPath, un rol y un nombre.Selenium documenta ocho estrategias de localización, del id al XPath.Cypress recomienda un atributo dedicado, como data-cy, en cada elemento que toca una prueba.
Cada uno de ellos es un dato sobre el código.Antes de que exista el código, no hay ningún id que seleccionar ni ningún atributo al que apuntar.Los page objects, las clases que envuelven cada pantalla para las pruebas, se escriben sobre ese mismo marcado.
Las instantáneas visuales en código también parten de lo ya desarrollado.Playwright crea sus capturas de referencia en la primera ejecución, así que la imagen con la que compara una prueba es la aplicación tal como se construyó, no tal como se diseñó.Storybook con Chromatic compara cada story de componente con su línea base aprobada, lo que detecta los cambios entre compilaciones.
Así que, en la práctica, la prueba de extremo a extremo se escribe después de la función, y la escribe alguien que mira la aplicación terminada.Después comprueba que la aplicación sigue haciendo lo que hace hoy, sea o no lo que se diseñó.
QA de diseño y deriva del diseño
El QA de diseño es la comprobación de que lo desarrollado coincide con el diseño.En la mayoría de los equipos se hace a ojo tras la entrega del diseño: un diseñador pone el marco de Figma junto a la aplicación de preproducción y enumera lo que difiere.
La deriva del diseño es la distancia que crece entre el diseño y el producto cuando nadie lo comprueba.Una etiqueta recibe palabras nuevas en el código.El grosor de una fuente no es el del sistema de diseño.Falta un icono en una pantalla.Cada cambio es pequeño, y juntos hacen que el producto parezca inacabado.
Las pruebas de regresión visual no cierran esa distancia por sí solas.Comparan la compilación de hoy con una compilación anterior, así que una pantalla que nunca coincidió con su diseño se supera cada vez.
Varias herramientas ya pasan de Figma a casos de prueba.La IA generativa de Testsigma escribe escenarios y casos de prueba a partir de marcos de Figma, una vez configurados un id de equipo de Figma y un token de acceso.BrowserStack Test Companion lee un enlace de Figma pegado y escribe casos de prueba, o scripts de automatización en su framework.Applitools Eyes permite que una prueba automatizada use un marco de Figma como su línea base visual.
Los casos de prueba escritos ayudan de verdad a planificar, pero una persona sigue teniendo que ejecutarlos o convertirlos en código.Un script generado, como cualquier prueba visual en código, sigue llegando a cada elemento mediante un localizador que solo existe cuando la función ya está desarrollada.Para una visión más amplia de las herramientas de extremo a extremo, consulte el estudio comparativo.
¿Cómo se generan pruebas de extremo a extremo a partir de un diseño de Figma?
Una prueba solo puede escribirse a partir de un diseño si no necesita el código.Tiene que encontrar cada elemento como lo hace una persona: por su aspecto y por lo que dice.
Así es como GUI Test Studio comprueba una pantalla.Una comprobación visual encuentra un elemento visualmente y lo compara con la imagen que usted espera.Una comprobación de texto lee las palabras de la pantalla.Un diseño ya contiene cada imagen y cada palabra que necesitan esas comprobaciones.
| Lo que contiene el diseño de Figma | Lo que recibe la prueba |
|---|---|
| Cada pantalla | Una imagen de referencia de la pantalla |
| Las palabras de una etiqueta, un título o un botón | Una aserción de texto que espera esas palabras |
| Un valor que cambia, como una fecha o un importe | Una aserción de texto dinámico que espera un valor del mismo tipo |
| Un icono, un logotipo o una imagen | Una aserción visual que busca esa imagen |
| Las secciones de una pantalla, como su cabecera o su formulario | Una aserción de grupo por sección, que también puede comprobar la disposición |
| Los enlaces de un flujo de prototipo | Los clics que llevan de una pantalla a la siguiente |
Diseño
Las pantallas de Figma aprobadas
Rojo
La prueba falla: la función aún no existe
Desarrollo
Un desarrollador o un agente de programación con IA escribe la función
Verde
Lo desarrollado coincide con el diseño
Desarrollo guiado por pruebas para la interfaz, paso a paso
- 1
Generar la prueba a partir del diseño aprobado
El día en que se aprueba el diseño, impórtelo.La prueba describe ahora la pantalla tal como se diseñó, antes de que nadie escriba la función.
- 2
Verla fallar: ese es el paso en rojo
Ejecútela contra la aplicación de hoy.La pantalla nueva no existe, así que sus comprobaciones fallan.El rojo es justamente lo que se busca: la prueba es la lista del trabajo que queda por hacer.
- 3
Desarrollar hasta que se ponga en verde
Un desarrollador, o un agente de programación con IA, desarrolla la función.Su pipeline ejecuta la prueba en cada compilación con gtr-cli.El Informe de confianza dice, elemento por elemento, lo que ya coincide con el diseño y lo que no.
- 4
Aceptar una vez el aspecto real
Un diseño y una pantalla real rara vez coinciden al píxel, porque las fuentes se dibujan de forma algo distinta.Tras la primera ejecución real, acepte una vez el aspecto real desde el Informe de confianza.A partir de entonces, la prueba compara con lo real.Consulte Cuando la aplicación cambia a propósito.
- 5
Refactorizar con la prueba como protección
Cambie el estilo de la aplicación, refactorícela, cambie su framework.La prueba no lee su código, así que se sigue superando mientras la pantalla siga siendo correcta.Falla cuando un usuario vería una diferencia.
Importar desde Figma: la prueba antes que la función
GUI Test Studio hace todo esto con Importar desde Figma.Un pequeño plugin se ejecuta dentro de Figma y guarda su diseño en un solo archivo, un paquete de diseño.GUI Test Studio recoge ese archivo.No hay ninguna cuenta de Figma que conectar ni ningún token de acceso que crear, y no se envía nada a ninguna parte.
El plugin se instala con GUI Test Studio.Se añade una sola vez en la aplicación de escritorio de Figma, en Plugins, Development, Import plugin from manifest....
En GUI Test Studio, elija Archivo, Importar desde Figma...: la ventana espera su diseño.En Figma, inicie el plugin y marque las pantallas que quiera, o elija un flujo de prototipo.Sus pantallas llegan entonces en orden, con los clics que llevan de una a la siguiente.Deje el archivo exportado en su carpeta Descargas: GUI Test Studio vigila esa carpeta y abre el diseño en uno o dos segundos.
La revisión muestra cada pantalla con un recuadro alrededor de cada elemento, y dice qué comprobación recibe cada uno.Un texto se comprueba como texto solo cuando se lee realmente en la imagen.Las palabras demasiado pequeñas o demasiado tenues reciben en su lugar una comprobación de imagen, y la lista dice por qué.Los párrafos largos y las fotografías grandes aparecen en la lista pero sin marcar, porque suelen ser contenido de ejemplo.
Haga clic en Importar, y todo llega como un solo escenario con el nombre de su diseño.Cada pantalla se convierte en una imagen en la pista Referencia visual.Sus comprobaciones van a la pista Aserciones, agrupadas por sección.En un flujo de prototipo, el clic que lleva a la pantalla siguiente se dirige al botón del que parte el enlace en el diseño.
Un diseño no dice dónde estará la ventana de la aplicación, así que estas comprobaciones buscan en toda la pantalla.Comparan con una exigencia flexible, de modo que se toleran las pequeñas diferencias de dibujo entre un diseño y una pantalla real, mientras que un elemento que falta o una palabra cambiada siguen haciendo fallar la comprobación.
Su diseñador termina el flujo «Sign in»: Login, luego Dashboard, luego Settings.Usted importa el flujo y obtiene tres imágenes, el clic en Sign in, el clic en el engranaje de ajustes y las comprobaciones de cada pantalla.La prueba está lista mucho antes que la función.El día en que la función llega a preproducción, el pipeline recorre con sus clics la aplicación real e informa, elemento por elemento, de si coincide con el diseño.
Cuando el diseño cambia: Sincronizar desde Figma
Los diseños evolucionan, y una prueba escrita a partir de un diseño tiene que evolucionar con ellos.Cuando el diseño cambie, expórtelo de nuevo desde Figma y luego elija Archivo, Sincronizar desde Figma... en GUI Test Studio.
| Lo que cambió en el diseño | Lo que hace una sincronización |
|---|---|
| Un texto dice otra cosa | La comprobación espera las palabras nuevas. |
| Un elemento tiene otro aspecto | La comprobación toma la imagen nueva. |
| Un elemento se movió o cambió de tamaño | La comprobación lo sigue, y también un clic dirigido a él. |
| Un elemento ya no está | Su comprobación se elimina. |
| Un elemento es nuevo | Sin marcar: nada nuevo se comprueba a menos que usted lo pida. |
Una comprobación que usted mismo editó tampoco está marcada, de modo que una sincronización nunca sobrescribe su trabajo sin preguntar.Nada se comprueba en segundo plano: la prueba solo cambia cuando usted sincroniza.
Esto es lo que mantiene visible la deriva del diseño.Cuando el diseño cambia y lo desarrollado no lo sigue, la prueba sincronizada falla y dice qué elemento difiere.
De un diseño de Figma a una prueba con un asistente de IA
También puede entregar el diseño a un asistente de IA.Claude, ChatGPT o un modelo de IA local en su propio equipo, uno nuestro o uno suyo, conectado a GUI Test Studio, crea la prueba a partir del paquete de diseño mediante la misma importación.Consulte Crear una prueba desde una petición.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.La prueba se guarda, y GUI Test Studio se abre en ella, lista para que usted la revise.Combina bien con un agente de programación con IA: el agente desarrolla la función, y la prueba hecha a partir del diseño le dice si desarrolló lo que se diseñó.Consulte Desarrollo con agentes de IA.
Buenas prácticas
Do
- Exportar el flujo de prototipo, para que la prueba recorra las pantallas en orden con sus clics.
- Dar nombres claros a las pantallas y a las secciones, como «Login» y «Header»: las comprobaciones de cada sección viajan en una sola aserción de grupo con su nombre.
- Ejecutar la prueba en cada compilación desde el primer día, también cuando está en rojo.
- Aceptar una vez el aspecto real, tras la primera ejecución de la función ya desarrollada.
Avoid
- Comprobar contenido de ejemplo, como párrafos de relleno y fotos de archivo.
- Tratar la primera ejecución en rojo como una prueba rota: es la lista del trabajo por hacer.
- Marcar cada elemento nuevo en una sincronización sin mirarlo.
- Escribir selectores para una pantalla que aún no existe.
¿No tiene archivo de Figma?Las imágenes de cualquier herramienta de diseño, como Sketch o Adobe XD, también sirven: consulte Pruebe una función antes de que exista.
Preguntas
¿Se pueden generar pruebas a partir de diseños de Figma?
Sí.El plugin de Figma de GUI Test Studio guarda sus pantallas en un solo archivo de diseño, e Importar desde Figma lo convierte en una prueba de extremo a extremo: una imagen de referencia por pantalla, una comprobación por elemento y, en un flujo de prototipo, los clics entre pantallas.La prueba se ejecuta contra la aplicación real en cuanto la función está desarrollada.
¿Cómo se hace desarrollo guiado por pruebas para una interfaz de usuario?
Escriba la prueba a partir del diseño en lugar del código.Una prueba que encuentra cada elemento por su aspecto y por lo que dice puede existir antes que la función.Falla mientras falta la función y se supera cuando lo desarrollado coincide con el diseño.
¿Qué es la deriva del diseño?
La deriva del diseño es la distancia que crece entre un diseño y el producto desarrollado a partir de él: palabras cambiadas, iconos que faltan, fuentes y espaciados que ya no coinciden.Pasa desapercibida cuando nadie compara lo desarrollado con el diseño.
¿Qué diferencia hay entre el QA de diseño y las pruebas de regresión visual?
El QA de diseño compara lo desarrollado con el diseño.Las pruebas de regresión visual comparan la compilación con una compilación anterior, así que se superan incluso cuando la primera compilación nunca coincidió con el diseño.
¿Qué le pasa a la prueba cuando cambia el diseño de Figma?
Exporte de nuevo el diseño y elija Sincronizar desde Figma en GUI Test Studio.Enumera cada cambio con una casilla, actualiza solo lo que usted deje marcado, y nunca sobrescribe una comprobación que usted mismo editó.
¿GUI Test Studio necesita acceso a mi cuenta de Figma?
No.El plugin guarda un archivo de diseño en su equipo, y GUI Test Studio lee ese archivo.No hay ninguna cuenta que conectar ni ningún token que crear, y no se envía nada a ninguna parte.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack y Applitools son marcas comerciales de sus respectivos propietarios.
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.