カテゴリー4終わらせるよー。
自動化レベル3は、最も成熟した自動化のフレームワークで、「キーワード駆動（Keyword-Driven）」と、「モデルベースド（Model-based）」の2つの要素からなります。
4.2.4.1 キーワード駆動
「キーワード駆動」は、JSTQB Advancedのシラバス9.3.7に、以下のように書かれています。
キーワード（「アクションワード」と呼ばれることもある）は、システムのハイレベルのビジネス相互作用（たとえば「注文のキャンセル」）を表現するためによく使用される（ただしそれに限定されるわけではない）。それぞれのキーワードは通常、テスト対象のシステムで、多くの詳細な相互作用を表現するために使用される。
エイイッ 直訳直訳ゥ！！まったく意味がわかりませんね。
TABOKを読んでもよくわからないのですが、NTTデータの町田欣史さんの記事が参考になりました。
TABOKを読んでもよくわからないのですが、NTTデータの町田欣史さんの記事が参考になりました。
www.nttdata.co.jp ここでは、「画面操作や入力・確認する文字列などを表形式で記述」と説明されています。その表を上から読んでいくと、操作シナリオになります。このことことからキーワード駆動は、「table-driven」とも呼ばれています。
このテーブルに現れる言葉は、ツールに依存しない、一般的な自然言語です。スクリプトがそれを、ツール用の言葉に読み替え、実行することになります。
キーワード駆動の長所
レベル2の機能分解では、作成したスクリプト部品を使いまわすことで、あるソフトウェアのテストにおけるスクリプトの冗長化を軽減していました。
キーワード駆動ではさらに踏み込んで、複数のソフトウェアにまたがって流用しようとします。テーブルが自然言語で書かれており、ソフトウェアや自動化ツールに依存しないので、それが可能という理屈です。
個人的には・・・そこまで作りこむのって本当に可能なの？と感じます。実現している組織の話を、ぜひ聞いてみたいですね。
もう1つ、テストパターンの作成にスキルがほとんど必要なくなることがあります。テーブルは自然言語で書かれているのですから、それを読んで組み合わせていくのは難しくありません。
キーワード駆動ではさらに踏み込んで、複数のソフトウェアにまたがって流用しようとします。テーブルが自然言語で書かれており、ソフトウェアや自動化ツールに依存しないので、それが可能という理屈です。
個人的には・・・そこまで作りこむのって本当に可能なの？と感じます。実現している組織の話を、ぜひ聞いてみたいですね。
もう1つ、テストパターンの作成にスキルがほとんど必要なくなることがあります。テーブルは自然言語で書かれているのですから、それを読んで組み合わせていくのは難しくありません。
キーワード駆動の短所
4.1で、自動化のコストには、「作成」と「維持」があると説明されていました。
これとは別の切り口として、「フレームワークを作ること」と、「フレームワークの上でスクリプトを書くこと」を分けて考える方がよさそうです。
自動化レベルが上がれば上がるほど、フレームワークの整備には時間とスキルが必要になり、一方でそれが整えば、スクリプト作りの人は幸せな余生を送れます。
これとは別の切り口として、「フレームワークを作ること」と、「フレームワークの上でスクリプトを書くこと」を分けて考える方がよさそうです。
自動化レベルが上がれば上がるほど、フレームワークの整備には時間とスキルが必要になり、一方でそれが整えば、スクリプト作りの人は幸せな余生を送れます。
レベル3のように、組織をまたがって使用されるようなフレームワークを作り始めると、広範囲の人々に、フレームワークのメンテナンスのルールにしたがってもらう必要が出てきます。気軽な自動化ではなくなってきます。
4.2.4.2 モデルベースド
モデルベースドは、これまでの自動化レベルと少々色が違うように思います。
たとえば、JaSST’07における電通大の西先生の、モデルベースとテストに関する発表スライド（PDF）では、「実は既にモデルを用いてテスト設計しているのです」とあり、その例として「状態遷移テスト: 状態遷移モデルを用いたテスト設計」と書かれています。
たとえば、JaSST’07における電通大の西先生の、モデルベースとテストに関する発表スライド（PDF）では、「実は既にモデルを用いてテスト設計しているのです」とあり、その例として「状態遷移テスト: 状態遷移モデルを用いたテスト設計」と書かれています。
たとえば状態遷移表があれば、1-passカバレッジ、2-passカバレッジを100%達成するための遷移パターンを自動的に生成するのは難しくありません。とすると自動化まではあと少しですよね。
西先生のスライドには、（2007年時点での）「まだ先の話」として、以下のような期待を述べられています。
- テスト設計モデルからテスト項目を自動生成できるようになる
- 自動生成されたテスト項目のカバレッジが保証できる
- テスト項目から自動テストスクリプトに自動変換できるようになる
・・
モデルベースドの長所
上述のように、カバレッジが定義しやすい。テストをやればやるほどカバレッジが上がり、品質への確信も上がっていきます。
また、これまでの自動化では、すでに手動なりで行ったテストを繰り返し行うという性質から、新しい欠陥を大量に見つける、というものではありませんでした。一方モデルベースドは探索的な性質をもつことから、欠陥を摘出する確率が高まるとあります。
すみません、わたし自身は、なぜモデルベースドテストが「exploratory(探索的)」と言われるのか、理解できていません。
また、これまでの自動化では、すでに手動なりで行ったテストを繰り返し行うという性質から、新しい欠陥を大量に見つける、というものではありませんでした。一方モデルベースドは探索的な性質をもつことから、欠陥を摘出する確率が高まるとあります。
すみません、わたし自身は、なぜモデルベースドテストが「exploratory(探索的)」と言われるのか、理解できていません。
モデルベースドの短所
もうこの辺は繰り返しですが、技術的に精通している人がいないと、実現できない。
もう1つは、マネジメントに理解がいるってこと。モデルベースドは、カバレッジを高める。よってこれまでの「テストの再実行」というより、「テストの追加」という形になります。他のフレームワークはコスト低減が見えやすい一方で、モデルベースドはどちらかというと、リスク低減の方が目的なんですね。
もう1つは、マネジメントに理解がいるってこと。モデルベースドは、カバレッジを高める。よってこれまでの「テストの再実行」というより、「テストの追加」という形になります。他のフレームワークはコスト低減が見えやすい一方で、モデルベースドはどちらかというと、リスク低減の方が目的なんですね。
よーし4章まで予習終わったー！ 7月は研究会に・・・。
