はじめに
先日、WACATE 2024 夏というワークショップを開催しました。私はWACATE実行委員長として運営に携わり、準備を行ってきました。
WACATE 2024 夏の開催内容およびWACATEという団体について詳しくは、以下のページをご覧ください。
WACATE 2024 夏では「テストケースには、必ず作った人の意図が存在する」というサブタイトルを付け、テスト実装からテスト分析へとテストプロセスをさかのぼる（＝リバースする）過程を体験してもらいました。
ワークショップを作成するにあたり、テストプロセスについて今までより深く考えられた（気がする）ので、本記事で言語化して書き残しておきたいと思います。
前提知識：テストプロセスとは何か
ISTQB（ソフトウェアテスト技術者資格認定）では以下のようにテストプロセスを定義しています。
今まで「テスト実行」と「テスト実行のための準備」ぐらいにしか分けていなかったテストのプロセスを、JSTQBではいくつものプロセスに分けて表現しています。
その中でも、「テスト分析」「テスト設計」「テスト実装」「テスト実行」は、単一のテスト対象に対してでも活用できる部分だと思っています。*1
この4つのテストプロセスのうち、テスト実行を除いた3つに着目すると、以下のようなインプット/アウトプットで作成できるでしょう。
本記事では、上の画像で表したテストプロセスとインプット/アウトプットを用いて説明します*2。
テストプロセスをリバースするとはどういうことか
今回のWACATE 2024 夏では、前提知識で書いたテストプロセスのうち、「テスト手順書（テスト実装の成果物）」しか手元にない場合に、テスト設計やテスト分析にさかのぼる（＝リバースする）ことを参加者に体験してもらおうと考えました。
この時、どのようにリバースすれば良いのでしょうか？単純に逆の順番で行えばできるのでしょうか？
上の図の赤矢印のように辿ると、「テスト手順書からテスト実装を行うことで、テスト設計成果物を作成できる」と読み取れます。果たして本当にそんなことが可能なのでしょうか？私は違うと思っています。
少なくとも、「テスト手順書をインプットとしてテスト設計を再度行い、テスト設計成果物を作成する」ということになると思います。
「テスト設計」を細分化する
「テスト設計を行う」という部分をもっときちんと考えるため、テスト設計というプロセスをさらに細分化することを試みます。すると以下のように考えることができました。
上図のうち青囲み部分が、元々「テスト設計」と呼んでいた部分です。今回は「テスト設計技法選択」「テストモデリング」「カバレッジアイテムの導出」という3つに細分化できました。
テストモデリングとは何か？
テストモデリングとは、テスト設計技法などを用いて、テストの視点で図式化、視覚化する行為のことです。詳しくは、今回の WACATE 2024 夏での発表資料をご覧ください。
カバレッジアイテムとは何か？
JSTQBの用語集によると、以下のように書かれています。
テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する
例えば、同値分割法におけるカバレッジアイテムは代表値になります。境界値分析におけるカバレッジアイテムは境界値になります。デシジョンテーブルにおけるカバレッジアイテムは、出てきたパターンになるでしょう*3。
上図の赤丸の部分がカバレッジアイテムになります。
そして、出てきたカバレッジアイテムを元にテスト手順書を作成していると考えることができます。例えば、同値分割というテストモデリングによって同値パーティションを作成し、それを元に境界値分析を行うことで境界値を見つけ出し、その境界値を用いてのテスト実装を行うことでテスト手順書のケース1つが作成できると考えられます。
改めて、テストプロセスのリバースを考える
テスト設計というプロセスを細分化したうえで、改めてテストプロセスのリバースを考えます。すると、テスト手順書からカバレッジアイテムを導き出すのではなく、それ以前の「テスト設計技法の選択」や「テストモデリング」から行っていると思われます。
つまり直前のプロセスに戻れば良いのではなく、結局はテスト設計のプロセスの初めから行っているのです。
しかし、元々のテストプロセスには（当然ながら）「テスト手順書」と「テスト設計技法選択」を結ぶ線は存在しません。つまり、ここはリバースモデリングの実施者が自ら想定しなくてはいけない部分なのです。ここは完全に想像の世界になってしまうので、ましてや前任者といった自分ではない他人が作った場合、元々の想定と違うテストモデルができる可能性が大いにある部分です。これこそがリバースモデリングする上で大変な部分でしょう。
おわりに：そもそもテストプロセスをリバースするのはアンチパターン
本記事では、テスト実装の成果物であるテスト手順書からテスト設計の成果物をリバースして作る際のプロセスについて書きました。
しかし、そもそもリバースしてテスト設計の成果物を作ること自体がアンチパターンだと思います*4。
テスト実装の成果物以外は何もないところからテスト設計を想定しろということ自体が無理難題です。WACATE 2024 夏では、リバースすること自体の難しさを参加者に体験してもらいました。その経験を反面教師にして、きちんとテストプロセスに沿った成果物を作成することが大事だと理解してもらえたのではないかと思います。
なお、テストプロセスに沿った成果物について、個人的には「テスト分析」の成果物を残しておくことをオススメしています。一般的に、成果物の作成されやすさは、
テスト実装成果物（テスト手順書など）＞テスト設計成果物＞テスト分析成果物（テスト条件）
の順ですが、個人的には
テスト分析成果物（テスト条件）＞テスト設計成果物＞テスト実装成果物（テスト手順書など）
の順で残しておくべきだと思っています。なぜならば、後追いでテスト作成の経緯を追うときに、同じ思考順にできる（リバースして考えることがなくなる）ため、再現性のあるテストに向かいやすいと思っているからです*5。
本記事を通じて、テストプロセスをきちんと理解することが少しでも大切だと感じてもらえれば幸いです。
参考：テストプロセスを用いて、テストケース作成の思考を整理しよう(WACATE 2022 冬の発表資料)
*1:逆に、「テスト計画」「テストのモニタリングとコントロール」「テスト完了」は、複数のテストを行う際に効果をより発揮できるプロセスだと感じています
*2:なお、この中で「テスト条件」が馴染みのない言葉かもしれません。本記事上では「何をテストしたいのかを書き記したもの」ぐらいに捉えておいてください。詳しく知りたい方は、JSTQB FLのシラバスをご覧ください。
*3:「カバレッジ」という単語から「テストコードを実行した際に測定できるコードカバレッジ」をイメージされる方もいると思います。コードカバレッジはコード1行1行がカバレッジアイテムとみなすことができるでしょう。
*4:アンチパターンである旨は、WACATE 2024 夏の中でもお伝えしました
*5:特に、テスト設計を学んでいればいるほど、再現率は高くなると思います
