テストの各レベルは、ソフトウェア開発においてそれぞれ固有の役割を持ち、それぞれ異なる問いに答えます。
単体テスト - 「変わってはいけない関数が変わっていないか?」 コードの最小単位(個々の関数やメソッド)を、システムの他の部分から切り離して個別にテストします。(単体テストの詳細な分析は、別のブログ記事で取り上げています。)
結合テスト - 「変更後も、コンポーネント同士が正しく連携して動くか?」 孤立した関数だけでなく、モジュール間の実際の接続(たとえば、データベース + サービス層 + API)をテストします。個々の部分は単独では通るのに、組み合わせると失敗するシナリオを明らかにします。
E2E(エンドツーエンド)テスト - 「実際のユーザーが体験するとおりにシステムが動くか?」 実際のUIやAPIを通じて、ユーザーの一連のワークフロー(ログイン → 操作 → 結果)全体をシミュレートします。これらの問題は実際のワークフローの中でしか表面化しないため、単体テストにも結合テストにも検出できないリグレッションを捉えます。
(もちろん、他にも *スモークテスト**、負荷テスト、セキュリティテストなどの種類がありますが、本記事の対象外です。)*
自動テストのどのレベルにも共通する目的は、現在取り組んでいるタスクの範囲外で機能が壊れていないことを検証することです。タスクが仕様どおりに完璧に完了していても、意図しない副作用として別の何かが壊れていることがあります。具体的な変更の範囲を超えて検証するテストの層がなければ、ユーザーが本番環境で問題を報告するまで、誰も気づきません。
手動テストの欠かせない役割
高度な自動化やAIの統合が進んでも、手動テストは不可欠で第一義的な役割を保ち続けています。人間のテスターは、本物の判断力と直感、そして自動化されたスクリプトが簡単に見落とす微妙なニュアンスや予期しないUIの挙動を見抜く力を備えています。手動での確認は、アプリケーションが実際のユーザーに提供できる状態にあると、開発チームが100%の確信を持てる拠り所であり、これまでも、今も、これからもそうあり続けます。
AI支援開発と「盲点」の補完
AI支援開発の時代には、自動テストの層はいっそう重要になります。AIエージェントはシステム全体を一度に認識することができないため、完全なコンテキストと過去の意思決定の履歴を持つ人間の開発者よりも、副作用が起こりやすくなります。テストは、コードが人間による最終承認に届く前に、このシステムに対する盲点を体系的に補うための仕組みとして機能します。
実務上の影響:AIによるE2Eテストの難しさ
E2Eテストの作成は、AIにとって特に複雑です。テストスクリプトを書くだけでなく、ソフトウェアが(多くの場合、テストのごく一部のために)使える適切なテストデータを準備することが中心になります。このデータの準備は非常に手間がかかります。
一見単純な操作を考えてみましょう。ドロップダウンリストをクリックして、パラメータ(たとえばドキュメントの種類 請求書)を選択する操作です。テストが失敗したり完了しなかったりした場合、根本原因を正確に診断することが重要です。次のような状況が起こりえます。
- AIが道に迷い、UI上にあるはずのドロップダウン要素を見つけられなかった。
- テストが経路の手前でエラーに遭遇し、復帰できなかった。
- ドロップダウンは存在するが、選択すべき期待どおりのデータが含まれていない。
- AIがJavaScript(目に見えない回避策)に頼り、プログラムから値を設定することには成功したが、実際のユーザーからは見えないままになっている。
1つのドロップダウンの周辺でも、多くの問題が起こりえます。重要なのは、AI(または評価システム)が本物のバグと、他の原因による連鎖的な失敗を区別できるかどうかです。データの保存に成功しただけでは、すべてが正常に動いているとは限りません。
振る舞いに基づくアプローチとテストカバレッジ
このため、テストは常にシステムの振る舞いの側面に焦点を当て、実際に起こると期待されることをテストすべきです。
ハッピーパス(約90%のケース): ユーザーが圧倒的に多くの場面で行うことに、主な焦点を当てます。
重大なエッジケース: 頻繁には発生しないが、システムの整合性にとって重要な限界条件です。
それ以外の可能性の低い組み合わせは、あらかじめテストしません。本番環境で発生した場合は、その場で修正するか、ソフトウェア上の制約やバリデーション(たとえば、入力が有効になるまで画面遷移を無効にするなど)で防ぎます。
AITMにおけるE2Eテスト
AITMでは、E2Eテストは、UIに影響するタスク(タスクの種類・意図で判定)に対する明示的で必須のパイプラインフェーズです。締め切りが迫ったときに省略できる任意のアドオンではありません。これを経なければ、パイプラインを完了としてマークできません。
E2Eテストが存在しない、または環境が利用できない場合、ビルドはデフォルトで失敗します(E2Eの失敗が先に進むことを許可される、まれな例外を除く)。さらに、すべてのE2E実行ではスクリーンショットが取得され、タスクの結果で確認できます。
現在のE2Eの仕組み:
- テストを実行する前に、ビルドの成功が保証され、専用の独立したワークツリーで実行されます。
- データベースの状態は、デフォルトのレコードに加えて、特定のテストデータで準備されます。
- テストはハッピーパスのみに厳密に絞られます(考えられるすべてのシナリオをカバーするわけではありません)。
E2Eの今後のロードマップ:
- フローマップ - システムが、ビジネスロジックに直接リンクされた要素への経路マップを構築します(AITMには統合済み)。
- 自律ナビゲーション - テストが稼働中の経路マップを読み取り、どこでクリックし、入力し、検証すべきかを正確に把握します(現在テスト中)。
- 状態の比較(ビジュアル差分) - コード変更の前後に撮影したスクリーンショットで各ステップを記録し、期待される要素とデータがDBやUIの期待値と一致することを確認します。
- ビジネスロジックの検証 - 期待される出力データ(たとえば、検証済みの請求書の合計額)の自動チェックです(現在開発中)。
- 夜間の結合テスト実行 - ステップの状態とソフトウェア要件から、エンドツーエンドの結合テストが自動的に生成され、夜間に実行されます。失敗した場合は、タスクを生成するか、人間による確認を依頼します(AIは間違えることがあり、人間の承認が必要なため)。
- 高度なシナリオ - 今後のリリースでは、無効なパラメータの注入、複数インスタンスの同時実行テスト、エッジケースのシミュレーションを取り入れる予定です。
E2Eの基本原則のまとめ
効果的なE2Eテストの本質は、マップとデータエンティティ間の関係の管理にあります。ソフトウェアの90%では、標準的なライフサイクルに帰着します。
#AITM #Data Input Validation #E2E #Integration test #AI TESTING