「品質での手抜き」と「駐車違反」の共通点：山浦恒央の“くみこみ”な話（12）

何を満足すれば、ソフトウェアが出荷基準に達したと判断できるのか？ 「基本的な出荷基準」の詳細と具体的な“手抜き”の方法を紹介する

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

――何を満足すれば、ソフトウェアが出荷基準に達したと判断できるのか？

　これはソフトウェア技術者の永遠の課題です。前回のコラム「『3匹の子豚』から学ぶ品質の優先順位付け」では、グレンフォード・マイヤーズの古典的名著『ソフトウェアテストの技法』に書かれている3つの必要条件に筆者の経験則4つを加えた、計7つの「基本的な出荷基準」を掲げました。今回は、その詳細と具体的な手の抜き方について解説していきます。

　まずは前回のおさらいとして、再度、基本的な出荷基準について以下に示します。

1. 全機能をテストした　
   ブラックボックス／ホワイトボックス・テストで同値分割を実施した。
2. 境界条件をテストした　
   ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。
3. 未実行コードがない　
   ホワイトボックス・テストのC0パス網羅を満足した。
4. エラー・ゲシング（Error Guessing）を実施した　
   バグを想定し、それを摘出するためのテスト項目を設計・実施した。
5. 長時間耐久テスト、過負荷テストを実施した　
   48時間の連続運転や、過負荷状態での稼働テストを実施した。
6. バグの発生が頭打ちになった　
   いわゆる「バグ摘出曲線」がフラットになった。
7. 未修正のバグが残っていない　
   摘出したバグは全件修正した。

　理想的には、この7つを完全に満足していれば、非常に高い品質を確保できますが、もちろん、そのためには、時間とお金と工数が掛かります。品質確保はタダではありません。時間とお金が掛けられない場合は、「品質のトリアージュ」として、7つの基本的出荷基準を『完全に実施』『かなり実施』『そこそこ実施』の3つのレベルに分類し、そのうち、どれを現在の人員と残り時間で満足できるかを判断することになります。つまり、どこを頑張って、どこで手を抜くのかを工学的に判断したり、選択したりする必要があるということです。

　この「手を抜く場合の戦略」では、エンジニアとしての“センス”が表れます。手を抜く場合、どの程度まで手抜きをするのか、定量的に把握しておくことが非常に重要です。例えば、駐車違反（実際は良くないことです！）をする場合、「15分なら巡視が来ないから大丈夫なはず。いま、8分経過したので、あと7分余裕がある」と認識するのと似ています。この駐車違反の例え話と同様に、意識的に本来良くないこと、つまり“品質で手抜きをする”場合は、適当に行うのではなく、用意周到にキチンと実行する必要があるのです。

　以下、各基準の説明と手抜きの3段階レベルについて解説します。

1．全機能をテストした

　機能をブラックボックス的、ホワイトボックス的にテストをしたかという基準です。開発した機能を1回もテストせずに出荷することは「ソフトウェア・エンジニアの道義」としてあり得ません。犯罪現場を警察官が見て見ぬ振りをして素通りするようなもので、職業的倫理感が欠落しています。そんな人は、直ちに別の仕事を探すべきです（転職しても、ウマくいくとは思えませんが……）。

　プロのソフトウェア技術者とアマチュアの大きな違いは、“どのように機能をテストするのか”にあります。テスト項目を設計する場合、技法を使わず自己流でぼんやり作っていると、「あれもテストしなきゃ」「これもチェックしなきゃ」と、爆発的に件数が増えて、あっという間に数百、数千項目にもなってしまいます。

　テスト項目設計の基本は「なるべく少なく」、しかも「重要な項目をカバーする」ことです。テスト件数を抑える方法として、30年前から有名で、かつ有効とされているのが「同値分割（Equivalent Partitioning）」という技法です。

　ものものしい名前が付いていますが、基本的な考えは超簡単です。例えば、「入場料算出プログラムでは、6歳未満の場合、入場料は無料、7歳から12歳までは200円、13歳から18歳まで500円、19歳以上は1000円と表示する」という機能をテストする際、年齢の各範囲から代表的なものを1つ選んでテストすればよいというものです。具体的には、7歳から12歳のカテゴリでは9歳を、13歳から18歳の範囲では15歳を1つだけテストすればよいという考え方です。初心者は不安になって、8歳、9歳、10歳とたくさんテストしがちですが、各カテゴリを代表するデータを1つだけテストすれば十分なのです。

