【ISTQB /JSTQB AutomotiveTester 解説】4.1.2 要求仕様レビューにおける品質特性とは?|静的テスト技法の基礎

JSTQB Automotive Tester

はじめに

ISTQB Automotive Tester シラバスの第4章では、「自動車特有のテスト技法(Automotive Specific Test Techniques)」として**静的テスト(Static Testing)動的テスト(Dynamic Testing)**を扱います。

本記事ではそのうち、**4.1.2「要求仕様レビューにおける品質特性(Quality Characteristics for Reviews of Requirements)」**について、ISO/IEC/IEEE 29148:2011の定義をもとに、レビューで注目すべきポイントを詳しく解説します。


静的テストとレビューの重要性

仕様書の欠陥は「早期発見」が命

要求仕様書(Requirements Specification)は開発とテストの両方の基礎となる文書です。

そのため、この段階での欠陥は後工程で大きなコスト・時間の損失を生みます。

  • 例:

    • 要求の誤りが結合テストや受け入れテストで発覚した場合、修正には多大な再作業が必要。

    • 一方、静的レビューで早期に発見できれば、低コストで修正可能。

このように、静的テストによるレビューは「早期発見・低コスト修正」の最も有効な手段の1つです。


要求仕様レビューで確認すべき「品質特性」とは?

ISO/IEC/IEEE 29148:2011では、**単一の要求(individual requirement)および要求群(set of requirements)**に対して、以下の品質特性(Quality Characteristics)を定義しています。

品質特性

意味

Verifiable(検証可能)

要求が静的または動的テストで確認可能であること。

Unambiguous(曖昧でない)

要求が明確で、解釈の余地がないこと。

Consistent(一貫性がある)

要求同士、またはシステム全体との整合性が取れていること。

Complete(完全である)

要求に必要な情報、定義、図表がすべて含まれていること。

Traceable(トレーサブルである)

一意なIDを持ち、テストケースや設計との対応関係を追跡できること。

Bounded(範囲が定義されている)

要求の適用範囲やテスト範囲が明確に定義されていること。

Singular(単一である)

要求が分割可能でなく、重複していないこと。

各品質特性の具体的な例

1. Verifiable(検証可能)

各要求は、テストによって検証可能である必要があります。

  • 良い例:

    「システムは3秒以内にブレーキ応答を行うこと」 → 測定可能で検証できる。

  • 悪い例:

    「システムは迅速に反応すること」 → “迅速”が曖昧で、検証できない。


2. Unambiguous(曖昧でない)

要求が明確で、解釈の違いを生まないこと。

  • 悪い例:

    「システムは通常時に動作すること」 → “通常時”の定義が不明。

  • 改善例:

    「エンジン回転数が1000〜4000rpmの範囲で動作すること」。


3. Consistent(一貫性がある)

他の要求と矛盾しないこと。

  • 悪い例:

    要求A:「システムは20℃で動作すること」

    要求B:「システムは10℃以下では動作しないこと」

    → この場合、10〜20℃の範囲で矛盾が生じる。


4. Complete(完全である)

すべての必要な情報が記載されていること。

  • 悪い例:

    「図1に示す構造で動作する」→ 図1が添付されていない。

  • 改善例:

    図や略語を明確に定義し、参照関係を示す。


5. Traceable(トレーサブル)

各要求に一意のIDがあり、テストケースや設計要素に紐づけられること。

これにより、変更影響分析(Impact Analysis)やテスト網羅性の確認が容易になります。


6. Bounded(範囲が定義されている)

開発・テストすべき範囲を明確にする。

  • 例:

    「車速が0〜200km/hの範囲で速度制御を行う」

    → 境界値を定義することでテスト範囲を明確化。


7. Singular(単一である)

要求が重複せず、独立していること。

  • 悪い例:

    「車速が100km/hを超えたら警報を出す、そしてライトを点滅する」

    → 複数動作を1つの要求に含めている。

  • 改善例:

    • 要求A:「車速が100km/hを超えたら警報を出す」

    • 要求B:「車速が100km/hを超えたらライトを点滅させる」


静的テストにおけるチェックリスト活用

品質特性をレビューする際、**チェックリスト(Review Checklist)**の活用が有効です。

以下はその一例です。

確認項目

質問例

Verifiable

この要求は静的または動的テストで検証可能か?

Unambiguous

解釈の余地や暗黙的な前提知識に依存していないか?

Consistent

他の要求と矛盾していないか?

Singular

複数の要求を1つにまとめていないか?

これらを体系的に確認することで、要求仕様の品質を大幅に向上できます。


まとめ

  • 静的テストは**「早期に安く欠陥を見つける」**ための最強手法。

  • 要求仕様レビューでは、ISO/IEC/IEEE 29148:2011の品質特性を基準にチェックすることが重要。

  • チェックリストを活用すれば、レビューの抜け漏れを防止し、品質向上につながる。

静的テストの本質は、**「後工程で問題を起こさない設計と要求の土台をつくること」**です。

次のステップでは、動的テストに進む前に、このレビュー技法をしっかり身につけましょう。

コメント

タイトルとURLをコピーしました