読み込み中...
投稿日
TIS AIChatLab：MagicPodをつかった自動テスト導入戦略
もくじ
TISでは全社のE2Eテスト自動化比率UPを目標に社内のMagicPodの利用推進を進めています。
本記事では、社内プロダクトであるTIS AIChatLabの実践例を通じて効果的なテスト自動化の導入方法をまとめました。
TIS AIChatLabとは
TIS AIChatLab（以下AIChatLab）は、社内情報検索にも対応したTIS社内向けAIチャットサービスです。ユーザーの質問や要求に対して、自然言語処理技術を使用して回答を生成します。AIChatLabにおけるLLMの応答評価に関しては、こちらの記事をご覧ください。
MagicPod導入の経緯
―MagicPod利用のきっかけは？
2024年1月にAIChatLabのアーキテクチャを大きく変更したことに併せて、MagicPodを利用開始しました。導入前は結合テストをエンジニアが手動で行っており、リリースごとの確認に時間がかかっていました。その負荷軽減を主な目的として、MagicPodを導入しました。
―MagicPodを選んだ理由は？
以下３点です。
・社内での利用開始手続き整備が進んでおり、利用開始しやすい
・社内で利用実績があり、サポートを受けやすい
・改修頻度が高いバックエンドと結合したエンドツーエンド（E2E）環境でのテストシナリオ作成・実行が行える
―導入にあたっての方針はありましたか？
画面テストに関しては「かける時間をいかに少なく抑えるか」を重視していました。
というのも、2024年1月当時はAIChatLabの検索・応答部分のブラッシュアップが急務で、エンジニアリソースはバックエンド改修に注力させたかったためです。アーキテクチャ変更はバックエンドがメインで、フロントエンドの改修はほとんどありませんでした。画面稼働も既にあるシステムなので、フロントエンドのテストを拡充するといった点ではなく「バックエンドと結合した環境でのリグレッションテストの効率化」を素早く実現することがポイントとなりました。
テストシナリオの作成について
―テストケースの洗い出しやケースの管理はどのように行なっていますか？
結合テストケースの洗い出しは、テスト観点カタログに沿って行い、ケース表はNotionで管理しています。
―MagicPodではどのような範囲のテストを実施していますか？
画面操作の網羅が主な範囲になります。ケース管理は、機能単位でフォルダ分けして、ユーザーの操作単位にシナリオを作成しています。シナリオ名=ケースNoとして、Notionのケース表との紐づきが判別できるようになっています。MagicPod上でのテストケースは現在約50ケースあります。
―MagicPodでは行わないとしているテストはありますか？
画面上に数秒だけ表示されるツールチップの表示確認など「キャプチャの取得タイミングがシビアなUI観点」は手動テストでの確認と整理しています。
MagicPodのテスト実行環境
―テストの実施環境について教えてください。
AIChatLabは社内向けのサービスでSSO認証を含むシステムです。許可されたユーザーのみアクセス可能の制御としており、テスト実行も社内の開発者ローカルPCから接続が必要です。テスト実行には「MagicPod Desktop」を使用し、開発者ローカルPCからテスト実行をしています。
―テストの実施環境面での工夫はありますか？
テストの再現性を保つための工夫が３つあります。
１.LLM応答部分のMock化
AIによるチャット回答は都度LLMのAPIコールをせず、常に同一の結果が返されるようにMockを使って応答するようにしています。LLMの応答自体は画面テストの観点ではないため、実行都度のビジュアルコンペアで差分が出ないようにしています。
２.動的表示順序の固定化
AIChatLabのチャット開始画面に表示する「プロンプトテンプレート」は、画面表示のたびに複数種類をランダム表示とする画面仕様になっています。こちらも常に同一の結果が返されるように、テスト環境ではプログラムのパラメータ設定により、表示順序を固定設定としています。
⒊トランザクションデータのクリーン処理
トランザクションデータの堆積によるロケータ位置の動的なずれを防止するため、チャットスレッドのデータクリーン処理を実装しています。現在はテスト環境専用のデータクリーンボタンを用意し、テストシナリオ内でボタン押下する方式を採用しています。今後はMagicPodのWebAPIコール機能を活用したAPI呼び出し方式へ移行する予定です。
テスト自動化の導入メリット
―どのような頻度でMagicPodのテスト実行をしていますか？
実行するタイミングはリリース前の結合テスト時です。そこでテストを一括実行し、不具合がないかを確認しています。本番リリース予定の約1週間前に一括実行を行い、問題があれば修正を行います。これまで結合テスト起因の遅延なくリリースできています。
―MagicPod導入による工数削減効果はありましたか？
手動で1週間かかっていたリグレッションテストの負荷を大きく下げることができました。テストを実行し、テストに問題が発生したときのみに人が修正を行うため、大幅な工数削減ができています。テストケースの作成も短期間に行えました。
―他にどのようなメリットがありますか？
ビジュアルリグレッションテストを行うにあたってのテスト結果の管理面でMagicPodは優秀だと感じています。スクリーンショットをMagicPod内で管理できるため、エビデンスの管理が不要です。その管理設計をする必要がないところも開発チームにとってメリットでした。おかげでスピーディーに導入ができました。
―テストのアサーション(テストの実行結果を判定するための確認)のステップでは、どの確認コマンドを使用していますか？
リグレッションテスト観点では、基本「画像差分確認」を使用しています。
自動テスト導入戦略のポイント
―自動テスト戦略を考えるうえで重視するポイントがあれば教えてください。
どの段階で自動テストの整備に着手するかで重視するポイントが変わると考えています。AIChatLabはプロダクトリリース後に後追いで自動テストの整備に着手したケースに該当します。
MVPフェーズでは自動テストの整備を後回しにする選択をし、プロダクトが成長期に入ると品質担保のための後追いで自動テスト導入を検討するプロジェクトも多いかと思います。
リリース後の自動テスト導入戦略
―リリース後のプロダクトに自動テストを導入する際、どのようなアプローチを取るべきでしょうか？
AIChatLabでは２つの戦略を組み合わせました。戦略１はバックエンドの検索・応答部分であり、戦略２がご紹介したMagicPodを用いた画面テストの部分です。
| 戦略１：重要機能優先アプローチ | ビジネスインパクトの大きい機能から優先的にテストを整備していく方法 |
| 戦略２：新機能連動型アプローチ | 新機能開発に合わせて、関連する既存機能のテストも同時に整備していく方法 |
どちらの領域も完璧なテストカバレッジを目指すのではなく、ビジネス価値と開発効率のバランスを重視してスコープを決定することが重要です。
―どこまでの範囲をMagicPodで自動化すると良いでしょうか？
AIChatLabは画面操作の網羅テストをMagicPodにて実行していますが、ある程度の規模があるシステムであれば、単体テストとMagicPodで行うテストの範囲をしっかりと切り分けて運用することが重要だと考えています。
E2Eテストは実際にアプリケーションを動かすという性質上、テストコードを動作させることに比べてどうしても時間がかかってしまいます。クリティカルパスの機能部分を優先的に自動化しつつ、テスタブルな設計へと段階的に移行することが求められます。
段階的な移行のためにも「E2Eテストから自動化を始める」は有効な戦略 です。
―自動テストを導入する際、指標とすべきものはありますか？
プロダクト開発の価値源泉は開発チームであり、チームが価値にフォーカスできる時間を増やすことでビジネス価値へと転換されます。テスト自動化による開発チームへのポジティブな影響は大きく、自動化を早期に実現できるとその効果をさらに大きくできます。導入時の指標として「自動化着手からN日でクリティカルパスのテスト整備完了」といった開発チームへの価値提供を先行指標とするのは理に適った考え方だと思います。
参考：MagicPodスタートガイド：テスト自動化の習慣を最速で定着させる
テスト資源のメンテナンスコストを抑える
―自動テストをメンテナンスしていく際に、留意すべき点はありますか？
できる限りテスト資源を再利用する、重複したテスト資源をつくらないことです。自動テストの保持のためにメンテナンスコストが上がってしまっては本末転倒です。しかし、一方で陥りがちな罠でもあります。
テスト資源の再利用の容易さ
MagicPodでは、テストコードの再利用が容易です。テストシナリオ単位の再利用も容易ですし、ステップ単位の共通化も後からでも簡単に行えます。テスト資源のメンテナンスの保持コストの低く抑えることができるのが、提供ツールを使用する最も大きなメリットかもしれません。
さいごに
「MagicPod導入におけるテスト戦略」と題して、MagicPodを導入するにあたってのTIS AIChatLabチームの戦略についてお聞きしました。プロダクトの性質によってMagicPodで行うべきテストの範囲が変わること、メンテナンス性の高いテストケースの分割の重要性が改めてわかりました。
まとめ
プロダクト開発におけるテスト自動化は、単なる品質保証ツールではなく、開発チームの生産性を高める戦略的な投資として捉える必要があります。
特に注目すべきは、フェーズに応じた柔軟な導入戦略と、重要機能優先・新機能連動型の2つのアプローチの組み合わせです。MVPフェーズでは開発速度を優先し、成長期に入ってから段階的に自動化を進めるという現実的なアプローチが提示されました。
また、E2Eテストからの着手という具体的な戦略は、実際のアプリケーション動作を確認できる点で、特に価値があります。さらに、テスト資源の再利用と共通化による保守性の向上は、長期的な運用コストの削減に貢献します。
MagicPodの利用推進 施策について
TISでは全社のE2Eテスト自動化比率UPを目標に社内のMagicPodの利用推進を進めています。モバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応しており、豊富な機能と高いメンテナンス性でリリースサイクルの高速化を支援します。
現在、社内では10件のプロジェクトにMagicPodを導入しています。他チームの活用事例は以下をご覧ください。
