Tests aus Figma-Designs erzeugen, bevor der Code existiert
Erzeugen Sie Tests aus Figma-Designs, bevor der Code existiert: testgetriebene Entwicklung für die Oberfläche, Design-QA ohne Selektoren und Prüfungen, die dem Design folgen.
10 Min. LesezeitVom Team von GUI Test Studio
Warum Tests aus Figma-Designs erzeugen?
Ihre Designerinnen und Designer haben bereits die genaueste Spezifikation geschrieben, die es in Ihrem Team gibt.Eine Figma-Datei sagt, was jeder Bildschirm zeigen muss: die Wörter auf jeder Schaltfläche, die Symbole, die Reihenfolge der Felder, den Bildschirm, der nach einem Klick kommt.Dennoch schreiben die meisten Teams ihre End-to-End-Tests erst Wochen später, anhand der fertigen App, und prüfen das Design in der Zwischenzeit mit bloßem Auge.
Designgetriebene Entwicklung kehrt diese Reihenfolge um.Sie ist testgetriebene Entwicklung, bei der das Design, nicht der Code, die Spezifikation ist, aus der der erste Test entsteht.Sie erzeugen Tests aus Figma-Designs an dem Tag, an dem das Design freigegeben wird.Der Test schlägt fehl, solange es die Funktion nicht gibt.Er besteht an dem Tag, an dem der Build dem Design entspricht.Von da an sorgt er dafür, dass der Build dem Design treu bleibt, wann immer sich das Design oder der Code ändert.
Dieser Artikel erklärt testgetriebene Entwicklung, warum sich codierte End-to-End-Tests nicht zuerst schreiben lassen, was Design-QA und Design-Drift sind und wie GUI Test Studio, eine Suite für End-to-End-Tests von Desktop-Apps und Web-Apps, aus einem Figma-Design einen lauffähigen Test macht.
TDD, ATDD und BDD in einer Minute
Alle drei sind Wege, den Test zuerst zu schreiben.Sie unterscheiden sich darin, woraus der Test geschrieben wird und wer ihn liest.
| Methode | Grundlage des Tests | Wer ihn liest |
|---|---|---|
| Testgetriebene Entwicklung (TDD) | Ein kleines Stück Verhalten, das der Code haben muss | Das Entwicklungsteam |
| Akzeptanztestgetriebene Entwicklung (ATDD) | Die Akzeptanzkriterien, die das Team mit dem Fachbereich vereinbart hat | Das ganze Team |
| Verhaltensgetriebene Entwicklung (BDD) | Szenarien in einfachen Worten, oft als Given, When, Then geschrieben, mit einem Tool wie Cucumber | Das ganze Team |
Der Zyklus von TDD hat drei Takte.Rot: Schreiben Sie einen Test, der fehlschlägt, weil das Verhalten noch nicht da ist.Grün: Schreiben Sie gerade genug Code, damit er besteht.Refactoring: Verbessern Sie den Code, während der Test ihn korrekt hält.
Tests auf diese Weise nach vorne zu verlegen, nennt man oft Shift-Left-Testing.Ein Fehler, der gefunden wird, bevor eine Funktion ausgeliefert ist, lässt sich günstiger beheben.Ein zuerst geschriebener Test ist außerdem eine Spezifikation, die niemand missverstehen kann.
Warum lässt sich ein End-to-End-Test nicht vor dem Code schreiben?
TDD funktioniert gut für Code-Funktionen und APIs.An der Benutzeroberfläche hört es meist auf.Der Grund liegt darin, wie codierte End-to-End-Tests Dinge auf dem Bildschirm finden.
Ein Test mit Selenium, Playwright oder Cypress findet jedes Element über einen Locator: eine ID, einen CSS-Selektor, einen XPath, eine Rolle und einen Namen.Selenium dokumentiert acht Locator-Strategien, von der ID bis zum XPath.Cypress empfiehlt ein eigenes Attribut, etwa data-cy, an jedem Element, das ein Test berührt.
Jeder davon ist eine Tatsache über den Code.Solange es den Code nicht gibt, gibt es keine ID zum Auswählen und kein Attribut, auf das sich zeigen ließe.Page Objects, die Klassen, die jeden Bildschirm für die Tests kapseln, werden gegen genau dieses Markup geschrieben.
Auch codierte visuelle Snapshots gehen vom Build aus.Playwright erstellt seine Referenz-Screenshots beim ersten Lauf, sodass das Bild, mit dem ein Test vergleicht, die App ist, wie sie gebaut wurde, nicht wie sie entworfen wurde.Storybook mit Chromatic vergleicht jede Komponenten-Story mit ihrer freigegebenen Baseline, was Änderungen zwischen Builds erkennt.
In der Praxis wird der End-to-End-Test also nach der Funktion geschrieben, von jemandem, der die fertige App betrachtet.Er prüft dann, dass die App weiterhin tut, was sie heute tut, ob das nun dem Entwurf entspricht oder nicht.
Design-QA und Design-Drift
Design-QA ist die Prüfung, ob der Build dem Design entspricht.In den meisten Teams geschieht sie mit bloßem Auge nach der Design-Übergabe: Jemand aus dem Designteam legt den Figma-Frame neben die Staging-App und listet auf, was abweicht.
Design-Drift ist die Lücke, die zwischen dem Design und dem Produkt wächst, wenn niemand prüft.Eine Beschriftung bekommt im Code neue Wörter.Eine Schriftstärke ist nicht die aus dem Designsystem.Auf einem Bildschirm fehlt ein Symbol.Jede Änderung ist klein, und zusammen lassen sie das Produkt unfertig aussehen.
Visuelle Regressionstests schließen diese Lücke nicht von allein.Sie vergleichen den heutigen Build mit einem früheren Build, sodass ein Bildschirm, der nie seinem Design entsprach, jedes Mal besteht.
Mehrere Tools führen bereits von Figma zu Testfällen.Die generative KI von Testsigma schreibt Testszenarien und Testfälle aus Figma-Frames, sobald eine Figma-Team-ID und ein Zugriffstoken eingerichtet sind.BrowserStack Test Companion liest einen eingefügten Figma-Link und schreibt Testfälle oder Automatisierungsskripte in Ihrem Framework.Applitools Eyes lässt einen automatisierten Test einen Figma-Frame als visuelle Baseline verwenden.
Geschriebene Testfälle sind eine echte Hilfe bei der Planung, aber ein Mensch muss sie trotzdem ausführen oder in Code umsetzen.Ein erzeugtes Skript erreicht, wie jeder codierte visuelle Test, jedes Element weiterhin über einen Locator, den es erst gibt, wenn die Funktion gebaut ist.Einen breiteren Blick auf End-to-End-Tools bietet die Vergleichsstudie.
Wie erzeugen Sie End-to-End-Tests aus einem Figma-Design?
Ein Test lässt sich nur dann aus einem Design schreiben, wenn er den Code nicht braucht.Er muss jedes Element so finden, wie es ein Mensch tut: daran, wie es aussieht, und daran, was es sagt.
Genau so prüft GUI Test Studio einen Bildschirm.Eine Bildprüfung findet ein Element am Aussehen und vergleicht es mit dem Bild, das Sie erwarten.Eine Textprüfung liest die Wörter auf dem Bildschirm.Ein Design enthält bereits jedes Bild und jedes Wort, das diese Prüfungen brauchen.
| Was das Figma-Design enthält | Was der Test erhält |
|---|---|
| Jeder Bildschirm | Ein Referenzbild des Bildschirms |
| Die Wörter einer Beschriftung, eines Titels oder einer Schaltfläche | Eine Text-Assertion, die auf diese Wörter wartet |
| Ein Wert, der sich ändert, etwa ein Datum oder ein Betrag | Eine Dynamische Text-Assertion, die auf einen Wert derselben Art wartet |
| Ein Symbol, ein Logo oder ein Bild | Eine Bild-Assertion, die nach diesem Bild sucht |
| Die Abschnitte eines Bildschirms, etwa seine Kopfzeile oder sein Formular | Eine Gruppen-Assertion pro Abschnitt, die auch die Anordnung prüfen kann |
| Die Verknüpfungen eines Prototyp-Ablaufs | Die Klicks, die von einem Bildschirm zum nächsten führen |
Design
Die freigegebenen Figma-Bildschirme
Rot
Der Test schlägt fehl: Die Funktion ist noch nicht da
Umsetzung
Jemand aus der Entwicklung oder ein KI-Coding-Agent schreibt die Funktion
Grün
Der Build entspricht dem Design
Testgetriebene Entwicklung für die Benutzeroberfläche, Schritt für Schritt
- 1
Den Test aus dem freigegebenen Design erzeugen
Importieren Sie das Design an dem Tag, an dem es freigegeben wird.Der Test beschreibt den Bildschirm nun so, wie er entworfen wurde, bevor irgendjemand die Funktion schreibt.
- 2
Den Test fehlschlagen sehen: Das ist der rote Schritt
Führen Sie ihn mit der heutigen App aus.Der neue Bildschirm ist nicht da, also schlagen seine Prüfungen fehl.Genau darum geht es bei Rot: Der Test ist die Liste der noch offenen Arbeit.
- 3
Bauen, bis er grün wird
Jemand aus der Entwicklung oder ein KI-Coding-Agent baut die Funktion.Ihre Pipeline führt den Test bei jedem Build mit gtr-cli aus.Der Konfidenzbericht sagt Element für Element, was dem Design schon entspricht und was nicht.
- 4
Das echte Aussehen einmal übernehmen
Ein Design und ein echter Bildschirm stimmen selten pixelgenau überein, weil Schriften ein wenig anders gezeichnet werden.Übernehmen Sie nach dem ersten echten Lauf einmal das tatsächliche Aussehen aus dem Konfidenzbericht.Von da an vergleicht der Test mit dem Echten.Siehe Wenn sich die App absichtlich ändert.
- 5
Mit dem Test als Schutz refaktorisieren
Gestalten Sie die App neu, refaktorisieren Sie sie, wechseln Sie ihr Framework.Der Test liest Ihren Code nicht, also besteht er weiter, solange der Bildschirm stimmt.Er schlägt fehl, wenn ein Nutzer einen Unterschied sehen würde.
Aus Figma importieren: der Test vor der Funktion
GUI Test Studio erledigt all das mit „Aus Figma importieren“.Ein kleines Plugin läuft in Figma und speichert Ihr Design als eine Datei, ein Designpaket.GUI Test Studio holt sich diese Datei.Es gibt kein Figma-Konto zu verbinden und kein Zugriffstoken zu erstellen, und nichts wird irgendwohin gesendet.
Das Plugin wird mit GUI Test Studio installiert.Sie fügen es einmal in der Desktop-App von Figma hinzu, unter Plugins, Development, Import plugin from manifest....
Wählen Sie in GUI Test Studio Datei, Aus Figma importieren...: Das Fenster wartet auf Ihr Design.Starten Sie in Figma das Plugin und aktivieren Sie die gewünschten Bildschirme, oder wählen Sie einen Prototyp-Ablauf.Seine Bildschirme kommen dann der Reihe nach, mit den Klicks, die von einem zum nächsten führen.Lassen Sie die exportierte Datei in Ihrem Ordner „Downloads“: GUI Test Studio beobachtet diesen Ordner und öffnet das Design innerhalb von ein, zwei Sekunden.
Die Überprüfung zeigt jeden Bildschirm mit einem Rahmen um jedes Element und sagt, welche Prüfung jedes erhält.Ein Text wird nur dann als Text geprüft, wenn er auf dem Bild wirklich lesbar ist.Zu kleine oder zu blasse Wörter erhalten stattdessen eine Bildprüfung, und die Liste sagt, warum.Lange Absätze und große Fotos werden aufgeführt, aber nicht aktiviert, weil sie meist Beispielinhalt sind.
Klicken Sie auf „Importieren“, und alles landet als ein Szenario, das nach Ihrem Design benannt ist.Jeder Bildschirm wird zu einem Bild auf der Spur „Bildreferenz“.Seine Prüfungen kommen auf die Spur „Assertionen“, nach Abschnitten gruppiert.Bei einem Prototyp-Ablauf zielt der Klick, der zum nächsten Bildschirm führt, auf die Schaltfläche, von der das Design verknüpft.
Ein Design sagt nicht, wo das Fenster der App stehen wird, deshalb durchsuchen diese Prüfungen den gesamten Bildschirm.Sie vergleichen mit einer großzügigen Strenge, sodass die kleinen Darstellungsunterschiede zwischen einem Design und einem echten Bildschirm toleriert werden, während ein fehlendes Element oder ein geändertes Wort die Prüfung weiterhin fehlschlagen lässt.
Ihr Designteam stellt den Ablauf „Sign in“ fertig: Login, dann Dashboard, dann Settings.Sie importieren den Ablauf und erhalten drei Bilder, den Klick auf „Sign in“, den Klick auf das Zahnrad der Einstellungen und die Prüfungen jedes Bildschirms.Der Test ist fertig, lange bevor die Funktion es ist.An dem Tag, an dem die Funktion die Staging-Umgebung erreicht, klickt sich die Pipeline durch die echte App und meldet Element für Element, ob sie dem Design entspricht.
Wenn sich das Design ändert: Aus Figma synchronisieren
Designs verändern sich, und ein aus einem Design geschriebener Test muss sich mit ihnen verändern.Wenn sich das Design ändert, exportieren Sie es erneut aus Figma und wählen Sie dann Datei, Aus Figma synchronisieren... in GUI Test Studio.
| Was sich im Design geändert hat | Was eine Synchronisierung tut |
|---|---|
| Ein Text lautet anders | Die Prüfung erwartet die neuen Wörter. |
| Ein Element sieht anders aus | Die Prüfung übernimmt das neue Bild. |
| Ein Element wurde verschoben oder hat seine Größe geändert | Die Prüfung folgt ihm, und ein darauf gezielter Klick ebenfalls. |
| Ein Element ist nicht mehr da | Seine Prüfung wird entfernt. |
| Ein Element ist neu | Nicht aktiviert: Nichts Neues wird geprüft, solange Sie es nicht verlangen. |
Eine Prüfung, die Sie selbst bearbeitet haben, ist ebenfalls nicht aktiviert, sodass eine Synchronisierung Ihre Arbeit nie ungefragt überschreibt.Nichts wird im Hintergrund geprüft: Der Test ändert sich nur, wenn Sie synchronisieren.
Genau das hält Design-Drift sichtbar.Wenn sich das Design ändert und der Build nicht folgt, schlägt der synchronisierte Test fehl und sagt, welches Element abweicht.
Vom Figma-Design zum Test mit einem KI-Assistenten
Sie können das Design auch einem KI-Assistenten übergeben.Claude, ChatGPT oder ein lokales KI-Modell auf Ihrem eigenen Computer, eines von uns oder Ihr eigenes, mit GUI Test Studio verbunden, erstellt den Test aus dem Designpaket über denselben Import.Siehe Einen Test aus einem Prompt erstellen.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.Der Test wird gespeichert, und GUI Test Studio öffnet sich damit, bereit für Ihre Durchsicht.Das passt gut zu einem KI-Coding-Agenten: Der Agent baut die Funktion, und der aus dem Design erstellte Test sagt Ihnen, ob er gebaut hat, was entworfen wurde.Siehe Entwicklung mit KI-Agenten.
Bewährte Methoden
Do
- Exportieren Sie den Prototyp-Ablauf, damit sich der Test der Reihe nach durch die Bildschirme klickt.
- Geben Sie Bildschirmen und Abschnitten klare Namen, etwa Login und Header: Die Prüfungen jedes Abschnitts reisen als eine Gruppen-Assertion, die nach ihnen benannt ist.
- Führen Sie den Test vom ersten Tag an bei jedem Build aus, auch wenn er rot ist.
- Übernehmen Sie das echte Aussehen einmal, nach dem ersten Lauf der gebauten Funktion.
Avoid
- Beispielinhalte prüfen, etwa Platzhalterabsätze und Stockfotos.
- Den ersten roten Lauf als kaputten Test behandeln: Er ist die Liste der zu erledigenden Arbeit.
- Bei einer Synchronisierung jedes neue Element aktivieren, ohne es anzusehen.
- Selektoren für einen Bildschirm schreiben, den es noch nicht gibt.
Keine Figma-Datei?Bilder aus jedem beliebigen Designtool, etwa Sketch oder Adobe XD, funktionieren ebenfalls: siehe Eine Funktion testen, bevor es sie gibt.
Fragen
Können Sie Tests aus Figma-Designs erzeugen?
Ja.Das Figma-Plugin von GUI Test Studio speichert Ihre Bildschirme als eine Designdatei, und „Aus Figma importieren“ macht daraus einen End-to-End-Test: ein Referenzbild pro Bildschirm, eine Prüfung pro Element und, bei einem Prototyp-Ablauf, die Klicks zwischen den Bildschirmen.Der Test wird mit der echten App ausgeführt, sobald die Funktion gebaut ist.
Wie funktioniert testgetriebene Entwicklung für eine Benutzeroberfläche?
Schreiben Sie den Test aus dem Design statt aus dem Code.Ein Test, der jedes Element daran findet, wie es aussieht und was es sagt, kann vor der Funktion existieren.Er schlägt fehl, solange die Funktion fehlt, und besteht, sobald der Build dem Design entspricht.
Was ist Design-Drift?
Design-Drift ist die Lücke, die zwischen einem Design und dem daraus gebauten Produkt wächst: geänderte Wörter, fehlende Symbole, Schriften und Abstände, die nicht mehr passen.Das fällt nicht auf, solange niemand den Build mit dem Design abgleicht.
Was ist der Unterschied zwischen Design-QA und visuellen Regressionstests?
Design-QA gleicht den Build mit dem Design ab.Visuelle Regressionstests gleichen den Build mit einem früheren Build ab, sodass sie auch dann bestehen, wenn schon der erste Build nie dem Design entsprach.
Was passiert mit dem Test, wenn sich das Figma-Design ändert?
Exportieren Sie das Design erneut und wählen Sie in GUI Test Studio „Aus Figma synchronisieren“.Die Synchronisierung listet jede Änderung mit einem Häkchen auf, aktualisiert nur, was Sie aktiviert lassen, und überschreibt nie eine Prüfung, die Sie selbst bearbeitet haben.
Braucht GUI Test Studio Zugriff auf mein Figma-Konto?
Nein.Das Plugin speichert eine Designdatei auf Ihrem Computer, und GUI Test Studio liest diese Datei.Es gibt kein Konto zu verbinden, kein Token zu erstellen, und nichts wird irgendwohin gesendet.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack und Applitools sind Marken ihrer jeweiligen Inhaber.
Bereit, Ihren ersten Test aufzuzeichnen?
Jede Funktion, 15 Tage lang.
Lieber an der Art von App sehen, die Sie testen?Buchen Sie ein kostenloses 30-minütiges Gespräch mit unserem Team.