こんにちは。エムスリーエンジニアリンググループ QAチームの城本(@yuki_shiro_823)です。こちらはソフトウェアテスト Advent Calendar 2020の9日目の記事になります。
ソフトウェアテストについてのPodcast「テストラジオ」で、以前日付の絡むバグの話がとりあげられており、それにインスパイアされて書きました。
私が今まで日付にまつわるテストをするときに、困ったことやテスト実施の時にどうしたか、経験をまとめてみます。この記事で扱っている範囲は結合テスト～システムテストで、主に画面を操作して行う試験です。
日付のテストで困ること
日付のテストでよく困ることに、特定の条件を満たす日付でテストをする必要があるが、その条件をどうやって整えたらよいかということが挙げられると思います。例えば、週単位や月単位で何かの締め作業が行われ、次の週や月から新しいカウントが始まる、というパターンはよくあると思います。このような場合、週末/週始めや月末/月始めで、それぞれ期待される動作を確認する必要がありますが、どのようにして週末や月末の状態を作ればよいのでしょうか？
考えられるテスト実施のパターン
テストの実施方法は、疑似的に条件にあう日付の状態にしてしまうか、愚直に実際に該当の条件の日付が来るまで待って試験するか、の2パターンに分かれると思います。どちらになるかは内部の作りによるので、テスト設計のときに「このパターンの確認はどうやったらできますか？」と開発を担当しているエンジニアに聞くことが多いです。疑似的に条件に合う日付の状態にできる場合、かつ、試験環境で日付の操作が可能な場合は、次のいずれかの方法をとっています。
端末のOSの日付を書き換える
日付の判断が、ユーザが使っているブラウザやアプリのOSでの日付のみで行われ、それに応じて何らかの表示や操作できる範囲が変わる場合に使えます。例えば、12月中であれば12月の勤怠の登録や修正が可能、前月である11月分は操作不可というケースであれば、OSの日付変更で12月や11月にできると、月が替わったら操作できる範囲が変わるテストケースが確認できますね。
（ただし、会社支給のPCだと多くの場合で日付変更の権限がないため、この方法が使えないこともあります）
DBの特定のカラムの日付データを書き換える
DBの特定のカラムの日付や時刻を超えたことをトリガに何らかの処理が行われる場合に使えます。例えば、カラムに登録されている指定された日付で何かの終了処理を行う場合などに、DBの該当のカラムを直近の日付に書き換え、終了条件を作ってテスト実施することがあります（DBを書き換えることで試験したい内容に合致する条件が作れるかは、事前に開発エンジニアに確認が必要です）
DBを書き換える際にはタイムゾーンも確認しておいたほうが良いです。終了条件を整えたはずなのに終了しなかったのでバグかと思ったら、UTCで考える必要があったところをJSTで書いていて実際には終了条件が整ってなかった、ということがよく起こります。
システム側の日付を書き換える
日付の判断がバックエンドで動いているシステムの日付のみで行われている場合に使えます。試験実施時に開発エンジニアに依頼して変えてもらうなどの対応が必要になるかと思いますが、私のチームでは、QAエンジニアが試験実施時に自由に日付変更できるよう、システムの日付を任意のものに固定できるツールを作ってもらいました！ 日ごとに表示内容が変わるものや、開始日からXX日経過した場合に表示内容が変わる、などのケースを試験するのに重宝しています（こちらもシステムの日付変更で試験したい内容に合致する条件が作れるかは、事前に開発エンジニアに確認が必要です）
※上にあげたケースは、日付の判定が１カ所で行われている場合に有効なものになります。日付の判定が複数システムにまたがっていたり、関連するシステムすべての日付を合わせる必要があるときには、愚直に該当の日付が来るまで待って試験を行うことになると思います。以前に毎月1日にしか発生しない、かつ修正確認も1日にしかできないバグに遭遇したことがありますが、これは1日を待って修正確認しました。
まとめ
条件を整えるのが大変な日付にまつわるテストは、疑似的に条件にあう日付の状態にすることで楽にテスト実施できる場合があります。内部の作りに依存するので、開発を担当したエンジニアに相談の上、条件に合う日付に書き換えて試験できるか検討してみてください。
We're hiring!
QAチームではバグを見つけるだけでなく顧客の利益にコミットしたい人、チームとともに成長したい人を募集しています！ 社会に役立つシステムを高品質で素早く届けたいQAエンジニアの方、一緒に働きませんか？ カジュアル面談でより詳しくお話ししましょう！
