コメントを残すヒューマンクレストの磯部です。年度も明けたので、特に業務的な要請はないけれど改元のテスト観点を考えてみました。いう切り口で書き出していきます。入力処理まずは当たり前のところから。新年号に応じた略記号も入力で使いますね。和暦で入力できる場合、正しい値(例えば、[新年号]元年5月1日)以外に、正しくない値(例えば、平成31年5月1日)でも試す必要があります。エラーが出る、正しい値に変換されるなど処理がどうなるかは仕様次第です。平成31年5月1日のような過去に正しかったけれども、現在は正しくなくなった値は要チェックだと思います。入力したものが表示できることは当然確認するとして。「平成」のような合字を使用しているならば、テストが必要です。1文字に割り当てられているのですが、新年号が決まると新しくコードが割り当てられるそうです。新元号への対応についてのアップデート)アプリケーションだけでなく、フォントとかOSがからんでくるので、いかにもバグが出そうですね。和暦と西暦の変換については、入力処理で記載したような値は網羅してテストすべきでしょう。正しくない値として、平成31年4月31日のような存在しない日付を変換してみるのも必要です。平成31年5月1日のようなパターンでは、西暦との相互変換をした場合に、変換と逆変換をかけると元の値に戻ってこない気がしますね。1つの日付ではなく、日付の期間や、日数計算などがあると、考慮事項が一気に膨らみます。全てUTCに変換してから計算するのであれば、変換をしっかりテストすれば良さそうですが。平成30年4月1日〜平成33年3月31日の期間の日数を計算する場合はどのようなアルゴリズムになっているか。このあたりは、ブラックボックスでテスト設計するにも限界がありそうで、アプリケーションの内部仕様を深掘する必要があります。新規リリース・新規サービス開始でないかぎり、新年号に対応したバージョンにどこかで切り替わることになります。処理やステータス遷移が、バージョン切替えをまたいで行われる場合は、特に注意が必要です。バージョンアップは新年号への切替え前だから、と油断は禁物です。未来日を扱うケースは多く考えられます。期限の終わりや、なにかの終了日は何年も後になるケースもあるので要注意です。保存についても、内部仕様が気になるところです。すべてUTC保存であれば、前記で上げたような値に対して、保存されていることを確認するだけで問題ないのですが。こんな現実もありますし。なんらかの形で保存されているのであれば、それに対する確認が必要となります。既存データの参照だけでなく、更新で問題が起きないかも確認します。既存データを編集して何も変えずに再保存というのも注目ポイントですね。おわりになるべく特定のサービスを想定せずに、一般的な観点として考えてみました。なかには本当に改元対応のテストを業務で行う方もいらっしゃるかもしれませんが、参考になれば幸いです。予定がないみなさまも、「こんなところをテストする」「ここでバグが出るはず」と考えてみてはいかがでしょうか。TweetQuesとは?Quesとは、Software品質保証に関わるQAエンジニアの活性化を目的としたQA専門のイベントです。Software品質保証に関わるQAエンジニアの方が、会社間の垣根を越えて、情報交換や交流を深めてもらう事で、日本のSoftware品質保証を盛り上げていく場にしたいと思います。(2)主催:協賛:運営:。