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

7つの基本的な出荷基準で“正しく手抜きをする”には？ 品質確保における手抜きのガイドライン「松」「竹」「梅」について詳しく見ていこう！

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

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

	①同値分割での 機能テスト	②境界値分析		③パス網羅 （含机上での網羅）	④バグ推測
			境界値			限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて
表1　品質手抜きのガイドライン

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

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

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

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

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

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

	①同値分割での 機能テスト	②境界値分析		③パス網羅 （含机上での網羅）	④バグ推測
			境界値			限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度

・松：【フルセットを完全に実施】

高信頼性が要求されるプログラムでは、“すべての入力値”について、強制的なパッチによる「無理やり同値分割テスト」を実施すべきです。

・竹：【フルセットを完全に実施と代表的なものを実施の中間】

特に、生命に影響したり、重大な環境破壊を起こす可能性があるような入力値に対し、強制的なパッチによる無理やり同値分割テストを実施します。

・梅：【代表的なものを実施】

通常の同値分割法でテストします。

2．境界値分析

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

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

	①同値分割での 機能テスト	②境界値分析		③パス網羅 （含机上での網羅）	④バグ推測
			境界値			限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度

・松：【フルセットを完全に実施】

限界値の外側（無効やエラーになる値）もチェックします。

・竹：【フルセットを完全に実施と代表的なものを実施の中間】

限界値の内側（最大の正常値）まではテストします。

・梅：【代表的なものを実施】

簡単に条件を揃えられる境界値、限界値だけをテストします。

3．パス網羅

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

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

	①同値分割での 機能テスト	②境界値分析		③パス網羅 （含机上での網羅）	④バグ推測
			境界値			限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度

・松：【C1網羅を80％以上カバー】

C1網羅は非常にキツイ基準であり、全般的に80％カバーするのも非常に難しいといえます。そのため、重要な機能についてのみ80〜100％網羅するなど、メリハリを付けたカバレッジをオススメします。

・竹：【C0網羅を80％以上カバー】

「たかがC0網羅だろ？」という声が聞こえてきそうですが、それでもC0網羅を80％カバーするのは、かなり大変です。世の中に、決して間違いを犯さず、悪意を持たない人しかいないとすると、世界の作業の80％は不必要になります。例えば、鍵のように人間不信を象徴するモノはもちろん必要ありませんし、犯罪や交通事故もあり得ないので警察や警備会社も不要。スーパーマーケットでは段ボール箱を置き、「各自、ここに品物の代金を入れてお釣りをお持ちください」と書いておけばいいのですから。ソフトウェア開発の世界では、ソースコード全体の半分以上が異常処理や境界処理であることを考えると、エラーケースのエラー処理などという特殊な条件も含んでC0網羅をすべてカバーすることはかなり困難だと思います。

・梅：【実施せず】

「パス網羅？ それ何？」というエンジニアはさすがにいないでしょうが、ここではC0網羅を実施しない代わりに、「どうやって品質を保証するべきか」をきちんと考えておく必要があります。

4．バグ推測

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

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

	①同値分割での 機能テスト	②境界値分析		③パス網羅 （含机上での網羅）	④バグ推測
			境界値			限界値
そこそこ実施（梅）	○	○	○	―	―
かなり実施（竹）	◎	◎	◎	C0を80％以上	外部破壊、深刻のみ
完全に実施（松）	●	●	●	C1を80％以上	外部破壊、深刻、プラス、中程度

・松：【外部破壊、深刻、プラス、中程度】

テスト項目を設計する基本、「バグを想定し、それを摘出するテストデータを作る」をしっかりと実施します。

・竹：【外部破壊、深刻のみ】

環境破壊や人命に大きな影響がある深刻なバグを想定し、それを摘出するテスト項目を中心に設計します。

・梅：【実施せず】

バグ推測をじっくりと実施する時間的余裕がない場合、バグを想定し、それを摘出するためのテストデータを作るという超原則を守ってはいません（きっと守れないでしょう）。実施していないという事実をしっかりと認識したうえで、ここでは思い切って手抜きをしましょう。

5．極限テスト

5．1．過負荷テスト

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

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

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて

・松：【フルセットを完全に実施】

最大の負荷が掛かった状態でのテストをしっかりと実施します。

・竹：【実施せず】

実施したい気持ちはあるのですが、時間的、精神的に余裕がありません。神に祈るだけです。実施していないという事実をしっかりと認識しておきましょう。

・梅：【実施せず】

例えるなら、過負荷テストまで考えがまったく及ばない余裕のない状態です。こうなると、ユーザーがギリギリのハードウェアリソースで稼働させないよう祈るだけです。

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

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

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて

