ソフトウェアテストの最も基本の技法といえば、境界値分析と、同値クラス分割の名前が挙がります。今回はその境界値のお話しです。
境界値分析はテストの際の基本中の基本ともいえる考え方です。なぜか。実際境界値付近は「バグ多発地帯」だからです。
さて、G.マイヤーズが、古典的名著『ソフトウェアテストの技法』の中で、同値クラスと境界値（限界値）テストの有効性を高々と掲げてから、はや30年以上が経過しました。にもかかわらず、今なお、境界値近傍が「バグ多発地帯」であり続けているはなぜでしょうか。いい加減、根本的な対策法が開発されて、いいようなものなのに。原因を1つに絞り切ることはできませんが、やはり大きな原因は「人間の側」のミスがあとを絶たないからだ、と思います。
ソフトウェアテストの本を読んでいても、『境界値付近はバグが多い。なぜならif文の条件で「＜」や「≦」などを取り違える可能性が高いからだ』と書かれています。実際そうであることが多いのですが、しつこくもう一度質問。なぜ、いつまでもその状態が、放置され、「バグ多発地帯」のままなのか。
テストの仕事をしていて感じるのは、「仕様の書き方が、あまり変わらない」ということが原因の1つとして挙げられるのではないか、ということです。上流工程で作成される仕様書では、たとえば「入力値は10から100までの範囲を有効とする」と、さらりと日本語で書かれていることが少なくありません。
この文章を読んだ時点で、テスト担当者としては質問が口をついて出ざるを得ません。「10と100は有効に含まれますか？」「入力値は整数ですか？」「小数点何ケタまで有効ですか？」（余談ですが、仕様書の記述にこの「…から…まで」の表現を発見し、すでにその仕様書を使って実装が終わっていることを知ったら、テスト担当者としては、気合を入れ直したりするものです。「ああ、このソフトはバグが多いかも」と）。
開発プロセスにおける「設計」「実装」「テスト」の3地点は、一本の糸で結ばれており、各地点における担当者の認識は極力一致するようにしておきたい（筆者は勝手に「3点の一致」と呼んでいます）。
言い方を変えるとこの「3点の不一致」が境界値における多くのバグを作り出す原因と言えると思います。ならば、それを逆手にとって「下流でできるだけ認識がずれないような仕様を書こう」という考え方を改めて提案したいのです。「なんだ、バカバカしい。そんなの当り前じゃないか！」そう思っていただいた方には、テスト担当者としてうれしく思います。本当にそれが「当り前」の考え方であって欲しいのです。近年、仕様記述の方法も大きく進歩を遂げています。ですが、まだまだ開発の現場では「不一致」を呼び込みやすい仕様の記述を多く見かけてしまうのが実際です。
設計フェーズで仕様書をレビューする際、「～から、～まで」のような記述には指摘の赤を入れる。「＜」「≦」などの記号使用を奨励し、可能ならば、「数直線」を添えること。中学校で習った時のように、ベタですが、端点が含まれるのか、含まれないのかが一目でわかるように、「＜」であれば「○」、「≦」であれば「●」を記入しておく。そして、整数なのか、小数点は何ケタまで有効なのか、その数直線の「刻み」も明記しておく。（図1参照）。時間がなければ、手描きで数直線を描いて仕様書にはりつけるか、スキャンした画像を添付するだけでもいい。
図1 できるだけ仕様書から境界値の誤解の余地を減らしていく
これだけでも下流工程におけるバグが減っていきます。
「知ってるよ」「当り前だ」と思われた方の中でも「実際にやっているよ」という方はどれだけいらっしゃるでしょうか。あるいはご自身は心掛けていても、チーム全体、会社全体となるとどうでしょう。ソフトウェアのバグは、まだまだ、人間的な部分が多くを占めています。
「ずれ」「誤解」「勝手な解釈」を許さない仕様記述は、「当り前」だけどなかなかできていないこと。でも「今日からできること」もたくさんあります。毎日の開発業務改善の際のヒントにしていただければ幸いです。
次回は「同値クラス分割」です。
