黒柴的ソフトウェアテスト考 #12
テストから考えるソフトウェアの設計#1
これは、あるプロジェクトでのバグから考える考察である
仕様：
ある工場では、3直で24時間勤務を行っており、アプリの画面には現在の直で実施予定の作業情報を表示する
そのため、テスト対象の処理ルーチンでは、現在時刻を元に現在の直の開始時刻を算出する仕様としている
各直の勤務時間は以下のとおりとする
テストケース：
担当者（実装、およびユニットテストを担当）が考えたテストケースは、以下のようなものだった
このテストケースは、直の仕様を以下のようなパーティション分割であると整理して作成したものと予想される
不具合の詳細：
上記のテストケースでは、日付が考慮されていない
そのため、項番４の7:29では前日の23:00を直の開始時刻とするべきところを、時刻のみを計算して直の開始日時としているため、当日の23:00を開始時刻として出力していた
この点では、対象の処理ルーチンが「直の開始日時」ではなく、「直の開始時刻」を算出していることに問題がある
提示された仕様では、直の情報に日付が定義されていないが、時刻のみならず日付も考慮したうえで、以下のように整理されるべきであると考える
改善したテストケース：
JSTQBのシラバスにおける同値分割については、以下のような記述がある
3.2.1 同値分割法
制限／注意事項
「たとえば、正の数と負の数を受け入れる入力欄に 対しては、正負で処理方法が異なる可能性があるので、正の数と負の数の 2 つの有効同値クラスとしてテスト する必要がある。同様に、ゼロを許容するかどうかについても、別の同値クラスとなる。」
すなわち、三勤のパーティション内に0時があることに注目する必要がある
そこから日付を考慮する必要があることが分かると、前日の23:00～23:59と当日の0:00～7:29は別のパーティションであることは、容易に判断できるはずだ
同値分割、境界値分析を踏まえて、改善したテストケースは、以下のようになった
テストを踏まえた実装設計：
この12個のテストケースについて、結果を確認するためには、どのようにテストを実施すべきなのか？
黒柴は、実装されたコードを見て、テストケースの抽出にも問題があるが、テスト自体もきちんと実施していないのだろうなと思った
理由は、実装された処理内で、直接システムの時刻を取得していたからである
このように処理内で直接システム日付を取得すると、テストを実施するために都度システム時刻（OSの時刻）を変更するか、もしくはデバッガでプログラムを止めて、取得したシステム時刻を書き換える必要がある
そして、このような面倒なテスト手順を、テストケースごとに実施しているとは思えない
その結果、実施した現在時刻の値のみでしかテストをしておらず、勤務時間（9:00～18:00）以外のテストケースは、テストしていないのでは？と予想できる
では、テストをより簡単に実施するために、どのように実装するべきなのだろうか？
以下は、黒柴が別のプロジェクトのアーキテクチャチームにいたときに、チーフのシステムアーキテクトから教えてもらったものである
システム時刻を取得する共通処理を1つ作成しておき、プログラム内のすべての処理は、その共通処理からシステム時刻を取得するのである
こうしておけば、共通処理：Sys_Commonの中で設定ファイルから時刻データを読み込みことで、テストの入力値となる時刻データを容易に設定できる
すべてのテストケースも簡単に実施できるし、テストの自動化だって容易だ
賢い諸兄らは、「こんな設計は、常識じゃね？」と思うだろうが、社内でこの話をしたとき、他のエンジニアはまさに「目から鱗が落ちる」という感じだった
知らないってことは残念なことだし、いろいろなことで知識の幅を広げるということは重要だと思うので、あえてこの件を記事にした
どのようなテストケースがあり、それを正確に、より簡単に実施するためには、どのようなコードが必要か？
そういう観点から実装設計を進めることも、必要だと思う
感謝：（2024/2/6更新）
この記事は、Software Designの2024年2月号の特集を読んで、テスト分析、テスト設計の重要性、およびそこから実装設計へのフィードバックを行う例として、過去の体験を踏まえて記述した
どちらかというと実装設計へのフィードバックに主眼を置いているため、テスト分析、設計についてはかなり端折っているのだが、Software Designで該当記事を執筆したエンジニアに目に留まったことで、テスト分析、設計について、ブログで補完して頂けた
テスト分析、設計については、黒柴自身も至らない部分が多かったので、助かりました
もともとこの実装を行った担当者と共有したいと思います
ありがとうございます