日本語E2Eテストはどこまでやるべき？ 「テスト全体像」から範囲を決定する2つのヒント
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。
MagicPodに限らず、E2Eテストの自動化に取り組み始めた方が疑問に思うのが
「E2Eテストってどのくらい／どこまでやればいいの？」
という点です。
かつてシステムテストやE2Eテストの自動化がいまほど普及していなかった頃には、
- なんでもかんでも自動化！
- 100％の自動化率！
といった、それまで行っていたたくさんの手動テストケースを片っ端から自動化するようなチームもあったようです。
しかし、テストピラミッドの考え方をはじめ、テスト自動化に関するさまざまな情報・ナレッジが普及するとともに、上記のような「E2Eテストをたくさん自動化しよう」というやり方はアンチパターンだと認識されるようになりました。
※参考：テストのコスト増加やその対策に関しては、こちらの記事もご覧ください。
その結果として、最初に挙げた「なんでもかんでも自動化すればよいわけでないなら、どこまでやればいいのか」という問いにつながってきます。
よく言われるE2Eテストの範囲
E2Eテストの範囲は、以下のように説明されることが多いです。
- 主なユーザーストーリー
- ビジネス要求をテスト
- システム・アプリケーションのコアな価値を確かめるテスト
- 画面を操作して、データや処理がDBや外部システムなどすべて通るようなシナリオ
これらの説明も決して間違っているとは思いません。しかし、「どこまでやればいいのか」という疑問を持っている方はこれらの答えではスッキリ納得ができず、まだもやっとしている状態なのではないでしょうか。
このもやっとした状態をクリアにするためには、テストの全体像を考えること、つまりE2Eテストを単独で考えるのではなく、他の「＊＊＊テスト」との関係性やそれぞれの責務を含めて考えることが重要です。
テストの全体像を考えるヒント2つ
考え方の例を2つご紹介します。
例１：テスト対象のアーキテクチャに基づいて範囲を決定する
ひとつの考え方は、テスト対象のアーキテクチャに基づいて、単体・結合・E2Eなど各種テストのカバーする範囲を決定する方法です。
Martin Fowler氏の記事を例に見てみましょう。
引用：Testing Strategies in a Microservice Architecture
この記事では、マイクロサービスアーキテクチャに対して
- Unit test
- Component test
- Integration test
- Contract test
- End-to-end test
がそれぞれ担う範囲を設定しています。 例では抽象的な図になっていますが、自組織における具体的なアーキテクチャ図に基づいて、どこからどこまでを各テストが担うのかを明示する、というのが一つの方法です。
国内ではfreee社が類似の取り組みについてブログ記事を公開しています。
参考：ソフトウェアアーキテクチャに基づいた自動テスト戦略と実装ガイドライン - freee Developers Hub
例２：テストアーキテクチャとともに範囲を検討する
テストアーキテクチャにはいくつかの説明がありますが、代表的なものとしては以下があります。
テストの全体像を、テストの構成要素とその関係性、連携の段取りで表現したもの 引用：テスト設計チュートリアルちびこん編2024
この説明どおり、まさにテストアーキテクチャはテストの全体像を表しているものです。
テストアーキテクチャの表現方法にも複数の種類がありますが、私が好んで用いているものにテストコンテナを用いたモデルがあります。
この図では、たとえば「単体テスト」の中では「構造テスト」や「例外ハンドリングテスト」を行い、「システムテスト」では複数のフェーズで「機能テスト」や「負荷テスト」を行いつつ並行して「動作環境テスト」を行って・・・といった形で各種テストが整理されています。
このような形でテストアーキテクチャを整理する中で、「E2Eテスト」というコンテナを用意してどんな観点をそこに含めるか、を検討するのも一つの方法です。
E2Eテスト単独でなく、他のテストと併せて考えよう
テスト対象のアーキテクチャ図で考える場合と、テストアーキテクチャに基づいて考える場合、いずれもE2Eテスト単独で範囲や責務を考えるのではなく、他のテストレベル・テストタイプとともにE2Eテストの範囲を検討する点がポイントだと考えています。
この考え方は、あらたにE2Eテストを自動化するときに限らず、「E2Eテストは自動化してあるけど、これでいいんだったかな・・・？」とその範囲や役割に迷った際にも有効です。
E2Eテストをどこまでやるべきか、で迷った場合は、まずはテスト全体でどうあるべきかに立ち戻って検討してみることをオススメします。
