異常系とは何であるか考えよう

システムのテストを行う際、テストの内容を「正常系」と「異常系」に分類することがある。それぞれのテスト項目数や不具合の発生数などを数えて、テストの妥当性や品質の判断に使ったりするのである。

この正常系、異常系という言葉はよく耳にするのだが、その意味は曖昧であることが多い。人によって解釈が違うのである。

例えば、「ユーザーが入力ミスをしたケース」について、「正常な値が入力されていないのだから異常系だ」という人もいれば、「開発者がミスを想定していて、プログラムで入力チェックをしてメッセージを出すなどの処理をしていれば正常系だ」という人もいる。

これは、異常系のテストを、「エラー・ハンドリングのテスト」と捉えるのか、「ハンドリングされていない（開発者が想定していない）事象が発生したらどうなるかを確認するテスト」と捉えるのかの違いである。

どちらが正しいともいえないが、少なくともプロジェクト内で、メンバーの認識をあわせなければ、混乱を招くだろう（もちろん、正常系と異常系に分類しないという選択肢もある）。

★

もっとも、テストの呼び方を決めるのは難しくない。むしろ、何をハンドリングして、何をハンドリングしないのかを決めることのほうが難しく、しかも重要である。それは、本来、システムに求められる要件（サービスレベル）と開発期間やコストなどのバランスの中で判断されるべきものだ。

また、ハンドリングをするにしても、その処理内容（どんなメッセージを出すのか、どんなログを出すのか等）を決めておかなければ、システム全体としての統一性がなくなる。

しかし、現実には、こうしたことが設計の段階で決められておらず、プログラマの独断で実装される（または実装されない）ことも多いようである。そのため、同じシステム内で同じエラーが発生しても、画面によって表示されるメッセージが違う、というようなことがよく起こる。あるいは、同じようなエラーについて、ある人は関数の戻り値で返し、別の人は例外を投げる（いわゆる TRY-CATCH で処理する）というようなことも起こる。

このあたりも事前にルール化し、十分な例を示すなどしてメンバーに浸透させておかなければ、システムのユーザビリティや保守性が損なわれてしまう。

異常系の設計は、正常系に比べておろそかにされがちだ。しかし、ユーザーテストなど、プロジェクトの最後の方での「手戻り」に繋がりやすいところなので、気が抜けないところである。

応援のクリックお願いします →