これが品質制御での手抜きのガイドラインだ：山浦恒央の“くみこみ”な話（20）

　前回、「7つの基本的な出荷基準」を挙げ、その一部、あるいは全部を割愛する“手抜きのガイドライン”を示しました。具体的には、7つの基本的な出荷基準と、品質確保での「松（手抜きせず）」「竹（少し手を抜く）」「梅（きちんと手抜きする）」の関係を表に示したのですが、今回はその表を以下に再掲し、品質制御での松・竹・梅の詳細を説明します。

　表1の①②……は、7つの基本的な出荷基準に対応しています。また、○は「代表的なものを実施」、●は「フルセットを完全に実施」、◎は「その中間」、―は「実施せず」を意味します。

　それでは、以下、7つの出荷基準における手抜きの松・竹・梅について解説していきます。

1．同値分割での機能テスト

　「同値分割」は効率を維持しつつ、テスト件数をなるべく少なくするために考え出されたテスト技法であり、テストの基本中の基本です。同値分割によるテストを完全に実施できないということはあり得ないはずですが、中には簡単にテストできない項目もあります。例えば、「このシステムが扱う貨物は、総重量が1000kg以下に限定する」との仕様があるとします。同値分割の手法を知っているエンジニアは、テスト項目として、「1001kg」「1000kg」を設計するでしょう。そして、1000kgが正常に処理され、1001kgがエラーとなった結果を見て、重量の上限テストとして「合格」と判断するはずです。しかし、わたしならもう一歩踏み込んで、「総重量が1001kgか？」とチェックしているIf文の後で“総重量を1001kgにする”よう、プログラム内のデータに強制的にパッチを当てます。無理やりセットした1001kgをエラーとしてきちんとはじけば本物です。

　本当にここまでやらなければならないのか？ もちろん、答えは「YES（イエス）」です。例えば、原子力発電所の制御プログラムのように、非常に高い信頼性を求められるソフトウェアで、実際にはあり得ない入力値や入力データの範囲チェックでエラーとなる値があるとしたら、エラー値を無理やり入れて、それでも誤動作しないかどうかをチェックすべきです。

　以下に、同値分割での機能テストにおける松・竹・梅を示します。

2．境界値分析

　「境界値分析」とは、“境界条件や限界条件上にはバグがたくさん潜んでいる”という30年前からいわれ続けている「ソフトウェアエンジニアの知恵」をベースにしたテスト基準です。グレンフォード・J・マイヤーズ（Glenford J. Myers）著の不滅のベストセラー「ソフトウェア・テストの技法」では、同値分割、バグ推測と並び、“テスト技法の三銃士”的に扱われています。

　以下に、境界値分析での松・竹・梅を示します。

3．パス網羅

　ホワイトボックステストの王様が「パス網羅」です。「1回も実行していないコードを出荷するのは、まともなプログラマのすることではない」という正論がベースになったテスト基準です。最低限、C0網羅（命令網羅）は100％カバーし、できればC1網羅（分岐網羅）は80％カバーしなければ……という志の高い声を聞きますが、実際には、C0網羅を80％カバーするのも簡単ではありません（この原因や事情は、「開発するのに30分、テストするのに10万年」を参照してください）。また、パス網羅では、それを支援するツールを使わないと大混乱することでしょう。基本的な考え方は簡単で、容易に理解できますが、実行する場合のハードルが非常に高いテスト基準といえます。

　以下に、パス網羅での松・竹・梅を示します。

4．バグ推測

　想像できないバグは摘出できません。QA（Quality Assurance）担当者がソフトウェア開発エンジニアよりバグを見つける能力が高いのは、漫然とテスト項目を設計しているのではなく、バグに対する想像力、知識、経験を駆使し、摘出するバグを想定（バグ推測）してテスト項目を設計しているためです。

　以下に、バグ推測での松・竹・梅を示します。

5．極限テスト

5．1．過負荷テスト

　携帯電話は、音声通信している最中にキャッチフォンが入り、同時にメールを受けるなど、複数プロセスを一定時間内に、限られたリソースで処理しなければなりません。このような過負荷状態のテスト（過負荷テスト）は、状態や環境を作るのに時間がかかり、かつ高度なテスト能力が求められます。

　以下に、過負荷テストでの松・竹・梅を示します。

5．2．長時間耐久テスト

　続いて、「長時間耐久テスト」での松・竹・梅を示します。

5．3．最大構成テスト

　仕様書に「本システムは、128台まで端末・周辺装置を接続できる」と書いたのなら、必ず「最大構成テスト」をする必要があります。

　以下に、最大構成テストでの松・竹・梅を示します。

6．バグの収束

　それまで、毎日20件以上もバグが出ていたのに、ある日を境に突然バグが出なくなることは、絶対にあり得ません。もし、そのような事象が発生したのなら、単にテストをしていないだけです。バグの収束状況をチェックすることは非常に重要ですが、時間がかかる“ぜいたくな品質制御”ですので、日程に余裕がないプロジェクトでは、最初から考慮されていない場合がよくあります。

　以下に、バグの収束での松・竹・梅を示します。

7．バグ修正

　摘出したバグが100件を超えるのに、リリース日が1週間後に迫っていて、全件を修正できない……というケースは、現代のデスマーチ型ソフトウェア開発で頻発します。

　以下に、バグ修正での松・竹・梅を示します。

　以上が品質における手抜きのガイドラインです。もしかすると、ここで紹介した梅よりもレベルを落としたテストをしてきた人もいるのではないでしょうか。そういった方は本稿を参考にしつつ、正しい手の抜き方を実践してみてください。（次回に続く）