ヒューマンクレストの磯部です。
年度も明けたので、特に業務的な要請はないけれど改元のテスト観点を考えてみました。
『知識ゼロから学ぶソフトウェアテスト』にならって、入力・出力・計算・保存という切り口で書き出していきます。
入力処理
まずは当たり前のところから。
和暦で新年号を使った入力、特に境界値として年号切り替わりの 2019/04/30 と 2019/05/01 は必ずテストします。
新年号に応じた略記号も入力で使いますね。
和暦で入力できる場合、正しい値（例えば、[新年号]元年5月1日）以外に、正しくない値（例えば、平成31年5月1日）でも試す必要があります。
もちろん、エラーが出る、正しい値に変換されるなど処理がどうなるかは仕様次第です。
特に、平成31年5月1日のような過去に正しかったけれども、現在は正しくなくなった値は要チェックだと思います。
出力処理
入力したものが表示できることは当然確認するとして。
「㍻」のような合字を使用しているならば、テストが必要です。
合字は、Unicode で 1文字に割り当てられているのですが、新年号が決まると新しくコードが割り当てられるそうです。（参考サイト：Microsoft | TechNet 新元号への対応についてのアップデート）
アプリケーションだけでなく、フォントとかOSがからんでくるので、いかにもバグが出そうですね。
計算
和暦と西暦の変換については、入力処理で記載したような値は網羅してテストすべきでしょう。
正しくない値として、平成31年4月31日のような存在しない日付を変換してみるのも必要です。
平成31年5月1日のようなパターンでは、西暦との相互変換をした場合に、変換と逆変換をかけると元の値に戻ってこない気がしますね。
1つの日付ではなく、日付の期間や、日数計算などがあると、考慮事項が一気に膨らみます。
全てUTCに変換してから計算するのであれば、変換をしっかりテストすれば良さそうですが。
例えば、平成30年4月1日〜平成33年3月31日の期間の日数を計算する場合はどのようなアルゴリズムになっているか。
このあたりは、ブラックボックスでテスト設計するにも限界がありそうで、アプリケーションの内部仕様を深掘する必要があります。
また、新規リリース・新規サービス開始でないかぎり、新年号に対応したバージョンにどこかで切り替わることになります。
処理やステータス遷移が、バージョン切替えをまたいで行われる場合は、特に注意が必要です。
バージョンアップは新年号への切替え前だから、と油断は禁物です。
未来日を扱うケースは多く考えられます。
期限の終わりや、なにかの終了日は何年も後になるケースもあるので要注意です。
データ保存
保存についても、内部仕様が気になるところです。
すべてUTC保存であれば、前記で上げたような値に対して、保存されていることを確認するだけで問題ないのですが。
こんな現実もありますし。
昭和と平成をtrueとfalseで持ってる某省庁#IT業界クソ現場オブザイヤー2017
— mahkun (@mahkun_gohan) 2017年12月2日
和暦(年号) がなんらかの形で保存されているのであれば、それに対する確認が必要となります。
既存データの参照だけでなく、更新で問題が起きないかも確認します。
既存データを編集して何も変えずに再保存というのも注目ポイントですね。
おわりに
なるべく特定のサービスを想定せずに、一般的な観点として考えてみました。
なかには本当に改元対応のテストを業務で行う方もいらっしゃるかもしれませんが、参考になれば幸いです。
特に予定がないみなさまも、「こんなところをテストする」「ここでバグが出るはず」と考えてみてはいかがでしょうか。
Tweet