どうも、はるにゃんです。初投稿です。

元号改正、ついに今年に迫ってきました。
わたくしも元号改正チームに
「テストやって★」と追加戦士として参戦させられまして、頭を抱える毎日でございます。

そんなわけでソフトウェアテストエンジニア（仮）として昨年12月から勉強を始めていますが、
弊社にテストエンジニアが存在しないため、ここに書いて誰かが素敵な助言を下さることを期待しつつ、
元号改正の対応としてこういうテストをやればいいのかな？というのを考えてみました。

※ ここに書いたテストケースはあくまでも一例です。網羅性だのなんだのは何も考えていません。
実業務でのご利用は計画的に。

まずは想定している仕様

画面上で”元号頭文字+和暦/月/日”で入力をおこなう（例：平成31年2月10日→H31/02/10¹）。
DB上は西暦で保持しているので、和暦→西暦変換でDBへの登録、西暦→和暦変換で照会をします。
和暦でDBに保存してるとかっていう変態システムは想定の範囲外すぎます

仮に、新元号を"J:神化²"とします。

境界値分析

とりあえずテストの基本、境界値分析です。
平成と神化の境界は2019/04/30と2019/05/01ですので、
入力値としてH31/04/30とJ01/05/01をテストケースに入れるのは当然のお話です。みんなそうする、オレもそうする。

さて、平成の境界線と、神化の境界線を考えると、
平成：1989/01/08～2019/04/30
神化：2019/05/01～2999/12/31³
となりますので、H31/05/01とJ01/04/30も境界値分析的には必要になるのではないでしょうか。
コレかいてて気付いたんですが、J99/12/31ってどうなるんだろう。気になります！

では、平成と昭和の境界は…どうなんでしょう？
テストケースにくわえる必要ってあるのかしら？

とりあえずここまでで、大体こういうテストケースを作ってみました。

組み合わせテスト

組み合わせテストです。
日付で考えられる組み合わせについては、FromToの検索くらいなのですが、もし他にあったら教えてくださいっ＞＜；

FromがNULLの場合は1900/01/01
ToがNULLの場合は2999/12/31
となる仕様の場合を考えます。

大体こういう感じでしょうか汗

やってみた感想

考えるとやってみたくなるものですが、「バグでそうだなこれ」という勘が私に足りてないなという感想。
この程度のテストケースで出てくるバグなら、苦労しなさそうだなって…。