回答。

問題の歴史:

テストカバレッジ（test coverage）は、テスト品質の主要な指標の一つです。カバレッジ戦略は、自動化の初期に登場し、テストの数が急激に増加する中で、手動で未カバーのシナリオを追跡することが不可能になりました。それ以来、アプローチは直感的なものから厳密な分析的なものに進化し、要件トレーサビリティ、コードカバレッジツール、テストピラミッド技術の管理が含まれています。

問題:

自動テストの均等で意図的なカバレッジは、様々なテストタイプ（ユニット、統合、E2E）、実行速度、メンテナンスコスト、ROIと見逃した欠陥のリスクとのバランスを取る必要性のため、難しい課題です。
高いコードカバレッジの割合だけで完全な保護が保証されるという誤った感覚がしばしば見られますが、ビジネスロジックやユーザーシナリオの「穴」が無視されることになります。

解決策:

様々な技術の組み合わせを使用する必要があります：コードカバレッジ、トレーサビリティマトリックス、リスクベーステスト。
開発チームおよびビジネスとの戦略の調整が重要で、実際の優先順位を理解することが求められます。
重要な実践は、定期的なカバレッジ監査（手動および自動）であり、優先順位の調整と「コードの100%カバレッジ」のアイデアを意味的かつシナリオ的、リスク指向のアプローチに変更することです。

主な特徴：

複数のカバレッジタイプの使用：ステートメント、ブランチ、条件、機能、要件カバレッジ。
最大の完全性のためのトレーサビリティマトリックスとコードカバレッジの統合。
戦略の定期的な見直しと自動レポートの生成。

誤解を招く質問。

高いコードカバレッジ率は製品の品質を完全に保証できますか？

いいえ、できません。高いコードカバレッジ（例えば95%）は、特定のコード部分だけがテストされていることを意味することが多く、ビジネスロジックや使用シナリオが正確にチェックされていることを保証するものではありません。

常に100%のコードカバレッジを目指すべきですか？

いいえ。100%のカバレッジを目指すことは、メンテナンスコストを増加させ、時には意味のないまたは到達不能な部分のテストを書く必要が生じます。リスクと利益に基づいて優先事項を選択する方が良いです。

信頼できるカバレッジのためにユニットテストだけを使用するのは十分ですか？

いいえ。ユニットテストは統合シナリオやコンポーネント間の相互作用をカバーしません。テストピラミッドに従って、さまざまなテストタイプを組み合わせる必要があります。

一般的な間違いやアンチパターン

コードカバレッジの高い割合への盲目的な追求
ユーザーシナリオや要件のカバレッジの無視
カバレッジ優先順位の決定におけるビジネスチームの不参加
すべてのテストが同じ種類：ユニットのみまたはE2Eのみ

実生活の例

ネガティブなケース

チームは、すべてのプルリクエストに対して90%のテストカバレッジを必須とするパイプラインを導入しました。その結果、「空の」テストが出現し、行はカバーされているがシナリオはカバーされていない状況が生まれました。ビジネスロジックのエラーは見逃されました。

利点:

形式的な基準を迅速に達成
もっとテストを書こうとするモチベーション

欠点:

テストが実際のバグを捕まえない
技術的負債が増え、チームはテストへの信頼を失う

ポジティブなケース

チームは、トレーサビリティマトリックスとリスクベーステストを用いてカバレッジ戦略を構築しました：最も重要な機能はE2Eテストでカバーされ、重要度が低い機能はユニットテストでカバーされます。毎月、シナリオに基づいてカバレッジの監査が実施されます。