上流工程で効く、「テストの考え方」

第2回境界値バグは上流で潰したい

ソフトウェアテストの最も基本の技法といえば、境界値分析と、同値クラス分割の名前が挙がります。今回はその境界値のお話しです。

境界値分析はテストの際の基本中の基本ともいえる考え方です。なぜか。実際境界値付近は「バグ多発地帯」だからです。

さて、G.マイヤーズが、古典的名著『ソフトウェアテストの技法』の中で、同値クラスと境界値(限界値)テストの有効性を高々と掲げてから、はや30年以上が経過しました。にもかかわらず、今なお、境界値近傍が「バグ多発地帯」であり続けているはなぜでしょうか。いい加減、根本的な対策法が開発されて、いいようなものなのに。原因を1つに絞り切ることはできませんが、やはり大きな原因は「人間の側」のミスがあとを絶たないからだ、と思います。

ソフトウェアテストの本を読んでいても、⁠境界値付近はバグが多い。なぜならif文の条件で「<」「≦」などを取り違える可能性が高いからだ』と書かれています。実際そうであることが多いのですが、しつこくもう一度質問。なぜ、いつまでもその状態が、放置され、⁠バグ多発地帯」のままなのか。

テストの仕事をしていて感じるのは、⁠仕様の書き方が、あまり変わらない」ということが原因の1つとして挙げられるのではないか、ということです。上流工程で作成される仕様書では、たとえば「入力値は10から100までの範囲を有効とする」と、さらりと日本語で書かれていることが少なくありません。

この文章を読んだ時点で、テスト担当者としては質問が口をついて出ざるを得ません。⁠10と100は有効に含まれますか?」⁠入力値は整数ですか?」⁠小数点何ケタまで有効ですか?」⁠余談ですが、仕様書の記述にこの「…から…まで」の表現を発見し、すでにその仕様書を使って実装が終わっていることを知ったら、テスト担当者としては、気合を入れ直したりするものです。⁠ああ、このソフトはバグが多いかも」と⁠⁠。

開発プロセスにおける「設計」⁠実装」⁠テスト」の3地点は、一本の糸で結ばれており、各地点における担当者の認識は極力一致するようにしておきたい(筆者は勝手に「3点の一致」と呼んでいます⁠⁠。

言い方を変えるとこの「3点の不一致」が境界値における多くのバグを作り出す原因と言えると思います。ならば、それを逆手にとって「下流でできるだけ認識がずれないような仕様を書こう」という考え方を改めて提案したいのです。⁠なんだ、バカバカしい。そんなの当り前じゃないか!」そう思っていただいた方には、テスト担当者としてうれしく思います。本当にそれが「当り前」の考え方であって欲しいのです。近年、仕様記述の方法も大きく進歩を遂げています。ですが、まだまだ開発の現場では「不一致」を呼び込みやすい仕様の記述を多く見かけてしまうのが実際です。

設計フェーズで仕様書をレビューする際、⁠~から、~まで」のような記述には指摘の赤を入れる。⁠<」⁠≦」などの記号使用を奨励し、可能ならば、⁠数直線」を添えること。中学校で習った時のように、ベタですが、端点が含まれるのか、含まれないのかが一目でわかるように、⁠<」であれば「○⁠⁠、⁠≦」であれば「●」を記入しておく。そして、整数なのか、小数点は何ケタまで有効なのか、その数直線の「刻み」も明記しておく。図1参照⁠⁠。時間がなければ、手描きで数直線を描いて仕様書にはりつけるか、スキャンした画像を添付するだけでもいい。

図1 できるだけ仕様書から境界値の誤解の余地を減らしていく
図1 できるだけ仕様書から境界値の誤解の余地を減らしていく
※ 当初掲載していた図に誤りがありました。お詫びして訂正します。ご指摘いただいた皆様、ありがとうございました。⁠著者、編集部)

これだけでも下流工程におけるバグが減っていきます。

「知ってるよ」⁠当り前だ」と思われた方の中でも「実際にやっているよ」という方はどれだけいらっしゃるでしょうか。あるいはご自身は心掛けていても、チーム全体、会社全体となるとどうでしょう。ソフトウェアのバグは、まだまだ、人間的な部分が多くを占めています。

「ずれ」⁠誤解」⁠勝手な解釈」を許さない仕様記述は、⁠当り前」だけどなかなかできていないこと。でも「今日からできること」もたくさんあります。毎日の開発業務改善の際のヒントにしていただければ幸いです。

次回は「同値クラス分割」です。

おすすめ記事

記事・ニュース一覧