Skip to content

2.8 最善のホワイトボックステスト技法の選択

これまで、ステートメントテストから複合条件テスト、APIテストに至るまで、様々なホワイトボックステスト技法を見てきました。しかし、現実のプロジェクトにおいて「すべてのコードに対して、最も厳密な複合条件テストを適用する」ことは、コストと時間の観点から不可能です。

テクニカルテストアナリスト(TTA)の最も重要な役割の一つは、プロジェクトのコンテキスト(状況)を分析し、 「品質目標を満たしつつ、テストの費用対効果(ROI)を最大化できる最善のテスト技法を選択すること」 です。


技法選択に影響を与える3つの主要要因

Section titled “技法選択に影響を与える3つの主要要因”

TTAがテスト技法を決定する際、主に以下の3つの要因を考慮します。

1. 規制基準と業界標準 (Regulatory Standards)

Section titled “1. 規制基準と業界標準 (Regulatory Standards)”

開発するソフトウェアが、人命や環境、甚大な経済的損失に関わる「安全クリティカル(Safety-Critical)」なドメイン向けである場合、適用すべきテスト技法やカバレッジ基準は法律や国際規格によって厳格に定められています。

  • DO-178C (航空機向けソフトウェア):
    • 最高の安全性が求められるレベルAでは、 MC/DC(改良条件判定カバレッジ) の100%達成が義務付けられています。
    • レベルBではブランチカバレッジ、レベルCではステートメントカバレッジが求められます。
  • ISO 26262 (自動車向け機能安全):
    • 最もリスクの高いASIL Dでは、同じくMC/DCが強く推奨されています。
  • IEC 61508 (電気・電子・プログラマブル電子安全関連系):
    • 産業機器などの基本安全規格であり、安全性度水準(SIL)に応じて必要なカバレッジが指定されます。

これらの規格が適用されるプロジェクトでは、TTAに「技法を選ばない(規格に従わない)」という選択肢はありません。

業界標準の縛りがない一般的なソフトウェアであっても、コンポーネントごとに「リスクベースドテスト」のアプローチを適用します。

  • 高リスク領域: 決済処理、認証ロジック、複雑なビジネスルールを含むコアモジュールには、ブランチテストMC/DCを適用し、論理的な欠陥を徹底的に排除します。
  • 低リスク領域: 単純なデータ表示や、影響範囲が限定的なUI寄りの処理については、ステートメントテスト(あるいはブラックボックステストのみ)に留め、テスト工数を削減します。

3. コードの特性とアーキテクチャ (Code Characteristics)

Section titled “3. コードの特性とアーキテクチャ (Code Characteristics)”

対象となるコードがどのような構造を持っているかによって、有効な技法が変わります。

  • 複雑な if 文や switch 文が多用されている論理制御中心のコードには、MC/DC複合条件テストが適しています。
  • ループの回数や順序が重要な処理には、パステスト(特定の経路を検証する技法)が適しています。
  • 外部システムとの連携口となるエンドポイントには、APIテストが必須となります。

TTAとしての戦略的アプローチ(ブレンド手法)

Section titled “TTAとしての戦略的アプローチ(ブレンド手法)”

実際の現場では、単一の技法だけでシステム全体をカバーすることは稀です。TTAは、テストマネージャや開発アーキテクトと協議し、以下のように複数の技法を戦略的に「ブレンド」します。

  1. ベースラインの確保: まず、システム全体に対して自動化された単体テストで「ステートメントカバレッジ 100%」を目指し、デッドコードや明らかなバグを排除します。
  2. クリティカルパスの強化: 次に、重要なコンポーネントに対して「ブランチカバレッジ」を測定し、未実行の分岐(特にエラーハンドリング処理など)に対するテストを追加します。
  3. ピンポイントの深掘り: 最後に、最も複雑でリスクの高い「少数のコアモジュール」に対してのみ、コストをかけて「MC/DC」を適用します。

このように、TTAは 「カバレッジの包含関係(複合条件 > MC/DC > ブランチ > ステートメント)」 を深く理解し、コストの爆発を防ぎながら、必要十分な品質と安全性を証明するテスト戦略を構築・実行するのです。