システムのテストを行う際、テストの内容を「正常系」と「異常系」に分類することがある。それぞれのテスト項目数や不具合の発生数などを数えて、テストの妥当性や品質の判断に使ったりするのである。
この正常系、異常系という言葉はよく耳にするのだが、その意味は曖昧であることが多い。人によって解釈が違うのである。
例えば、「ユーザーが入力ミスをしたケース」について、「正常な値が入力されていないのだから異常系だ」という人もいれば、「開発者がミスを想定していて、プログラムで入力チェックをしてメッセージを出すなどの処理をしていれば正常系だ」という人もいる。
これは、異常系のテストを、「エラー・ハンドリングのテスト」と捉えるのか、「ハンドリングされていない（開発者が想定していない）事象が発生したらどうなるかを確認するテスト」と捉えるのかの違いである。
どちらが正しいともいえないが、少なくともプロジェクト内で、メンバーの認識をあわせなければ、混乱を招くだろう（もちろん、正常系と異常系に分類しないという選択肢もある）。
もっとも、テストの呼び方を決めるのは難しくない。むしろ、何をハンドリングして、何をハンドリングしないのかを決めることのほうが難しく、しかも重要である。それは、本来、システムに求められる要件（サービスレベル）と開発期間やコストなどのバランスの中で判断されるべきものだ。
また、ハンドリングをするにしても、その処理内容（どんなメッセージを出すのか、どんなログを出すのか等）を決めておかなければ、システム全体としての統一性がなくなる。
しかし、現実には、こうしたことが設計の段階で決められておらず、プログラマの独断で実装される（または実装されない）ことも多いようである。そのため、同じシステム内で同じエラーが発生しても、画面によって表示されるメッセージが違う、というようなことがよく起こる。あるいは、同じようなエラーについて、ある人は関数の戻り値で返し、別の人は例外を投げる（いわゆる TRY-CATCH で処理する）というようなことも起こる。
このあたりも事前にルール化し、十分な例を示すなどしてメンバーに浸透させておかなければ、システムのユーザビリティや保守性が損なわれてしまう。
異常系の設計は、正常系に比べておろそかにされがちだ。しかし、ユーザーテストなど、プロジェクトの最後の方での「手戻り」に繋がりやすいところなので、気が抜けないところである。
■関連記事
・どこまで書くか設計書
・曖昧言葉
・例外論 ～その１～ 警報
翔泳社 (2005/02/18)
売り上げランキング: 48245
現場の目で見た正直な視点が親しみやすい 実際にテストを行う人へ
始めに目を通しておきたい本
カットシステム (2006/11)
売り上げランキング: 372916
Javaからプログラミングを始めた人に
タイトルに偽りあり
」という本にも、「スパゲティコード」という言葉は出てきている。しかし、それは幾つもあるアンチパターンの中のひとつでしかない。つまり、悪いコードは「スパゲティ」という一言では表せないのである。プログラミング言語の発展により、そのパターンは、いっそう多様化してきたようにも見える。
良い本だと思うけど星３つの訳
