見出し画像

日付のテストについてふと思ったこと

156

仕事している時に思い出して欲しい過去テストの経験やアイデアが、仕事をしていない時に限って思い出したり思い付いたりすることがあります。

今回はふと頭に過った日付のテストについて思ったことを書いてみます。

■仕様によってはバリデーションで遊べない

以前関わっていた案件のとある追加機能のテストでの経験ですが、日付設定のUIがiOSではドラムロール、AndroidOSではカレンダーと言う仕様だったことがありました。

そのテストではもう一人のテスト実行者と分担してテストケース(設計？)も作成していたのですが、機能追加前のプロダクトをいじっていた時にドラムロールが例えば「4月31日」に設定しようとすると月の部分が4月から翌月5月にスライドするような形だったこともあって、この仕様だと存在しない日付を使った確認はできないんだな〜と思いながら作成していました。
もちろん4月31日が設定出来ちゃう仕様のドラムロールもあると思いますが。

更に言えば、カレンダー・タイプの物についてはカレンダーそのものが間違えていない限り存在しない日付の設定は不可能なんだなぁと気付きました。
※余談ですが、カレンダー・タイプだったそのUIでの年の設定が面倒臭いなぁとも思っていましたw

その時は設定可能な年齢の制限があったので、設定可能な生年月日になっているかどうかでバリデーションを作成し直しました。

また、プルダウンリスト・タイプについてはそもそも年・月・日のリストの中身が決まっているため、4月31日にしてエラーを出すことは出来るかもしれないけど、0月0日だったり13月100日と言ったリストに載っていない数値を使った日付の設定は出来ない形になるかと思います。
強いて言えば、未設定にした状態ならフォーカスアウトしたりボタンが活性だったら押下してのエラー確認は出来るかな。
年についても、プルダウンリスト外の数値の設定は出来ないので、例えば何千年も昔の年とか未来の年にすることは、そもそもプルダウンリストに入っていない限り不可能。
プルダウンリストについては、まずは中身が仕様通りになっているかの確認が必要となりますが…。

テキストボックスになっている場合ですが、Excelのように入力すると「yyyy/mm/dd」に変換されたり、日付の入力する前提の仕様なら難しいところはありそうです。
が、単に文字種と文字数の指定だけの場合はバリデーションで遊び放題？かと。

以上のことから、大抵の日付設定はある程度の仕様が決まっていることが多いと思われるので、好き勝手に入力出来るパターンの方が少ないかもしれません。
バリデーションで遊ぶ？にしても、意外と仕様を考慮すると遊べないんだなぁ、とふりかえってみて思いました。

あと、このようにUIによって設定出来る範囲が決まっている場合、「mm月dd日の設定は出来ないこと」の確認があってもいいかもしれないですね。

■閏年などなど

これも昔の別案件ですが、たまたま日付が絡むケースについて、丁度その案件にいた年が閏年の年だったので閏年についてのバリデーションを提案したことがあります。

その時以来日付については閏年を意識するようになりました。

先日投稿した積読リストにも載せている本、ソフトウェア技術者のためのバグ検出テキストにも閏年についてのパターンの記載がありました。

■閏年について
・４で割り切れる年は閏年
・１００で割り切れる年は平年
・４００で割り切れる年は閏年​

後半2つについては恥ずかしながらこの本で知ったか閏年についてググっていたかで、実はここ数年で知りました。

100／400で割り切れる年の部分に関しては、そもそも設定可能な仕様になっているかどうかで確認できるか決まってきそうです。

この本では対策として、

■閏年の対策
・仕様で閏年について考慮しているか
・コードに閏年の処理を記述しているか
・閏年の2月２９日周辺をテストしているか
・閏年の１２月３１日をテストしているか

を取り上げていました。

1〜3番については結構考慮されていると思いますが(とは言え、2番目のコードについては開発側のテストになることが多いと思うので、実際にQAが指摘するとしたら要件定義や仕様書レビューで突っ込むくらいでしょうか)、4番目についてはここで初めて知りました。

過去に発生した閏年のバグとして2008年の公衆電話機のものを取り上げていて、そこでは実際に発生したのは1月31日だったようですが、年の切り替えの12月31日に発生し易い可能性は確かにあります。

「場合によっては、日数を配列で確保していて、予期せぬ1日でバッファオーバーランとなる可能性がある」と記載されていました。

閏年＝2月29日周辺さえ確認しとけば大丈夫かな、と思っていたので、結構目から鱗でした。

■タイムゾーンを変えていいならやってみたい

そう言えば去年年末のテスターちゃんのブログに探索テストについての投稿がありましたが、この内容は日付のテストについての内容でもあると思いました。

年の切り替えや当日に記録し忘れて翌日に記録すると言ったことは実際にユーザとしてもあり得ますが、タイムゾーンの切り替えは一つの国にしかいないとなるとなかなか思い付かないかもしれません。

かつて自分はデンマークに1年未満滞在したことがありますが、テストの仕事に携わる前だったので、実際にその国のタイムゾーンに変更している状態で日本のアプリを海外で使っていてそのようなトラブルになったことはありませんでしたが、もしかしたらテスターちゃんで取り上げられているようなバグに遭遇していた可能性はあったのでは、と今では思います。

タイムゾーンの変更まで行くと、もしかしたら探索テストやアドホックテストの範囲になるかもしれないし、「日本のタイムゾーンで使用する前提だから」とバグを見つけても改修対応外になる可能性はあり得そうです。

■現在日付のテストについて考えていることは以上

経験がもっとあれば更に色々出て来るかもしれないけど、今のところはこんな感じになっています。

他にも思い付いたり学んだりしたら、続編を書くかもしれません。

この記事が気に入ったらサポートをしてみませんか？