はじめに
本記事は自動テスト・テスト自動化 Advent Calendar 2021の24日目の記事です。
今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述します。
後編である本記事では、自動テストに適用した場合の話を書きます。
前編はこちら。
発表スライド＆発表動画
目次
今回のお題
前編での成果物
前編では、テスト設計を行うことで、デシジョンテーブルを用いてお題の内容について整理しました。
前編で作成した成果物のうち、本記事でも使用する成果物を示します。
PICTを使ってテスト総数を減らしてみる
150通りもテストしたくはないが、いちいちデシジョンテーブルで整理するのも面倒とお思いの方がいるかもしれません。
手間をかけずにテスト総数を減らす方法として思い浮かぶものの一つとして、PICTの活用があります。
PICTを用いることで、デフォルトの設定では二因子間網羅を行うことができます。ちなみに、前編で一番最初に示した150通りのデシジョンテーブルは4因子間全ての網羅です。*1
PICTの使い方については、以下のサイトを参照してください。
実際に、PICTで出力した結果がこちらです。
25通りまで減らすことができました。
しかし、PICTにも欠点がいくつかあります。
欠点1:網羅しているのはあくまでも二因子間だけである
二因子間網羅なので、三因子が関わる不具合は見逃してしまうことがあります。
欠点2:有則な条件でPICTを使うと、見逃してしまうケースが出てくる可能性がある
PICTは無則な条件間で使うことを想定しています。
今回のように、大人の人数と子供の人数という合計人数に関わるような有則な関係でPICTを使うことは推奨しません*2。
欠点1と欠点2について詳しくは、昨年に書いた別記事を見てください。
欠点3:テストに失敗した際、何が原因なのか分かりづらくなる
先ほど出した25パターンのうち、予約が成功する期待値の例は4パターンです。（#1,#15,#16,#20）
しかし、ある不具合を1つだけ混入すると、下記のように4パターンのうち3パターンでテスト失敗が発生します。なお、残りの21ケースは全て成功したとします。
どんな条件の時の不具合なのか原因を探す際に、PICTで作成したテストパターンだと原因が見つけづらくなります。
このように、PICTの利用は色々な落とし穴があります。そもそも、PICTの考えの元になっているペアワイズ法はJSTQB AL TAの学習範囲であり、少し応用的な技法なので、まずはデシジョンテーブルから考えた方が良いと思います。
テスト設計の内容は自動テストの理解容易性にも影響する
「前編で考えたテスト設計をしなくても（PICTでテストパターンを作成して）自動テストでテストしちゃえば良いのでは？」とお思いの方がいるかもしれません。
確かに、PICTで作成したテストパターンでも、自動テストにすることで、繰り返しテスト実行する際のテスト実行時間が大幅に改善できるかもしれません。しかし、自動テストが失敗した時の原因特定に影響があります。
このPICTの組み合わせをそのまま自動テストで表現する
「最初は150ケースも書く必要があるかと思ったけど、PICTで25ケースまで削れたので、それを自動テストにしよう」と考えた人がいたとします。
これで組んだ自動テストで、先ほどの不具合が発生した場合、テスト結果は下記のように表現されます。
上記結果画面で、赤字の部分がテスト失敗となったケースです。ここからテスト失敗の原因を特定するのは相当大変でしょう。
大変である理由の1つとして、PICTで作成したテストケースだと構造化して表現できないという欠点があるからだと考えています。
デシジョンテーブルの例を活用して自動テストで表現する
一方、「デシジョンテーブルを作成したら色々整理できたから、その内容を元に自動テストにしよう」と考えた別の人がいたとします。
これで組んだ自動テストで、先ほどの不具合が発生した場合、テスト結果は下記のように表現されます。
こちらの場合、いくつかのことが推測できます。
- 「名前」「予約番号の印刷」の印刷は不具合の原因とは無関係に見える
- 大人の人数も子供の人数も4名の場合はテストが失敗している
今回のテストケース数はPICTの場合よりも少ないにもかかわらず、おそらく、不具合の原因の特定はPICTの場合よりも早いでしょう。*3
おわりに
本記事では、自動テストに適用した場合のテスト実行結果を示すことで、テスト設計結果が自動テストの理解容易性に影響する点について書きました。
なお、テスト自動化の8原則の1つに「8. テスト結果分析という新たなタスクが生まれる」というのがあります。今回の話はまさにこれに当たります。
ただ闇雲にテスト自動化をするのではなく、テスト設計をして整理してからテスト自動化をすることで、テスト結果分析のコストを減らしましょう。
