小ネタ：欠陥の混入、テストレベル、工程の責務

1. はじめに

欠陥は後工程で摘出するほどコストが膨らむため早期に摘出するのが理想です。とはいえ欠陥の種類によって早期に見つけられるものや後工程で初めて顕在化するものがあります。例えばコンパイラのwarningや静的解析ツールで見つかる欠陥はコーディング～ビルドの工程で見つけられますがエラー処理の欠陥はエラーの状況を準備しシステム動作を行うことで見つかるかもしれません。

「この手の欠陥はこの工程で摘出する」という工程の責務を定義しようと思いJSTQB FLシラバス(Version 2018)を読んだところ「2.2 テストレベル」の節にテストレベルごとに整理されていました。そこで責務はシラバスをご参照いただくこととし、ここでは欠陥の混入やテストレベルの補足をします。

2. 欠陥の混入

ソフトウェアの信頼性(G.J.マイヤーズ、訳:有澤 誠)にソフトウェアの開発とは変換の繰り返しであることが説明されておりそのモデル図を以下に引用します。この本が出版されたのは1977年ですが変換の繰り返しというのは現在でも変わらないです。

ソフトウェアの開発は要求→目標→高レベル設計→低レベル設計→プログラムというように大きな塊を段階的に詳細化しながら進行します。これら変換の過程で発生するエラー(誤り)が漏れや曖昧、間違い¹といった欠陥(フォールトまたはバグ)を誘発します。以下に一例を示します。

• 漏れ：条件の漏れ、機能(振る舞い)の漏れ、性能のような非機能要件の漏れ
• 曖昧：複数の担当者のあいだで認識の相違を招く表現
• 間違い：要求の間違い、要件の間違い、仕様の間違い、コーディングの間違い

プログラムの欠陥を実行し顕在化すると故障となります。

3. テストレベル

プログラムに限らず仕様書のような中間成果物も変換の過程で欠陥が入り込むため設計²の欠陥は設計の工程で検証し摘出します³。コーディングの欠陥はコーディングの工程で摘出するほか段階的にテストを行い除去します。

複数のシステムで構成されるシステムでは統合テストはコンポーネント統合テストとシステム統合テストの2つの異なるテストレベルがあります。システム統合テストはシラバスによると「システムテストの後、または実行中のシステムテスト活動と並列に行う」とあり、前者の例を以下に図解します。

1. 間違いだらけの設計レビューに倣うと「漏れ、曖昧、誤り」ですが本稿ではJSTQB FLシラバス「1.2.3 エラー、欠陥、および故障」のエラーという意味で「誤り」を用いているため「間違い」としています。 ↩

2. ソフトウェアの設計だけでなくテストの設計も含みます。 ↩

3. レビューを行ったりモデルやプロトタイプを作って確認したりします。 ↩