テストの考え方

正常終了は複数ある

• フルインプット
• フルインプット以外
• データの型の違い
• フル桁
• フル桁以外

異常終了は正常終了より多くSubmitする

テストはバグを見つけることが目的です。
エラーになりそうな入力をして検証していく必要があります。

エラーデータを入れる箇所

同項目のインプット箇所が複数ある場合、下記にエラーデータを入れてみてください。

• 先頭
• 中間
• 最後

境界値に注意

> or <

birth < 20250101
この時テストする境界値は下記です。

• 20241231
• 20250101
• 20250102(あってもいい)

>= or <=

birth <= 20250101
この時テストする境界値は下記です。

• 20241231
• 20250101
• 20250102

色は変わったけど文字が変わっていないなど

エラーチェックの色が変わったので動作確認OKと思いきや、中の文字が変わっていなかったなどというケースもあるあるです。
俯瞰して見てみてください。

複数同時エラー

エラー処理が複数あり、それらを同時に発生させるとバグが生じることがあります。

すべて開発を終えてからテストする

すべて実装できていないけど、ここの処理は事前にテストしてしまおうと考えるのはNGです。
すべて完了してからテストをしましょう。

バージョン管理

うまく動作しないことで前のに戻すことは割とあると思います。
そんな時にせっかく実装した部分まで戻ってしまい、前のに戻しすぎてしまうこともあります。
ここまで戻すとどこが変わるのか考えてから実行しましょう。

良い出力にならない問題の原因を特定する

下記をチェックしてみます。
※スペルミスも含む

• 入力データは問題ないか
• 入力データを受け取った後の手順は問題ないか

すべてのロジックを通っているか

ソースコードを見てすべてのロジックを通るようなテストができているか確認をします。
テスト仕様書は設計書を見ながら作成しますが、最後にはしっかりとソースコードも見ます。