Automotive SPICE 4.0 SWE.5 ソフトウェア統合テストの考え方
Automotive SPICE 4.0では、各プロセスの目的は変わっていないとしならがら、細かい点で修正が盛り込まれています。 Automotive SPICEのアセスメントを予定している方には、目的は変わらないと言われても、不安に思われている方も多いと思われます。今回は、SWE.5 ソフトウェア統合テストに関する変更点についてお伝えします。
ソフトウェア統合および統合テストについては、インタビューの場面でもアセッサと論点がかみ合わず、対応に苦慮された経験をお持ちの方も多いのではないでしょうか? よくあるケースとして:
- いわゆるビックバン:全てのソフトウェアをビルドして統合するので段階的な統合やテストは実施していない(する必要性を感じていない)
- 統合テストとは、ビルドしたソフトウェアを使って、機能を確認するテストである
という説明になり、質疑に時間がかかってしまうケースが多いように見受けられます。
勿論、製品開発の形態(新規、派生など)や、プロジェクトの状況などにより、統合やテストの方法は変わってきます。 しかしながら、Automotive SPICEにおける考え方を理解しておくことで、状況に応じた説明をすることが重要だと思います。
そこで、VDAガイドライン第2版をみながら統合テストのありかたを整理してみました。
ソフトウェア統合および統合テスト(検証)の考え方は次の通りです:
❶ コンポーネント内のソフトウェアユニット相互が設計通りに振舞うことを検証する
❷ コンポーネントが設計通りに正しく動作することを検証する
➌ コンポーネント相互が設計通りに振舞うことを検証する
VDAガイドラインでは、次の絵を使って解説しています。
下記の4点は、Automotive SPICE v3.1では直感的/十分には記載されていなかったとして、Automotive SPICE 4.0 では各プロセスに明確に定義されました。
- SWE.2 単体のソフトウェアコンポーネントの振舞いの定義(コンポーネント間の相互作用とは対照的なものとして)
- SWE.3 単体のソフトウェアユニットの振舞いの定義
- SWE.5 ソフトウェアユニットをそれらのコンポーネントに統合および統合検証
- SWE.5 単体のソフトウェアコンポーネントの検証(他のコンポーネントとの統合に先立ち)
これらを別の形で図示すると 2023.10.7発行のコラム(ソフトウェアドキュメント間のトレーサビリティ) の中で「統合テスト」のアイコンで示したことと、ほぼ同じことを言っていることがわかります。
当たり前といえば、当たり前のことなのですが、アセスメントモデルのプラクティスとして記載されてしまうと、求められていることがわかりにくくなってしまうのかもしれません。このように図で表現するとわかりやすいのではないでしょうか?
ご不明な点等あれば、弊社までお問合せください。
日吉 昭彦