A-SPICEのテスト関連プロセス、検証、品質保証のすみわけ

昨日(今日の朝)に引き続き、A-SPICEの話です。

A-SPICEにはテスト関連のエンジニアリングプロセスがSWE.4~6、SYS.4~5とあります。それぞれソフトウェアユニット検証、ソフトウェア統合テスト、ソフトウェア適格性確認テスト、システム統合テスト、システム適格性確認テストです。ISTQB CTFL_AuT 2.4.2章によると、ISTQBの定義とのマッピングとしては、それぞれコンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、システムオブシステムズテスト、となるということです。

これらのエンジニアリングプロセスというメインのプロセス以外に、A-SPICEではMANやSUPといった周辺のプロセスが存在します。その中のSUP.1品質保証、SUP.2検証と前述のSWE.4~6、SYS.4~5のすみわけがよくわからない、と思われることが多いと思います。事実僕もそうでした。なので、その解釈を書いておきます。

SUP.1品質保証は、

作業成果物およびプロセスが~あらかじめ定義された規定および計画を遵守~していることを、独立的かつ客観的に保証することである

とA-SPICE3.1日本語版(↓)で言っています。

大切なポイントは「独立的かつ客観的に」という点です。有識者に聞いたところ、基本的には独立した品質保証のための組織を想定しているとのことでした。いわゆる品質保証部などですね。小さい組織では難しいかもしれませんが、解釈としてはそうなるようです。独立しているという意味では、エンジニアリングプロセスの中のテストとは別物と考えた方がよさそうです。

逆に、SUP.2検証は、エンジニアリングプロセスの中のテストと重複する部分があるようです。各要件を分析するプロセス(SYS.2やSWE.1)において検証戦略というものを策定するのですが、そことSUP2. BP.1は明らかに重複しています。なので、SUP.2としては各プロセス横断で検証という考え方を適用しなさいよ、と言っているように解釈できるかと思います。

似たような重複は各所に出現していて、SUP.8の構成管理については各エンジニアリングプロセスの重要なプラクティスになります。

というわけで、すべてのプロセスが直交しているなどとは考えずに、書いてあることを担保できれば大丈夫、と思っていればよいのだと考えます。

この記事が気に入ったらサポートをしてみませんか?