Vibe Coding Week参加記：画面仕様と実画面比較の自動化試行

はじめに

こんにちは！KINTOテクノロジーズQAグループで主にWebフロントエンド案件を担当しているoshimaです。
弊社は全社を挙げてAI利用を推進していますが、その波に乗って先月生成AIコーディング企画”Vibe Coding Week”が行われました。この企画で私がチャレンジした内容についてご紹介いたします。
Vibe Coding Week企画そのものの説明は他の記事をご参照いただければと思います。

背景

私自身、通常業務でコーディングをほとんど行うことはありません。一方、私の担当する案件については一つ一つのリリースサイクルが速いことと、同じ期間に複数の案件が重複することで、効率の良いテストが求められていました。
となればテスト自動化が一つのカギになります。実際グループではPlaywrightを用いての自動化が推進されてきました。が、私自身は残念ながら「コードの書けない人」です。これまでは出来る同僚に依頼するなどの方法でしのいできましたが、いつまでも当てにし続けられない（なかなか手が空かない）という状態が続いていました。

救世主！？

自動化出来れば効率アップできそうな案件関連のネタは持っている。ただ、自身のスキルではどうしようもなかった。そんなもどかしい状態を打ち砕いてくれたのが生成AIです。
やりたいテスト（条件と期待値、制約条件など）がはっきりしていて、AIに正しく伝えることができれば、お望みのコードを生成してくれる。これならコーディングできない自分でも自動化に対して立ち向かっていける。業務の効率化のみならず、今まで自分が越えられなかった壁を越えてくれる（かもしれない）、救世主のような存在がAIでした。

チャレンジ企画との親和性

日本語のプロンプトでPlaywrightによる自動テストコードを生成していこうという取り組みは、先述のVibe Coding Week企画関係なく自然発生的なものでした。なので、企画発表があった時点で、企画意図に沿った内容の報告ができるのではないか？という感触を持っていました。

適用案件の特徴

通常業務での効率化の対象とした案件、そしてチャレンジ企画で取り組んだ案件が、社内では「静的資材」案件と呼ばれているものです。主にはKINTO ONEのサービスで取り扱う車種の仕様をお客様に紹介するためのページや契約内容の案内ページなどの確認を行う案件です。
例：トヨタ ヤリスの紹介ページ

特徴

車種紹介のページになると、KINTOで取り扱う車種が増えるごとに案件が成立しますが、ページレイアウトや項目は全車種共通。異なるのは画像と価格などのため、確認する内容は車種が変われども同じという案件の特徴がありました。

通常のテストでの作業内容

通常のテストで実施していた内容は以下となります。

• 全体デザインがFigmaで作成されたデザインと比較して差異がなく、またレイアウトの崩れがないこと
• 表示されている価格・サイズ・燃費などの各種データが指定ファイルと同じであること
• 画面内のボタンやリンクの遷移先が仕様通りであること

これらの確認を今までは目視確認で行ってきました。原始的なやり方ですが、ある程度不具合指摘もできていたのですが、数が重なってくるとこれでは厳しくなってきます。上記の確認3項目については、うまくやれば自動で済みそうな内容です。
幸い試験時にはFigmaでの画面デザイン、価格表や燃費・サイズの記載された諸元表の指定ファイルは提示されます。材料はあります。なので、テスト対象ページの記載内容と自動で比較は特に問題なくできるのではないかという仮説を立て、チャレンジしてみました。

チャレンジ企画での取り組み

全体デザインの自動比較

デザインの比較については、次の手順で取り組みました。

• テスト対象の該当Figmaページからコンポーネント情報を抽出してJSONに出力を試みる
  • 全部だと情報量が多く読み込みに失敗
• 抽出する情報を位置情報に絞って相対位置比較でレイアウト崩れ確認に移行
  • レイヤーやID情報などが複雑で、ほしい情報を整理するのに苦労
  • 実画面情報との解像度の差もあって、単純な比較でエラー頻発
    残念ながらこのチャレンジ期間ではデザイン周りはうまくいきませんでした。

価格などの表示情報の自動比較

こちらについては、次の手順で取り組みました

• テストページの表示情報を抽出してJSONに出力を試みる
  • 通常テキストは余裕でしたが表形式は項目名指定で工夫が必要でした
• 元データ（Excel）から情報抽出して同様にJSON出力
  • 比較をしたいので「基本性能・主要装備」と「プラン別ご利用料イメージ」部分を抽出
  • 結果的にうまくいきましたが、実はいろいろ試行錯誤し、結局はセル番号指定でのベタな指令に落ち着きました。
• 作成された2つのJSONを比較
  • ここまでくると問題なく実行完了
    テキスト情報は比較的スムーズにうまくいきました。

リンク遷移先の確認

こちらは全部終わらなかったのですが、時間かければできそうな実感がありました。

• ボタンに設定されたリンク先の取得は問題なし
• 目視の方が速そうなので比較の自動化までは実施せず

チャレンジ企画の成果

ポイントは、単純に情報抽出してくださいではなく、テストコードをタイプスクリプト形式で実装し、Playwrightで実行したことです。このコードを生成しておくことで、他の車種や元データファイルが変わっても少しの改変で対応できるようになりました。
今まで目視確認で行っていたテスト内容を一部でも自動化出来たことは一つの成果ですが、できていない箇所や、より効率的にテストが進められる改善の余地は、残念ながらまだまだ多いです。
とはいえ、チャレンジ企画の短期間である程度できたことも確かです。地道に継続することで、出来てない部分を埋めていけると思います。

未来への妄想 -まとめにかえて-

自動化でできることはとことん自動化ツールでの確認に任せて、人間でしか確認できない箇所を追求する。効率化で時間的な余裕を生み、結果として人力でのテストの質の向上まで図ることができれば理想的です。
現段階ではまだまだ妄想です。ただ、コーディングできない人間でもある程度の自動化ができる時代になった今、妄想の実現は決して遠くない未来にあるのではという期待感も持っています。
チャレンジ企画で対応した案件以外での取り組みも含め、少しずつでも歩みを進めていこうと思います。