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

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

この記事を読むのに必要な時間:およそ 1 分

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

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

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

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

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

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

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

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

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

図1 できるだけ仕様書から境界値の誤解の余地を減らしていく

図1 できるだけ仕様書から境界値の誤解の余地を減らしていく

※ 当初掲載していた図に誤りがありました。お詫びして訂正します。ご指摘いただいた皆様,ありがとうございました。⁠著者,編集部)

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

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

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

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

著者プロフィール

石原一宏(いしはらかずひろ)

第三者ソフトウェアテスト専門会社バルテスのテスト技術開発部に所属。テスト技術の研究開発,社内・社外の技術研修・教育業務,コンサルティング業務に従事しつつ,ソフトウェア品質向上業務に携わる。

著書

コメント

コメントの記入