要件ベースドテスト（Requirement Based Testing）は、ISTQB Foundation Level（CTFL）でも登場する基本的なテストアプローチであり、Automotive Testerシラバスでも K1（用語レベル） として扱われます。
この記事では、自動車領域のテストで重要となる「要件ベースドテスト」の考え方を、具体例を交えながらわかりやすく紹介します。
■ 要件ベースドテストとは？
要件ベースドテストとは、仕様書（要求仕様）からテスト条件を抽出し、それに基づいてテストケースを作成・実行するアプローチ です。
テスト設計技法（同値分割・境界値分析など）とは異なり、
これは 「テストの進め方（アプローチ）」 に分類されます。
■ 要件ベースドテストの基本ステップ
Foundationレベルで学んだ「テストプロセス」と同じ流れで進んでいきます。
-
要件を分析する
-
テスト条件を特定する
-
テストケースを設計する
-
テストケースを実行する
-
結果を分析し、必要なら追加テストを作る
このように、要件に基づいてテスト設計 → 実行 → 改善 を繰り返し、要件を十分にカバーすることが目的です。
■ 自動車開発での具体例：要件ベースドテスト
● 要件例
要件R1：車速が20km/h以下のとき、後方カメラが自動で起動すること。
要件R2：車速が20km/hを超えた場合、後方カメラは自動的にオフになること。
● テスト条件の抽出
-
車速 ≤ 20km/h のときカメラON
-
車速 > 20km/h のときカメラOFF
● テストケース例
|
TC No |
車速 |
期待結果 |
|---|---|---|
|
TC1 |
0 km/h |
カメラON |
|
TC2 |
10 km/h |
カメラON |
|
TC3 |
20 km/h |
カメラON |
|
TC4 |
21 km/h |
カメラOFF |
|
TC5 |
30 km/h |
カメラOFF |
このように、要件の内容をそのまま反映したテストケースが作られます。
■ 要件が不十分な場合のリスク
要件が曖昧・不完全な場合、
その要件に基づくテストケースも不完全になる
という点が最大のデメリットです。
例：
要件に「20km/h以下」とあっても、
-
“20km/hちょうど” の扱いが明確でない
-
小数点はどう扱うのか？
-
停止中（0km/h）をどう扱うのか？
などが曖昧な場合、テスト時にも混乱が生じます。
■ すべての要件を100%網羅できない問題
要件が膨大だったり、非常に詳細だったりすると、
すべての要件をテストするのは不可能 です。
これはテスト原則の1つ、
「原則②：完全（網羅的）テストは不可能」
に対応する内容です。
そのため現実的には、
-
重要度
-
リスク
-
優先度
に基づいてテストケースを優先付けします。
特に自動車領域では、安全に直結する要件（ASILが高いもの）を優先してテストを行います。
■ 要件ベースドテスト＋探索的テストの組み合わせ
動画でも解説されているように、要件ベースドテストだけでは
「要件に記述されていない欠陥」に気づけないことがあります。
そこで、自動車開発では次のような組み合わせが一般的です。
-
要件ベースドテスト（形式的）
-
経験ベーステスト（探索的テスト、エラーベース）
-
回帰テスト
特に探索的テストでは、実車特有の動き、環境条件、ドライバー操作などから新しい不具合を見つけることがよくあります。
■ まとめ
要件ベースドテストは最も基本的なアプローチですが、
自動車開発では非常に重要な役割を果たします。
-
要件からテストを作ることで、仕様を漏れなく確認できる
-
ただし要件が不完全だとテストも不完全になる
-
全部の要件はテストできないので優先度付けが必要
-
経験ベースや回帰テストと組み合わせると効果が高い
K1レベルの範囲ですが、実務でも頻繁に登場する重要な考え方です。
コメント