・松：【フルセットを完全に実施】

例えば「48時間連続稼働させるテストに合格しないと出荷しない」という基準に従います。この基準は案外厳しく、ほかのすべてのテスト基準に合格していたとしても、48時間耐久テストに耐えられるプログラムというのはそれほど多くありません。金曜日、帰宅前にプログラムを走らせ、月曜日に祈る思いで会社に行くと、起動後12時間で異常終了していた……なんてことがよくあります。メモリの解放漏れやバッファの食いつぶしなど、その原因はさまざまですが、このバグを見つけるのは簡単なことではありません。

・竹：【代表的なものを実施】

ここでの基準は「本来、48時間連続稼働させる必要があるが、そんな余裕がないので24時間に短縮する」というものです。これはあくまでわたしの経験則ですが、12時間以上の連続稼働に耐えられるなら、24時間、48時間にも耐えられるでしょう。

・梅：【実施せず】

「長時間耐久テストは実施せず」がこの基準です。長時間耐久テストを実施しないのは仕方がないのですが、“未実施である”ことを認識している必要があります。これが“正しい手抜き”の第一歩です。

5．3．最大構成テスト

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

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

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて

・松：【フルセットを完全に実施】

ここでは、最大構成を実機でテストします。非常に大掛かりで、準備に時間がかかります。「128台接続しても動作するのか？」というたった1件のテスト項目を消化するのに、数日は必要でしょう。

・竹：【フルセットを完全に実施と代表的なものを実施の中間】

最大構成テストを実機ではなく、シミュレータ環境で行います。とはいえ、シミュレータはシミュレータであり、実機による完全なテストではありません（ちょっと不安ですが……）。そこを認識しておく必要があります。

・梅：【代表的なものを実施】

手近にそろっているシステムの最大構成でテストします。ただし、「やらないよりはまし」という気休めでしかありません。最大構成で運用する顧客は必ずいるので、異常動作が起こる可能性が高いことを覚悟しておきましょう。

6．バグの収束

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

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

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて

・松：【十分考慮】

毎日、バグの発生をグラフにプロットして、発生傾向をチェックします。バグの発生曲線がフラットになったとき、「バグの水源が枯渇した」と判断し、出荷基準に達したこととします。

・竹：【考慮】

一応、松のようにバグの発生状況を毎日トレースします。しかし、発生曲線が完全にフラットになるまで待てなかったり、まだフラットにはなっていないけれども、発生したバグの重要性が低いものばかりだったりという場合に、「バグは疑似収束している」と見なして出荷するケースがこれに該当します。

・梅：【無視】

そもそもバグの発生曲線を毎日プロットすることに考えも及ばなかったり、プロットしているけれど、一切参考にしていない場合がこれに該当します。本来、バグ発生曲線をプロットしていないようなケースは完全に問題外ですが、現状を把握し、“どんな状況・タイミングでリリースするべきか”を意識しておくことが必須（これが、正しい手抜きの第一歩です）でしょう。

7．バグ修正

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

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

	⑤極限テスト			⑥バグの収束	⑦バグ修正
	過負荷テスト	長時間耐久テスト	最大構成テスト
そこそこ実施（梅）	―	―	○	無視	外部破壊、深刻
かなり実施（竹）	―	○	◎	考慮	プラス、中程度
完全に実施（松）	●	●	●	十分考慮	すべて

・松：【すべて】

摘出したバグは、スペルミスや誤字のような軽微なものも含めて、全件修正します。20年前、30年前のソフトウェア開発エンジニアには、「全バグ修正」は当たり前でしたが、いまでは珍しくなりました。

・竹：【プラス、中程度】

バグの重要性を「致命的」「重要」「軽微」の3つに分けた場合、「軽微」以外をすべて修正します。表示メッセージのテキストを大量に修正するなど、労力は大きいのに、品質がそれほど向上しない変更作業については、竹では（特に時間がない場合は）実施すべきではないでしょう。

・梅：【外部破壊、深刻】

さすがにこのバグを修正しないと、市場にリリースできないというような致命的なバグのみ修正します。ここでいう致命的なバグとは、（1）その製品の基本機能に関するバグがある場合（例えば、自動車の場合「走る」「曲がる」「止まる」のような基本機能関係のバグ）、（2）基本機能ほど重要な機能ではないが、その機能の代替機能がない場合（例えば、データの「移動」がバグで正しく動作しない場合でも、「コピー」と「削除」を組み合わせれば同じことができます。この場合は“代替機能がある”といえます）を指します。

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

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。