コードが存在する前に Figma のデザインからテストを生成する
コードが存在する前に Figma のデザインからテストを生成する: UI のテスト駆動開発、セレクターなしのデザイン QA、デザインと同期するアサーション。
読了 10 分更新日: 2026年11月6日執筆: Ait Nohaila (事業開発担当)
はい、コードが存在する前に Figma のデザインからエンドツーエンドテストを生成できます: GUI Test Studio の Figma プラグインが画面を 1 個のデザインファイルとして保存し、Figma からインポートがそれを要素ごとのアサーションを持つテストに変えます。
なぜ Figma のデザインからテストを生成するのか
デザイナーは、チームが持つ最も正確な仕様書をすでに書いています。Figma ファイルは、各画面が何を表示すべきかを語ります: 各ボタンの語句、アイコン、フィールドの順序、クリックの後に来る画面です。それなのに多くのチームは、数週間後に完成したアプリからエンドツーエンドテストを書き、その間はデザインを目で確認しています。
- デザイン駆動開発は、その順序を逆にします。これはテスト駆動開発ですが、最初のテストの元になる仕様書がコードではなくデザインです。デザインが承認されたその日に、Figma のデザインからテストを生成します。機能が存在しない間、テストは不合格です。ビルドがデザインに一致した日に合格します。それ以降は、デザインやコードが変わるたびに、ビルドの正直さを保ちます。
この記事では、テスト駆動開発、コードで書くエンドツーエンドテストを先に書けない理由、デザイン QA とデザインのずれとは何か、そしてデスクトップアプリと Web アプリのエンドツーエンドテストスイートである GUI Test Studio が Figma のデザインをどう実行できるテストに変えるかを説明します。
TDD、ATDD、BDD を 1 分で
3 種類とも、テストを先に書く方法です。違うのは、テストが何から書かれ、誰が読むかです。
| プラクティス | テストの元になるもの | 読む人 |
|---|---|---|
| テスト駆動開発 (TDD) | コードが持つべき小さな振る舞い | 開発者 |
| 受け入れテスト駆動開発 (ATDD) | チームがビジネス側と合意した受け入れ基準 | チーム全体 |
| 振る舞い駆動開発 (BDD) | 分かりやすい言葉のシナリオ、Cucumber のようなツールを使って Given、When、Then の形で書かれることが多い | チーム全体 |
TDD のループには 3 拍あります。レッド: 振る舞いがまだないので、不合格になるテストを書きます。グリーン: 合格させるのに必要なだけのコードを書きます。リファクタリング: テストが正しさを守る中で、コードを改善します。
なぜコードの前にエンドツーエンドテストを書けないのか
TDD は関数や API ではうまく機能します。ユーザーインターフェイスでは、たいてい止まります。その理由は、コードで書くエンドツーエンドテストが画面上の要素を見つける方法にあります。
Selenium、Playwright、Cypress のテストは、各要素をロケーターで見つけます: ID、CSS セレクター、XPath、ロールと名前です。Selenium は ID から XPath まで 8 種類のロケーター戦略を文書化しています。Cypress は、テストが触れるすべての要素に data-cy のような専用の属性を付けることを推奨しています。
cy.visit('/reports');
cy.get('[data-cy=export-pdf]')
.click();コードで書くビジュアルスナップショットも、ビルドから始まります。Playwright は最初の実行時にリファレンスのスクリーンショットを作るので、テストが比較する画像はデザインされたままのアプリではなく、作られたままのアプリです。Storybook と Chromatic は各コンポーネントのストーリーを承認済みのベースラインと比較し、ビルド間の変化を捉えます。
つまり実際には、エンドツーエンドテストは機能の後に、完成したアプリを見ている人によって書かれます。そしてそれは、設計どおりかどうかにかかわらず、アプリが今日している動作を続けていることを検証します。
デザイン QA とデザインのずれ
Definition
デザイン QA は、ビルドがデザインに一致しているかの確認です。多くのチームでは、デザインの引き渡しの後に目で行われます: デザイナーが Figma のフレームをステージングのアプリの横に置き、異なる点を列挙します。
Definition
デザインのずれは、誰も確認しないときにデザインと製品の間で広がっていく差です。コードでラベルの語句が変わります。フォントの太さがデザインシステムのものではありません。ある画面でアイコンが欠けています。個々の変化は小さいのに、合わさると製品は未完成に見えます。
Testsigma
すでにいくつかのツールが Figma からテストケースへ進んでいます。Testsigma の生成 AI は、Figma のチーム ID とアクセストークンを設定すれば、Figma のフレームからテストシナリオとテストケースを書きます。BrowserStack Test Companion は貼り付けた Figma のリンクを読み、テストケースか、使っているフレームワークの自動化スクリプトを書きます。Applitools Eyes は、自動テストが Figma のフレームをビジュアルベースラインとして使えるようにします。
書かれたテストケースは計画の大きな助けになりますが、人がそれを実行するかコードに変えなければなりません。生成されたスクリプトは、コードで書くどんなビジュアルテストとも同じく、機能が作られて初めて存在するロケーターを通して各要素に到達します。エンドツーエンドツールをより広く見渡すには、比較調査を参照してください。
Figma のデザインからエンドツーエンドテストを生成するには
それが GUI Test Studio の画面の検証方法です。ビジュアルアサーションは要素を見た目で見つけ、期待する画像と比較します。テキストアサーションは画面上の語句を読み取ります。デザインには、それらのアサーションに必要なすべての画像とすべての語句がすでにあります。
| Figma のデザインが持つもの | テストが得るもの |
|---|---|
| すべての画面 | 画面のリファレンス画像 |
| ラベル、タイトル、ボタンの語句 | その語句を待つテキストアサーション |
| 日付や金額のような変化する値 | 同じ種類の値を待つ動的テキストアサーション |
| アイコン、ロゴ、画像 | その画像を探すビジュアルアサーション |
| ヘッダーやフォームといった画面のセクション | セクションごとのグループアサーション (配置も検証できる) |
| プロトタイプのフローのリンク | ある画面から次の画面へ導くクリック |
デザイン
承認された Figma の画面
レッド
テストが不合格になる: 機能がまだない
ビルド
開発者または AI コーディングエージェントが機能を書く
グリーン
ビルドがデザインに一致する
UI のためのテスト駆動開発、手順を追って
- 1
承認されたデザインからテストを生成する
デザインが承認された日に、インポートしてください。これでテストは、誰かが機能を書く前に、デザインされたとおりの画面を記述します。
- 2
不合格になるのを見る: それがレッドのステップ
今日のアプリに対して実行してください。新しい画面がないので、そのアサーションは不合格になります。レッドこそが要点です: テストは、残っている作業の一覧です。
- 3
グリーンになるまで作る
開発者または AI コーディングエージェントが機能を作ります。パイプラインは gtr-cli ですべてのビルドでテストを実行します。信頼度レポートが、要素ごとに、デザインにすでに一致しているものとそうでないものを示します。
- 4
実際の見た目を一度採用する
フォントの描画がわずかに異なるため、デザインと実際の画面がピクセル単位で一致することはめったにありません。最初の実際の実行の後、信頼度レポートから実際の見た目を一度採用してください。それ以降、テストは実物と比較します。アプリが意図的に変わったときを参照してください。
- 5
テストを守りにしてリファクタリングする
アプリのスタイルを変え、リファクタリングし、フレームワークを変えてください。テストはコードを読まないので、画面が正しい間は合格し続けます。ユーザーに違いが見えるときに不合格になります。
Figma からインポート: 機能の前にテストを
- GUI Test Studio はこのすべてを Figma からインポートで行います。小さなプラグインが Figma の中で動き、デザインをデザインパッケージという 1 個のファイルに保存します。GUI Test Studio がそのファイルを拾い上げます。接続する Figma アカウントも、作成するアクセストークンもなく、どこにも何も送信されません。
Figma プラグイン
チェックした画面を 1 個のデザインファイルとして保存する
ダウンロードフォルダー
GUI Test Studio が監視し、ファイルを拾い上げる
レビュー
すべての要素と、それが得るアサーション
テスト
1 個のシナリオ: 画像、アサーション、クリック
- 1
Figma にプラグインを一度だけ追加する
プラグインは GUI Test Studio と一緒にインストールされます。Figma のデスクトップアプリで、プラグイン、開発、マニフェストからプラグインをインポート...から一度追加してください。
- 2
Figma からインポートを開く
GUI Test Studio でファイル、Figma からインポート...を選んでください: ウィンドウがデザインを待ちます。
- 3
Figma から画面をエクスポートする
Figma でプラグインを起動し、欲しい画面にチェックを入れるか、プロトタイプのフローを選んでください。するとその画面が、ある画面から次へ導くクリックと共に、順番に入ってきます。エクスポートされたファイルはダウンロードフォルダーに置いたままにしてください: GUI Test Studio がそのフォルダーを監視していて、1、2 秒以内にデザインを開きます。
- 4
検証される内容を確認する
テストに何かが届く前に、レビューがすべての要素とそのアサーションを一覧表示します。 - レビューは各画面をすべての要素を枠で囲んで表示し、それぞれがどのアサーションを得るかを示します。テキストは、画像上で本当に読み取れるときだけテキストとして検証されます。小さすぎたり薄すぎたりする語句は代わりにビジュアルアサーションになり、一覧がその理由を示します。長い段落と大きな写真は、たいていサンプルコンテンツなので、一覧には載りますがチェックは入りません。
- 5
「インポート」をクリックする
インポートをクリックすると、すべてがデザインの名前を付けた 1 個のシナリオとして配置されます。各画面はビジュアルリファレンストラックの画像になります。そのアサーションはアサーショントラックに、セクションごとにまとめて置かれます。プロトタイプのフローでは、次の画面へ導くクリックは、デザインがリンク元としたボタンに狙いを定めます。
デザイナーが「Sign in」のフローを仕上げます: Login、次に Dashboard、次に Settings です。フローをインポートすると、3 枚の画像、Sign in のクリック、設定の歯車のクリック、各画面のアサーションが得られます。テストは機能よりずっと前に準備できます。機能がステージングに届いた日、パイプラインが実際のアプリをクリックして進み、デザインに一致しているかどうかを要素ごとに報告します。
デザインが変わったら: Figma から同期
デザインは動き、デザインから書かれたテストはそれに付いていかなければなりません。デザインが変わったら、Figma からもう一度エクスポートし、GUI Test Studio でファイル、Figma から同期...を選んでください。
| デザインで変わったこと | 同期がすること |
|---|---|
| テキストの語句が変わった | アサーションは新しい語句を期待します。 |
| 要素の見た目が変わった | アサーションは新しい画像を取り込みます。 |
| 要素が移動した、またはサイズが変わった | アサーションがそれに付いていき、それを狙うクリックも同様です。 |
| 要素がなくなった | そのアサーションは削除されます。 |
| 要素が新しい | チェックなし: 求めない限り、新しいものは何も検証されません。 |
自分で編集したアサーションにもチェックは入らないので、同期が断りなく作業を上書きすることはありません。バックグラウンドで検証されることはなく、テストは同期したときだけ変わります。
AI アシスタントで Figma のデザインからテストへ
デザインを AI アシスタントに渡すこともできます。GUI Test Studio に接続した Claude、ChatGPT、または自分のコンピューター上のローカル AI モデル (当社が提供するものか、自分で用意するもの) が、同じインポートを通してデザインパッケージからテストを作ります。プロンプトからテストを作成するを参照してください。
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.テストが保存され、GUI Test Studio がそれを開いてレビューを待ちます。AI コーディングエージェントとの相性も良好です: エージェントが機能を作り、デザインから作られたテストが、デザインどおりに作られたかどうかを伝えます。AI エージェントとの開発を参照してください。
ベストプラクティス
Do
- テストが画面を順番にクリックして進むように、プロトタイプのフローをエクスポートしてください。
- 画面とセクションに Login や Header のような分かりやすい名前を付けてください: 各セクションのアサーションは、その名前を付けた 1 個のグループアサーションとして移動します。
- 初日から、レッドも含めて、すべてのビルドでテストを実行してください。
- 作られた機能の最初の実行の後、実際の見た目を一度採用してください。
Avoid
- プレースホルダーの段落やストック写真のようなサンプルコンテンツを検証すること。
- 最初のレッドの実行を壊れたテストとして扱うこと: それは、やるべき作業の一覧です。
- 同期で新しい要素をすべて見もせずにチェックすること。
- まだ存在しない画面のセレクターを書くこと。
Figma ファイルがありませんか?Sketch や Adobe XD など、どんなデザインツールの画像でも使えます: 実装前の機能をテストするを参照してください。
要点
- 1Figma のデザインはすでに仕様書です: テストが見つけるべきすべての語句、アイコン、画面を語っています。
- 2コードで書くエンドツーエンドテストは先には書けません: そのロケーターは、機能が作られて初めて存在するからです。
- 3Figma からインポートは機能の前にテストを生成します: 画面ごとの画像、要素ごとのアサーション、そしてクリックとしてのプロトタイプのフローです。
- 4レッド、そしてグリーン: テストはビルドがデザインに一致するまで不合格になり、その後はすべてのビルドでそれを守ります。
- 5Figma から同期はデザインに付いていき、自分で編集したアサーションを上書きすることはありません。
よくある質問
Figma のデザインからテストを生成できますか?
はい。GUI Test Studio の Figma プラグインが画面を 1 個のデザインファイルとして保存し、Figma からインポートがそれをエンドツーエンドテストに変えます: 画面ごとのリファレンス画像、要素ごとのアサーション、そしてプロトタイプのフローでは画面間のクリックです。機能が作られると、テストは実際のアプリに対して実行されます。
ユーザーインターフェイスでテスト駆動開発を行うには?
コードではなくデザインからテストを書いてください。各要素を見た目と語句で見つけるテストは、機能より前に存在できます。機能がない間は不合格になり、ビルドがデザインに一致すると合格します。
デザインファーストテストとは何ですか?
デザインファーストテストは、完成したコードではなく承認されたデザインからエンドツーエンドテストを書くので、テストは機能より前に存在します。機能がない間は不合格になり、ビルドがデザインに一致すると合格し、その後はすべてのビルドでデザインのずれを捉えます。GUI Test Studio は、Figma からインポートで、またはどんなデザインツールの画像からでも、これを行います。
デザインのずれとは何ですか?
デザインのずれとは、デザインとそこから作られた製品の間で広がっていく差のことです: 変わった語句、欠けたアイコン、もう一致しないフォントと間隔です。誰もビルドをデザインと照らし合わせないと、気づかれずに進みます。
デザイン QA とビジュアルリグレッションテストの違いは何ですか?
デザイン QA はビルドをデザインと照らし合わせます。ビジュアルリグレッションテストはビルドを以前のビルドと照らし合わせるので、最初のビルドがデザインに一致していなくても合格します。
Figma のデザインが変わると、テストはどうなりますか?
デザインをもう一度エクスポートして、GUI Test Studio で Figma から同期を選んでください。すべての変更がチェックボックス付きで一覧表示され、チェックを残したものだけが更新され、自分で編集したアサーションが上書きされることはありません。
GUI Test Studio には Figma アカウントへのアクセスが必要ですか?
いいえ。プラグインがコンピューターにデザインファイルを保存し、GUI Test Studio がそのファイルを読みます。接続するアカウントも、作成するトークンもなく、どこにも何も送信されません。
Figma、Selenium、Playwright、Cypress、Storybook、Chromatic、Cucumber、Testsigma、BrowserStack、Applitools は各所有者の商標です。
テスト対象のアプリでご覧になりますか? チームとの 30 分の無料相談を予約してください。