改元に関するテスト観点を考えてみました

QUES TECH

ヒューマンクレストの磯部です。
年度も明けたので、特に業務的な要請はないけれど改元のテスト観点を考えてみました。
『知識ゼロから学ぶソフトウェアテスト』にならって、入力・出力・計算・保存という切り口で書き出していきます。

入力処理

まずは当たり前のところから。
和暦で新年号を使った入力、特に境界値として年号切り替わりの 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保存であれば、前記で上げたような値に対して、保存されていることを確認するだけで問題ないのですが。

こんな現実もありますし。

和暦(年号) がなんらかの形で保存されているのであれば、それに対する確認が必要となります。
既存データの参照だけでなく、更新で問題が起きないかも確認します。
既存データを編集して何も変えずに再保存というのも注目ポイントですね。

おわりに

なるべく特定のサービスを想定せずに、一般的な観点として考えてみました。
なかには本当に改元対応のテストを業務で行う方もいらっしゃるかもしれませんが、参考になれば幸いです。
特に予定がないみなさまも、「こんなところをテストする」「ここでバグが出るはず」と考えてみてはいかがでしょうか。


ユニットテストを推進して半年経過したまとめ

QUES TECH

こんにちは、ヒューマンクレスト 磯部です。

今回は、私が社内向けに開発・運用している Webアプリの、ユニットテストについて書いてみます。


ランダム文字列の衝突確率

QUES TECH

こんにちは、ヒューマンクレストの磯部です。
今回はランダム文字列の衝突確率について考察します。
自動テストを運用する際に、意外に何度も実務で使ったことがあるので書いてみました。


上手な不具合報告で、開発者と良い関係を!

QUES TECH

handshake01
こんにちは、ヒューマンクレスト 磯部です。
今回はテストの基本中の基本、不具合報告について書きたいと思います。

ここで不具合報告というのは、テストを実行した結果NGが出た際に開発者などへ出す報告のことです。現場によってインシデント、バグ票、チケット、などなど、様々に呼ばれています。
不具合報告の精度次第で、この後の原因解析や修正までがスムーズになることもあり、書き方ひとつで開発者の信頼を失うこともあります。おろそかには出来ない一方で、不具合発見から報告までは出来る限り短い方が望ましいので、スピードも求められます。

そんな不具合報告を上げる時に気をつけている点をまとめてみました。テストエンジニアのみなさまには、「当たり前」という点も多々あると思いますが、参考にして頂ければと思います。


Selenium GridのWindowsサービス化

QUES TECH

こんにちは、ヒューマンクレスト 磯部です。
今回はテスト自動化のなかから Selenium Grid の TIPS をご紹介します。

Windows で Selenium Grid を使う場合、Windows のコマンドプロンプトから Hub や Node を実行出来ます。
しかし、テスト環境でコマンドプロンプトを開いたままにしておくと、操作ミスで閉じてしまったり、テスト環境を再起動した際に起動し忘れたりといった問題が起きます。
そこで、Grid Windowsのサービスとして登録する方法をご紹介します。


JCSQE を受けてきました

QUES TECH

はじめまして! ヒューマンクレストの磯部です。
普段は、HCで自動化をメインにお仕事しています。

先週の土曜日、6月21日に、ソフトウェア品質技術者資格認定(JCSQE)の初級試験が実施されました。
http://juse-sqip.jp/jcsqe/

わたしも初めて受験してきましたので、ご報告したいと思います。
受かってるといいなぁ。。。