アドベントカレンダー２３日目 第２章 線を意識する（２）
こんにちは。リリカルです。前回の続きでWACATEの予習です。
WACATE2016 夏 満員御礼！と 予習内容について - WACATEブログ
第２章 線を意識する
前回に続き、境界値分析や同値分割の例題が扱われています。実数の境界値分析における考え方や、複数の変数の同値分割と境界値分析についてです。ここでは問題は割愛しますが、ここで注意するのは「異常値は他の異常値を隠す」ということです。
これは意外とやりがちです。（特に、テストを急いで終わらせようとしたり、テストケース数をなるべく減らそうとした時に）
ドリル本の例では「アルファベットの大文字・小文字、数値のみが入力可能」というのと「文字列長は５〜３０文字」という仕様に対して、"@ABC"といったテストデータを使うとどうなるか、ということが書かれています。
一見、ここでエラーとなれば「特殊文字でエラーになる」と「文字列長が５文字未満だとエラー」の、一度に二つの要素が確認できるように思えますが、これでは一体どちらが原因となってエラーとなったのか外からではわかりません。あるいは、特殊文字を先にチェックするロジックが組まれていたらそもそも文字列長は見ない実装になっているかもしれません。
「このテストケースは何を確認したいものか？」というのは常に意識すべきです。これはドリル本p.26のテストデータの例に「本テストデータを選んだ理由」という欄があることからもうかがえます。そして、一度に検証できる異常値は１つであるということも覚えておくべきことです。
バグの検出に有効なテストケースを絞り込むという文脈においてテスト技法を使うことは大切ですが、それ以前に必要なテストが漏れてしまってはどうしようもありません。発散させてないのに収束させようとしているわけですから、余計にテストの質が下がってしまいます。
ドリル本ではこのほかに、日付と時刻における境界値分析、ループ境界のような隠された境界値、負荷テストについても扱っています。
隠された内部的な値を使ってテストするのはグレーボックステストとも言われ、とても重要です。自分も、以前テストしていた時に全く意識していなかった境界からバグが出て、「なぜ？」と開発者に聞いてみたら、全く想像していなかったステータス値が制御に使われていたことがありました。こう言った実装に近い話はぜひ首を突っ込んで聞いてみるといいと思います。開発者にとっては当たり前の情報も、テストする側にとっては宝のような情報となることがあります。
次回予告
次回は第３章、「面で逃さない」に入っていきます。
