はじめに
テスト自動化戦略のシラバスが今年2024年に公開された。
このシラバスを読みまして、各章をDailyで読めるようにしてみた
3.1 Integration Across Test Levels を今回は翻訳・解説する
テストピラミッド
テスト自動化の分野では、テストレベルを分類し、適切なバランスを保つことが重要です。
Mike Cohnが提唱した「テスト自動化ピラミッド」は、そのための有用なモデルです。
テストピラミッドは、異なるテストが異なる粒度を持つことを示すモデルです。
このモデルは、テスト自動化とテスト作業の配分をサポートし、異なるテスト目的が異なるレベルのテスト自動化によって支えられていることを示します。
ピラミッドの層はテストのグループを表し、上層に行くほどテストの粒度が粗くなり、テストの独立性が低くなり、テストの実行時間が長くなります。
- 下層のテスト
小さく、独立していて、迅速に実行され、機能の小さな部分をチェックします。多くのテストが必要です。 - 上層のテスト
複雑で高レベルのエンドツーエンドテストです。これらのテストは一般的に遅く、大きな機能をチェックするため、少数で十分です。
一般的に、以下のように３層にすることが多いです。
- ユニットテスト (Component Testing)
個々のコードモジュールや関数の機能を検証する。 - サービスレベルテスト
- コンポーネント統合テスト : 複数のコンポーネントが連携して動作することを検証する。
- コントラクトテスト : サービス間の契約（API仕様など）が守られていることを検証する。
- APIテスト : APIの機能や性能を検証する。
- UIテスト
ユーザーインターフェースの動作を検証する。
ピラミッドの形状は、理想的なテストレベルのバランスを表しています。
下層のユニットテストやサービスレベルテストの割合が多く、上層のUIテストの割合が少ないのが理想的です。
理由は、下層のテストは実行が早く、フィードバックが迅速であるため、頻繁に実行できます。
一方、上層のUIテストは実行時間が長く、メンテナンスコストも高いため、慎重に設計する必要があります。
ピラミッドはあくまで理想像で、これに沿うことに注力すべきではないと思います。
現在のテスト状況と理想的な状態を比較することで、不足しているテストレベルや改善すべき点を見つけるきっかけになると思う、そういった使い方をするといい。
例えば、UIテストに過度な依存がある場合、下層のテストを強化することで、テストの効率性と信頼性を向上させることができます。
テストピラミッドのパターン
ピラミッド型
下層のテスト (ユニットテストやサービステスト) を多く、上層のテスト (UIテスト) を少なくするバランスのとれた形状
- メリット
迅速なフィードバック、高いテストカバレッジ、低いメンテナンスコスト。 - デメリット
UIテストの不足により、ユーザー体験に関する問題が検出されにくい可能性がある。
アイスクリームコーン型
上層のUIテストに重点を置き、下層のテストが少ない形状。
- デメリット
テスト実行時間が長く、メンテナンスコストが高い。 - リスク
欠陥の発見が遅れ、修正コストが増加する可能性がある。
砂時計型
上層と下層のテストに重点を置き、中間層のサービステストが少ない形状。
- デメリット
統合テストの不足により、システム全体の整合性が損なわれる可能性がある。 - 改善策
APIテストやコンポーネント統合テストを増やすことで、テストの効率化と信頼性を向上させる。
傘型
上層のUIテストに完全に依存している形状。
- デメリット
テスト実行時間が長く、メンテナンスコストが高い。 - 改善策
UIテストの自動化を最適化し、テスト実行時間を短縮する。また、可能な限り下層のテストを増やすことで、テストの効率化を図る。
※ CT-TAS から引用
テスト自動化アプローチの選択
テスト自動化アプローチの選択はシステムのアーキテクチャに大きく依存します。
理想的なテスト分布はピラミッド型ですが、現実には組織の状況やシステムの特性によって異なります。
例えば、メインフレームシステムでは自動化が難しい部分が多く、GUIテストやバッチ処理のテストが中心となります。
一方、マイクロサービスアーキテクチャではAPIテストや契約テストが有効です。
組織がレガシーシステムをモダナイズする際には、これらのテストを導入することで、より網羅的なテストが可能になります。
重要なのは、現状を把握し、段階的に改善していくことです。
組織の文化や成熟度も考慮し、現実的な目標を設定することが重要です。
Shift LeftとShift Rightアプローチを実現するためのテスト自動化分布の最適化方法
テスト自動化の最適化は、現在のテスト分布を正確に把握し、理想的な分布（多くの場合、ピラミッド型）を設定することから始める。
このギャップを埋めるためのロードマップを作成し、自動化の範囲と戦略を明確にすることが重要。
ボトムアップアプローチによる改善
テストカバレッジが低い場合は、コンポーネントテストの追加が優先されます。
コンポーネントテストの質を高めるために、テスト駆動開発やワークショップの開催が有効です。
UIテストとAPIテストの最適化
UIやAPIのコンポーネントテストを導入することで、より早い段階で問題を発見できます。
モックやスタブを利用することで、外部システムへの依存を減らし、テストの安定性を高めます。
契約テストの導入
プロバイダとコンシューマ間の契約を検証することで、欠陥を早期に発見し、問題の根本原因を特定しやすくなります。
契約テストにより、APIテストの数を減らすことができます。
API間の関係を可視化(コールグラフの作成)することで、システムのボトルネックを特定しやすくなります。
Shift LeftとShift Right
Shift Leftは、開発の早い段階でテストを行うことで、バグの早期発見と修正を可能にします。
Shift Rightは、 本番環境に近い環境でテストを行うことで、実際のユーザーの状況でのシステムの挙動を検証します。
Shift Rightは、オブザーバビリティと組み合わせることで、本番環境での問題を迅速に検出し、対応することができます。
Shift Rightの目的
- ユーザーの行動パターンや好みを理解する
- カナリアリリースやダークローンチをサポートする
- 本番環境でのバグを早期に検出する
- テスト自動化の範囲を拡大する
- カバレッジを高める
テスト自動化プロジェクトと各ソフトウェア開発ライフサイクルモデルの適合性
ウォーターフォールモデル
ウォーターフォールモデルはテストフェーズは要件分析、システム設計、実装フェーズの後に位置しています。
この厳格な順序のため、テスト自動化活動は遅れて開始となります。
テスト間のサイクルが長くなることで、テスト自動化を活用する機会が減り、テスト自動化からのフィードバックが遅くなり、投資対効果（ROI）が低下する可能性があります。
Vモデル
Vモデルはすべてのテスト計画とドキュメントの準備が初期フェーズで行われます。
例えば、アーキテクチャ設計フェーズで統合テスト設計が作成され、ウォーターフォールよりも早い段階でテストが設定されます。
しかしながら、TASの実際の実装はSDLCの後期に来るため、テスト自動化のROIはウォーターフォールモデルよりも高いものの、現代のアジャイルソフトウェア開発プラクティスに遅れを取る可能性があります。
アジャイルソフトウェア開発
アジャイルソフトウェア開発の理想の一つは、スプリント内でのテスト自動化を実現すること。
これは、各ユーザーストーリー完了基準の一部として、必要なすべてのテスト自動化活動を決定することをさします
これには、テストケースの定義、自動テストケースの実装、TAFの更新、場合によってはCI/CDパイプラインへの統合が含まれます。
アジャイルプラクティスを正しく適用していない組織は、テストの工数を見積もらず、別のチケットで管理したり、まったく監視しなかったりします。
スプリント内でのテスト自動化を実現することで、アジャイルチームは、各スプリントの終了時までに合意された範囲をデプロイする準備ができていることを保証します。
アジャイルの観点から成熟していないチームの場合、最初の目標はスプリント内でのテストの実現であり、その後にテスト自動化に取り組むことが推奨されます。
テスト自動化プロジェクトとDevOpsベストプラクティスを適合
アジャイルソフトウェア開発は仕事の組織化方法に焦点を当てているのに対し、DevOpsはソフトウェアのエンドツーエンドのデリバリーを担当します。
これは、ビルド、統合、テスト、デプロイ、プロダクション活動を自動化することで実現されます。
これにより、継続的な改善を保証するフィードバックループを通じて、継続的なテストが可能になります。
重点は、コンポーネント、コンポーネント統合、契約テストなど、より低レベルの自動テストケースの実装に置かれます。（テストピラミッド）
実際のデータやサービスへの依存を減らすことで、テストをより短時間で実行できます。
可能であれば、テスト自動化はSUTが構築されるのと同じパイプラインで実行されるべきです。
さまざまなテストスイートは、各開発およびビルドフェーズ（ローカル、プルリクエスト、マージ、デプロイなど）後にトリガーされます。
テスターがより大きなUIおよびAPIテストスイートを構築する能力を持っている場合、それらは追加の価値を提供するために別途実行されます。
手動テストの取り組みは、探索的テストとエンドユーザーからのフィードバックに焦点を当て、テスト自動化の補完的な活動として提案されています。
テスト自動化に適したテストの決定基準
テストケースのテスト自動化への選定は、通常、どのテストケースを自動化できるかを理解しているテストアナリスト、またはそのような決定に必要なドメイン知識を持つテスト自動化エンジニア(TAE)が行う。
テストケースのテスト自動化のための選定と優先順位付けの際に考慮される点は次のとおりです。
- 技術的に自動化されたテストケースを実装可能か？
- 自動テストケースのデリバリーに影響を与える技術的な課題はあるか？チームは実装作業の準備ができているか、十分なトレーニングを受けているか？
- コーディングの労力は適切なROIを提供するか？
- テストケースを頻繁に実行する価値はあるか？
- テストの種類 : 機能テストか非機能テストか？スモークテストスイート、回帰テストスイート、確認テストスイートの一部か？
- テストケースは繰り返可能か？
- SUTの更新による変更時に、テストケースはメンテナンスしやすいですか？
- テストケースは頻繁に使用されるビジネスワークフローをカバーしていますか？
- テストステップとテストデータの再利用を可能にするテスト間の機能的な重複はあるか？
テスト自動化のみが解決できる課題
テスト自動化によってのみ実行可能であり得意な特定のテストがあります。
- 手動テストの実行時間が長すぎる場合
- テストケースの実行を同期させる必要がある場合
- パイプラインでテスト結果を確認する必要がある場合
- 大規模なログファイルを解析して欠陥を見つける必要がある場合
- テストのタイミング精度が必要な場合
- 複数のOS、ブラウザ、デバイス、場所、または構成にわたるテストの組み合わせが必要な場合
- カバレッジを最大化するために大量のテスト実行やデータ入力が求められる場合
- 自動化された監視と分析、または大量のユーザーからの入力（ストレステストや信頼性テストなど）を必要とする非機能テストの場合
テスト自動化が困難なテスト条件
テストケースの自動化を困難または不可能にする特定のテスト条件があります。
この場合、手動テストにすることを推奨します
- デザイン要件の検証（異なるプラットフォームでのUIの一貫性を含む）
ソフトウェアの全体的なルックアンドフィールは主観的であり、人間のレビューが必要です。 - 過度の人間介入を伴うテストケース
金融業界では、ローン申請がその良い例です。このプロセスでは、特定の規制や条件（十分な収入がない、個人情報が間違っているなど）の場合があります。このような状況では、エージェントは実際のローン申請を再確認し、手動で決定を下したり、顧客に連絡する必要があります。 - OSレベルの制限など、テスト自動化活動を妨げる技術的な困難
一例として、ユーザーにテキストメッセージを送信するネイティブOSソフトウェアがあります。これらのテキストメッセージの操作や検証は、OSがターゲットSUT以外の操作を許可しないため、UIテスト自動化ツールでは不可能です。 - 長い時間依存性のあるテスト条件
テスト自動化を非効率にし、手動テスト実行と比較して適切に設定するのが困難な場合があります。たとえば、テスターはSUTにログインし、ホームページのコンテンツを更新し、SUTがセッションタイムアウトにより自動的にログアウトするまで2時間待つ必要があります。経過時間を手動で変更できない場合（モック、サーバーサイドの応答、OSレベルの時間変更など）、そのようなテストケースを自動化して実装することはお勧めしません。