テスト自動化戦略シラバス：テスト自動化影響分析

はじめに

テスト自動化戦略のシラバスが今年2024年に公開された。
このシラバスを読みまして、各章をDailyで読めるようにしてみた

5 Test Automation Impact Analysis を今回は翻訳・解説する

テスト自動化の投資対効果

テスト自動化プロジェクト導入を考える時、構築とメンテナンスのコストを推定することが重要（ROI）です。

ROI 計算は、投資した労力に対するリターンを実証することにより、プロジェクトライフサイクルの任意の時点の効果測定に使える。
計算の元ネタとして、手動テスターのコストとTAE のコストの両方を単純に時間をかけてそれぞれの労働コストを掛けることで、さらに調整できます。

ROI を計算するには、テスト自動化の”投資”（時間とコスト）と、それによって達成される”節約”を決定する必要があります。

ROI = 節約 / 投資

ここで挙げる例は単純なモデルで、実情はさまざまな指標とデータ、さまざまな測定単位と単位を考慮する必要がある

一般に、テスト自動化によって達成される”節約”とは、同じテストを手動で実行する場合よりも大幅に短い時間で実行でき、頻繁に実施出る点です

”節約”のメトリックス

• テストケースを手動で実行する時間
• 自動化されたテストケースを実行する時間
• テストケースの数
• テストの実行回数

"投資"のメトリックス

• テスト自動化を設定する時間
• 自動化されたテストスクリプトを開発する平均時間
• 実装された自動化テストスクリプトの数
• 自動化テストスクリプトの平均メンテナンス時間
• 自動化されたテストスクリプトを実行する時間
• 失敗した自動化テストスクリプトの割合
• 定義されたテストケースの数
• テストの実行回数

概略のモデルをアジャイルソフトウェア開発に適用することで、プロジェクトの Sprint を以下のグラフに示すように予測できます。
グラフを使用して、テスト自動化が投資を回収した Sprint を特定できます。

※ ISTQB CT-TASより引用

計画されたプロジェクト期間が ROI の転換点よりも短い場合、テスト自動化を導入する価値はない。
この場合、テストを手動で実行することで、時間と労力を節約できます。
投資は自動テストの実行時間に大きく依存するため、テストピラミッドを適用して適切なテストレベルでテストケースを実装することで、この実行時間を短縮し、ROI を改善できます。

テスト自動化メトリックス

メトリックスを活用することで、以下のような判断ができます。

• テスト自動化の適性 : プロジェクトに適したテスト自動化ツールやフレームワークを選択できる
• テスト自動化の拡張性 : 新しい機能やテスト条件に対応するためのテストケースを効率的に追加できる
• テスト自動化の保守性 : テストケースのメンテナンスやトラブルシューティングを効率的に行える

メトリックスとして、以下のようなものがある

• 合格率/失敗率
  自動テストの成功と失敗の割合
  失敗率が高い場合、テストケースやシステムに問題がある可能性があります。

• 失敗数/欠陥数
  1つの欠陥によって何回テストが失敗したか
  同じ欠陥による失敗が多い場合、テストケースやシステムの特定の部分に問題がある可能性があります。

• テスト自動化の実行時間
  自動テストの実行にかかる時間
  テストケースが増えるにつれて、実行時間が長くなる可能性があります。

• 自動化テストケース数
  自動化されたテストケースの数
  しかし、単に数が多いだけでは、テストの網羅性を示すものではありません。

• 機能カバレッジ
  自動化されたテストケースがどの程度の機能要件をカバーしているか

• コードカバレッジ
  自動化されたテストケースがどの程度のコードを実際に実行しているか
  高いコードカバレッジは、システムの品質を高めることにつながります。

テスト自動化のプロジェクトおよび組織レベルでの価値

テスト自動化利用に関する組織的考慮事項

プロジェクトでテスト自動化を開始する前に、組織内で以下を特定する必要がある

• ソフトウェア開発のポリシーとプラクティス
  開発チームの働き方などのドキュメントが、テスト自動化の利用促進につながる。ドキュメントには、SUTの技術仕様、使用ソフトウェア、開発ツール、コードレビューガイドライン、コーディング標準、マージプロセスなどが含まれます。
• 既存のアクティブなテスト自動化プロジェクトとそのステータス
  進行中の開発プロジェクトでは、複数のチームがそれぞれTAS開発を進めている場合がある。意思決定者は、既存のプロジェクトとそのステータスを確認し、新しいTASのテスト目標に適合するかを確認することが求められる。既存のTASを再利用するか、現在のニーズに基づいて新しいTASを作成するかを判断する
• 組織のテスト自動化の専門家
  組織内で新しい TAS のロールアウトを支援するSME(Subject Matter Expert)がおすすめ。 SME は、TAS とそのロールアウトに関するストーリーや教訓を共有する。 これにより、成功した TAS のロールアウトのために考慮または回避する必要があるさまざまなリスクを特定できます。