　同値分割では、ブラックボックス的な機能をテストするのが基本であり必須です。さらに、ホワイトボックス的にも同値分割技法を適用する必要があります。これは、外部的な機能に現れない仕様、例えば1万件までの固定長レコードをソートするプログラムがあり、内部処理として1000件まではメモリ上でソートするが、1001件以上は磁気ディスクを作業用ファイルとして使用するといった仕様があるとします。この場合、例えば1000件以下のカテゴリの代表値として888件によるソートを、1001件以上の代表として9999件によるソートを選ぶ必要があります。これがホワイトボックス的な同値分割です。

　「全機能をテストした」という基本的出荷基準の3段階の「手抜き」のレベルとして、機能ごとに「機能を正常ケース、異常ケース、境界ケースについてキチンとテストした」「正常ケースと代表的な境界・異常ケースのみテストした」「正常ケースのみテストした」に分かれます。

　ソフトウェア業界におけるテスト項目数の一般的な平均として、正常ケースは全体の60％以下、異常、境界関連の項目数がそれぞれ20％以上といわれていますので、「正常ケースのみのテスト」では40％以上の手抜きができ、「正常ケースと代表的な境界・異常のみ」では20％手を抜けることになります。

　品質で手を抜く場合に重要なことは、テスト項目を設計する段階でテスト項目1件ごとに、「正常ケース」「異常・境界の代表的ケース」「それ以外」の3つに分類しておくことです。プロジェクトが混乱してから、テスト項目を分類して「正常ケースと、異常・境界の代表」を抽出するのでは遅過ぎます。これでは時間がかかりますし、余計に混乱を招いてしまいます。「平和なとき」に将来の混乱時の対策をしておくことが「正しい手抜き」につながります。

2．境界条件をテストした

　これは、機能の境界や限界をブラックボックス的、あるいは、ホワイトボックス的にテストしたかどうかの基準です。専門用語では、「境界値分析（Boundary Analysis）」と呼びます。

　プログラムの不良で圧倒的に多いのが、境界、限界に関するものです。「20歳以下」を「20歳未満」と勘違いするなんてことがよくあります。この“バグの王様”を摘出するのが境界値分析の目的です。同値分割の場合と同様、境界値分析でもブラックボックス的境界値分析と、ホワイトボックス的境界値分析があります。

　同値分割の基本は「あるカテゴリから代表値をテキトーに1つ選ぶこと」です。「テキトーに選べばよい」のなら、境界値と重複させると効率の良いテスト項目を設計できることになります。同値分割と境界値分析を融合させて、かつ、機械的に（高速、かつ専門知識を必要とせずに）テスト項目を作成する方法が「カテゴリの両端をテストする」ことです。

　例えば、「入場料算出プログラムでは、6歳未満の場合、入場料は無料、7歳から12歳までは200円、13歳から18歳まで500円、19歳以上は1000円と表示する」という機能をテストする場合、7歳から12歳のカテゴリでは7歳と12歳を、13歳から18歳の範囲では13歳と18歳を選べば、深く考えなくても「打率の高い」テスト項目を設計できます。

　境界値分析における手抜きの3レベルは、「境界値をテストしない」「重要な境界値のみテストする」「全部の境界値をテストする」になります。境界値のテストで、一番面倒なのが最大値のチェックです。

　例えば、「本システムには、最大512台の端末が接続できる」と仕様書に書いてあれば、この最大構成のシステムを構築してテストしなければなりません。最大構成テストの準備はものすごく大変で、何日もかかります。時間がないプロジェクトでは、真っ先に割愛されるのがこのテストです。

　「全機能の実施」におけるテストと同様、境界値分析でもテスト項目を設計するときに「重要な境界値」かどうかをあらかじめ分類しておくと、混乱時にスムーズに手抜きができるようになります。

　さて次回は、残りの基本的出荷基準について解説します。特に「3．未実行コードがない」は、誤解が多い基準ですので、例と図を使って詳細に説明したいと思います。お楽しみに！ （次回に続く）

【 筆者紹介 】

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

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

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