前回に続き、地道なテストの重要性について考える。特にエラー処理、例外処理については、正常処理以上の時間をかけて、テストの網羅性を追求しなければならない。
 |
テストによって、ソフトが仕様書通りにできていることを確認できれば何も問題ないはずだが、いくら整然と仕様書が書かれていても完ぺきはあり得ないし、顧客と設計者の間の暗黙の了解や、当然の常識はまず仕様書には書かれていないと考えたほうがよい。
さらに、その後に顧客から要求された仕様変更は、議事録やメールに記録があっても、仕様書にまで反映されていないことがある。ましてエラー処理については、せいぜいその2割程度しか仕様書には書かれていないとも言われる。したがってテスト担当者は、仕様の書き漏れがないかを再確認するとともに、少しでも不明確なところは設計者や顧客によく質問する癖をつけたい。
 |
異常ケースのテストをきちんとやれば、正常ケースは自ずときれいになるものだ。四隅をきれいに拭けば真中は意識しなくてもきれいになるという“窓拭きの要領”と同じである。正常ケースが動いたからといって周囲を安心させたものの、実は異常ケースが穴だらけで、その後に大混乱に陥ったシステムもある。特に通信制御にからむリアルタイム処理や、マン-―マシン・インタフェースなどでは、異常処理や例外処理のほうが正常処理や通常処理よりもかなり多いのが実態だ。
例外ケースのテストは面倒だし、地味なため、とかく後回しになりがちだが、テストは例外ケースから着実にこなすべきである。正常ケースはついでにテストできてしまうのだ。
 |
仕様書やマニュアルに規定されていない入力に対し、システムになんらかの異常が起きないかどうかのテストは極めて大事であるし、例外ケースにおけるバグの検出にも効果がある。特に、エンドユーザーやオペレータは勘違いを起こしやすいし、勘違いしなくても操作ミスは起こすため、規定外の間違い入力に対する耐性が十分あるかどうか、さらに誤操作に対する修正が簡単かどうかまでテストしておきたい。
また、他のテストや総合テスト中に、誤操作によって何か困ったことが起きたときは必ず報告してもらえるように、トラブル時の報告フォーマットを用意し、できるだけ詳しい状況情報の確保に努めることも大事である。
 |
例外処理事例テストの一例として、システムが取り扱う数値データの範囲についてもよく見ておきたい。全数値についての確認は現実的ではないので、少なくともレコードごとに、最小値、最大値、中間値、最小値－α、最大値＋α、の5つのケースについてテストしておきたい。
また、取り扱うレコードの長さと、これを収容する媒体の物理的境界値との関係についてもよく見ておきたい。例えば、磁気デイスク装置にレコードを収容する場合、レコードの長さによって、1つのブロックに収まる場合もあれば、複数ブロックをまたがる場合もある。さらには、トラックやシリンダをまたがる場合もある。このような各段階のまたがりについて、どんなケースが発生するかを分析し、各ケースについてしっかり確認しておくこと必要がある。
