「テスト」から「検証」へ　－　Automotive SPICE 4.0の「検証」プロセス　－

Automotive SPICE 4.0 に関するコラム、今回は「検証」プロセスについてお届けいたします。

はじめに

これまでのAutomotive SPICE v3.1にあった「テスト」と名の付くプロセスは、v4.0では以下の様に「テスト」の代わりに「検証」という用語に変わりました。

SWE.5：ソフトウェア統合および統合テスト　→　ソフトウェアコンポーネント検証および統合検証
SWE.6：ソフトウェア適格性確認テスト　　　→　ソフトウェア検証
SYS.4：システム統合および統合テスト　　　→　システム統合および統合検証
SYS.5：システム適格性確認テスト　　　　　→　システム検証

なぜ「テスト」から「検証」に変わったか

Automotive SPICE v4.0のガイドラインでは、「特に、システム及びハードウェアのレベルでは、テストだけが唯一の検証アプローチではなく、測定、計算または物理的なサンプルを使用するシュミレーションなどは他の検証方法である」とあります。より包括的な「検証」という用語を用いることにより、テストに限定しないで最も適した検証手段を選んで下さいというメッセージになりました。
もともとv3.1でも、SWE.4「ソフトウェアユニット検証」プロセスだけは、ユニット検証手法としてテストだけでなく静的解析やコードレビューもあることから、「ソフトウェアユニットテスト」ではなく「ソフトウェアユニット検証」というプロセス名になっていました。V4.0ではこの考え方が全テストプロセスに広がったことになります。

これまでのテストプロセスとの違い

用語の変更に伴い検証プロセスのBP（基本プラクティス）の内容も変わりました。

v3.1 SWE.6：ソフトウェア適格性確認テストとv4.0 SWE.6：ソフトウェア検証を比較すると以下となります。

Ver3.1のSWE.6.BP1「回帰テスト戦略を含むソフトウェア適格性確認テスト戦略の策定」はV4.0では「戦略」がBPから無くなるために削除となり、「テスト仕様の作成(BP2)」は「検証手段の仕様化」、「テストケースの選択(BP3)」は「検証手段の選定」に、「ソフトウェアのテスト(BP4)」は「ソフトウェアの検証」と、その表現を変えています。

これまでは「テスト仕様の作成」というBP名称だったため、とにかく「テストしなければならない」という思いが強かったのではないかと思います。そのため本来机上検証の方が効果的かつ効率的な項目においても、無理してテストを行うような場面があったのではないでしょうか。でもVer4.0では「この項目はテストで検証」「この項目は机上で計算」と戦略的に検証手段を選択することを求めていますので、テストに拘らずより検証目的に適った検証手段を選択することとなり、結果的に検証品質が向上し、製品の品質向上に繋がると考えます。
（安部　宏典）