テスト自動化の技法は現在どう変わったか
15年以上前のこの分類、現在ではどのように変わっているのでしょうか。自動化に関する近年の資料として、TABOK（テスト自動化知識体系）[1]と、ISTQB[2]のシラバスを参照してみましょう。
TABOKでは、自動化のアプローチを「フレームワークのレベル」として分類しています。一方ISTQBでは、手動テストを自動化するアプローチを4つの「オプション」に分けています。
次の表1は、TABOK、ISTQB、ギア本で定義している自動化のアプローチが、それぞれどのように対応するかをおおまかにマッピングしたものです。レベルが高いほどアプローチとして絶対的に優れているということにはなりませんが、構造化や抽象化が進み、一般的に保守性・再利用性・可読性などが向上しています。
| TABOK | ギア本 | ISTQB | ||
|---|---|---|---|---|
| レベル1 | リニアスクリプト | リニアスクリプト |
キャプチャー・ プレイバック アプローチ |
オプション 1 |
|
構造化 スクリプティング |
リニア スクリプティング |
|||
| レベル2 |
機能分解 フレームワーク |
共有スクリプト |
構造化 スクリプティング |
オプション 2、3 |
|
データ駆動 フレームワーク |
データ駆動 スクリプト |
データ駆動 テスティング |
オプション 2、3 | |
| レベル3 |
キーワード駆動 フレームワーク |
キーワード駆動 スクリプト |
キーワード駆動 テスティング |
オプション 2、3 |
| ‐ | ‐ | ‐ |
プロセス駆動 スクリプティング |
オプション 4 |
| レベル3 |
モデルベースド フレームワーク |
‐ |
モデルベースド テスティング |
オプション 4 |
「構造化スクリプティング」は、ギア本では構造化プログラミングに対応するものであるのに対し、ISTQBではスクリプトを分解して再利用を促すものであることから、同じ名称ながら違う場所にマッピングされています。
それ以外の差としては、「プロセス駆動スクリプティング」と「モデルベースドテスティング」があります。この2つは、ISTQBでは「オプション4」の性質をもったものとされています。ISTQBでいう4つのオプションは、次の表2のようなものです。
| オプション | テストケース実装 | 抽象化 |
スクリプト 自動生成 |
テスト手順 自動生成 |
|---|---|---|---|---|
| 1 | テスト自動化エンジニアが行う | なし | なし | なし |
| 2 | テスト自動化エンジニアが行う | あり | なし | なし |
| 3 | ツールが行う | あり | あり | なし |
| 4 | ツールが行う | あり | あり | あり |
オプション3と4の違いは、テスト手順の自動生成の有無です。
では、プロセス駆動スクリプティングとモデルベースドテスティングについて、少し詳しく見てみましょう。
[1] TABOK（The Test Automation Body of Knowledge）は、テスト自動化を推進する団体「Automated Testing Institute」が発行する、テスト自動化に関する知識体系ガイド。このサイトから購入することができます。
[2] ISTQB（International Software Testing Qualifications Board）は、ソフトウェアテストに関する資格認定を行っている国際団体。日本ではJSTQBが加盟組織。認定に必要な知識を整理したシラバスを無償で公開しており、本記事で参照しているのは、Expert Levelのうち「Test Automation」カテゴリのシラバスです。
プロセス駆動スクリプティング
オプション2・3に対応するキーワード駆動テスティングと、オプション4に対応するプロセス駆動スクリプティングの違いは、大きく2つあります。
まず、キーワードの粒度が異なる点です。たとえばギア本では、「リストに項目を追加する」「ファイルを保存する」といったキーワードが定義されています。確かにこういったキーワードも、「項目を追加する」際のソフトウェアに対する具体的な操作を隠蔽しているという点では抽象化ということができますし、操作自体の確認をするテストではむしろ、それらの操作に対応する粒度のキーワードが必要でしょう。
一方、業務シナリオを検証するようなテストケースでは、必然的に操作の数が増えます。そのテストケースを実装するキーワードが先のような粒度だと、全体として何がしたいテストケースなのかの見通しがつきづらくなりますし、保守性も悪くなります。
ISTQBでいうプロセス駆動スクリプティングは、キーワードを、「操作」の粒度ではなく「業務」の粒度にすることを意図しているようです。「機能駆動」（Function driven）と呼ぶこともありますが、同じ意図でしょう。
シラバスでは、「発注する」「注文の状況を確認する」といった例が示されています。こういった粒度のキーワードであれば、テストケースで行おうとしている業務がイメージしやすくなります。さらに、「発注する」より前に「注文の状況を確認する」ことはできないはずといった、キーワード同士の論理的な関係も定義しやすいというメリットがあります。
もう1つの違いは、オプション4の本質でもあるテストケースの自動生成ができる点です。キーワードの粒度が「業務」レベルになるということは、ユースケースをキーワードで表現できるということになります。この特徴を利用して、ユースケースシナリオから直接テストケースを生成し、さらにそれを自動実行するという夢が広がります。
モデルベースドテスティング
キャプチャー・プレイバックからキーワード駆動までが、テストケースの実行を自動化するのに対し、モデルベースドテスティングではソフトウェアのふるまいの一側面を抽象化したモデルから、テストケースの生成（およびその実行まで）を自動化します。
ギア本の第15章ではその一例として、状態遷移モデルからテストケースを導出する方法を解説しています。この例では、モデルから単純にテストケースを生成するのではなく、「直近で変更があった」（すなわち欠陥を作りこんでいる可能性が相対的に高い）箇所に重みを付けるといった方法も紹介されています。
