リリースに向けた品質確認試験について(その2)
前述の通り、ルネサス製MCU(Rx231シリーズ)へのファームウエア移行に関するご依頼を頂き、準備を進めてきました。開発工程全体から見たときの品質確認試験の位置づけと前段の開発工程との関係をまとめたいと思います。
1.ウォーターフォール型の開発工程
今回の組込みファームウエアの移行をウォーターフォールモデル型の開発工程でみた場合、「構造設計」からのスタートになります。ただし、『コストダウンのためにハードウエアとソフトウエアの切り分けを再定義したい』や、『顧客要求を反映して機能をブラッシュアップしたい』となると、前工程の「機能設計」や「構造設計」からのスタートになります。リリースに向けては、品質確認試験前の開発段階で2.の視点でバグを潰せているかがポイントになってきます。

2.開発担当による事前確認
- ウォーターフォールの最下層にある「論理設計」、「コーディング」、「モジュールテスト」のループを回して、各モジュールが要求を満たすことを、信号タイミングや波形を基に判断します。要求に対するマージンを含めて「モジュールテスト」の段階でまとめておくと、後工程で問題が発覚し、切り分けを行う時に威力を発揮します。
- モジュールを組み合わせて行う「組合せテスト」(例、外部IFを経由して表示を制御する)については、仕様通りに動作することを確認する他に、連続してコマンドを送り続ける過負荷試験を行い安定動作を確認します。
- 全体が仕上がった後の事前確認「プログラムテスト」の段階では、品質確認試験項目をN=1で良いので一通り実施する、バグ死滅曲線を描いてみて問題を出し切ったことを定量的に判断するなどを行います。
- 品質確認試験に使用する試験プログラムは「プログラムテスト」段階で使用に耐えられること、計測データが正しく記録できることなどを品質確認試験実施者と確認します。
3.品質確認試験
- 試験項目や数量に対する考え方は前回投稿したので省略しますが、試験に投入するサンプルは、量産工程で製造し、検査に合格した試作品を用います。量産工程の検査でNGが出れば開発に戻して原因の究明を行います。
- 品質確認試験は、開発者とは別の方が行います。開発者は長い期間プログラムやその挙動を観察しているため、正常性バイアス(多少異常なことが起きても心を正常に保とうとする心理傾向)が働き、異常と認識しない可能性があるためです。
- また、大手メーカで発覚した品質不適切事案(例、三菱電機株式会社の不適切行為に関する調査状況)をみると、開発に関与しない評価担当者が品質確認試験を実施することで、試験結果に対する信憑性が担保できると考えます。
品質確認試験の項目について不安を感じる方は、ホームページのお問い合わせのページからお知らせください。

