昨晩から会社に泊まって、未明から朝まで眠り、朝起きてから、データを必死になって作っていました。
何らかのテストを行うにあたって重要なことは、そのテストが正しいテストであることを確認しなければならないことだと思います。確認項目をパッと考えてみても、これくらいの項目が頭に浮かびました。
- テスト対象の行う動きの正しさ(仕様)
- テスト前提の正しさ
- テストケースの正しさ(テスト対象の動作の正しさを保証できるに(必要)十分なテストケースであること)
- テストデータの正しさ
- テストを行おうとする対象の正しさ(デグレードや、テスト対象に影響を与えるような未テストの機能が混入していないこと)
- 想定結果の正しさ
1, 2, 3 についてはあくまでテスト前提であり、これを満たしていない、あるいは理解していないテストに意味はありません。
4, 5, 6 は、テストを y = f(x) という機能の正しさを担保するものだと捉えた場合、x, f, y それぞれが個々に正しいことを保証する項目です。例えば 5. が満たされていない場合は、y = f(x) ではなく、z = g(x) を実施していることになり、想定結果である y と実際の出力 z の差異に頭を悩ませることになります。悩ませるだけならまだしも、それがサービス影響を伴うような(アプリ的な)障害に繋ってしまいます。
ぼくがこの数日、工数を割かれているのは 4. のテストの入力となるデータの作成でした。
単体テストを終えたエンタープライズなアプリケーションの結合テストを行う場合、入力データの正しさをどう担保するかというと、一般には(既にテスト済の)正規機能でデータを作成します。だって、他に「正しいデータ」を作る方法ってないものね。
しかし、正常系テストにおける入力データのバリエーションというものは、通常の正規機能で作成されるであろう範囲に収まらず、正規機能で作成「できる」範囲にまで及びます*1。通常はシステムで作成されないとしても、作成され得るデータに対しては、システムは少なくとも想定内の動きをしなければなりません。では、そういう「通常作成はされないけれど、作成され得るデータ」を正規機能で作成するのって、スゴく工数が嵩むことが多いんですよね。。。。。。。
今日も終電で人が死ぬ。
*1:異常系を含めるともっと広いですね