• テスト環境の可用性
  　大規模組織では、既存のテスト環境の情報、利用状況、および可用性を収集することが推奨される。これは、新しいTASを展開し、システムを使用する際に他のチームの作業を妨げないために重要です。多くの場合、新しいテスト環境が必要になりますが、既存の環境を基準として使用し、責任者を特定することで作業が容易になります。
• テストツールとライセンス
  組織が現在保有しているツールとライセンスの情報を把握することは重要。コストとタイムラインを削減し、TASの計画が効率化される。

テスト自動化の最適な実装を決定するプロジェクト特性の分析

最適な働き方を定義し、成功するテスト自動化の目標を定義するのに役立ついくつかの主要なプロジェクト特性があります。

• ドメイン
  各ドメインは、規制または標準のいずれかで異なることを理解することが重要です。 計画されたテスト自動化の目標が準拠していることを確認するために、さまざまな標準とドメインの制限をチェックすることが重要

• プラットフォーム
  テスト自動化の目標設定には、プロジェクトが対象とするプラットフォームと、どこでテスト自動化が有益かを評価することが重要です。複数プラットフォームでのテスト自動化は、異なるソリューションが必要になることがあるため計画が難しくなりますが、多くの場合同じツールを使用できます。また、プロジェクトのプログラミング言語や技術スタックもテスト自動化の目標に影響する。開発者が使用しているプログラミング言語を使用することで、コラボレーションが容易になり、コードレビューを通じた相互学習がSUTの品質とTAEの知識を向上させます。

• プログラミング言語とテクノロジースタック
  　プロジェクトの実装の詳細 (プログラミング言語やテクノロジースタックなど) も、組織が定義すべきテスト自動化のテスト目標の種類を決定します。 与えられたプロジェクトで開発者が使用しているのと同じプログラミング言語を使用することをお勧め。 そうすることで、コラボレーションをより簡単にすることができ、コードレビューを共同で行うことで、SUT の品質と TAE の知識をさらに向上させることができます。

• プロジェクトの成熟度
  プロジェクトの成熟度分析で、理想的なテスト自動化の目標を設計するための情報が得られる。テストケースの数、既存のCI/CDパイプライン、テスターやTAEの数などの要素を特定し、それに基づいてロードマップを作成。特に、手動で優先度の高いテストケースが多く、その実行時間が長い場合は、これらを最初に自動化することが重要です。また、プロジェクトのタイムラインも考慮し、短期間のプロジェクトでは大規模なTASの計画は避けるべき。長期的なプロジェクトの場合は、段階的なロードマップを検討します。

• ステークホルダーの支持
  　 テスト自動化が導入されない理由は、主要な関係者が導入に同意しないことが多いためです。速度の低下、厳しい締め切り、予算などの懸念が含まれる。プロジェクトの成熟度を分析し、TASの導入に余地がある場合、戦略的な関係者は製品のリスクを特定し、テスト自動化の利点を列挙し、適切な計画を策定する必要がある。この計画は、テスト自動化によって達成されるマイルストーンと、SUTのテスト可能性を向上させるための改善策を強調し、関係者に提示する。

• チームの知識と関連する経験
  　テスト自動化成功要因は、テスターのスキルと経験です。テストマネージャーは、チーム内の知識を把握し、ギャップを特定するためにスキルマトリックスを作成します。これにより、トレーニングやタスク割り当てが効果的に行えます。

• テスト管理のサポートと予算
  　プロジェクトの規模や成熟度、予算、テスト管理のサポートを考慮して、実現可能なテスト自動化の目標を設定することが重要です。テスト自動化戦略を管理者に提案する際には、文書を簡潔にし、ギャップや将来のコストを明確に示します。ビジネス価値とコスト削減の利点を挙げることで、テスト管理の承認を得やすくします。

• 品質特性
  ISO/IEC 25010:2011品質特性を定義しています。 これらの品質特性は、現在の TAS を評価したり、TAS によって収集されるメトリックを決定したりするために使用できます。
  参考に、品質特性の非機能の項目は以下のものがある

  • Performance efficiency
  • Compatibility
  • Usability (interaction capability)
  • Reliability
  • Security
  • Maintainability
  • Portability (flexibility)
  • Safety

テストレポートデータの分析による意思決定への情報提供

テスト自動化レポートの形式と内容は関係者によって異なります。重要な指標を特定して強調することが戦略的に重要です。

自動化で収集されたデータは、以下に役立ちます。

• トレンドの特定と根本原因分析の実行
• テスト自動化の取り組みをメンテナンスに移行
• テスト自動化の取り組みを TAF の改善とさらなる開発に移行
• 全体的な TAS に機能を追加
• テストへの左シフトと右シフトのアプローチの強化
• 将来のスプリントでのテスト自動化の機能カバレッジの拡大
• デフェクトクラスタへのフォーカス
• 開発者にコードを改善する領域をアドバイス
• 全体的な SDLC プロセスに関するアドバイス
• 将来のテスト自動化レポートの内容と形式を変更

上記の情報に基づいて、TAE は他のステークホルダーと協力して、既存のテスト自動化カバレッジとテスト結果のギャップと特定の改善点を特定できる。