第310回： 「ALTAのテキストをつくろう」63 （キーワード駆動テスト）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「6. テストツールおよび自動化」の「6.1 イントロダクション」と「6.2 キーワード駆動テスト（のイントロ）」について書きました。
ISTQBではツールに効率性と正確性を求めているといった話です。
最近読んだ「AIの内部は回路と電流だけ」という記事に、
「誰かである」とは、個々の人間の「誤り」によって定義され、人間とは「誤り」の集合体である
とあり、人間と機械の違いとして妙に腑に落ちました。
私もシラバスと同様に、「正確性」について人間はロボット（自動化）に敵わないと思っています。
特に人間は「同じことをくり返して実施する」ことが苦手で、機械は「同じことをくり返して実施する」ことが得意だと思います。
（たとえば、「100万人のユーザー登録」をテストする必要があったら、テストの自動化を検討すべきです。）
「効率性」のほうはどうでしょう。
効率は効果を固定して初めて比較できるようになるものですから、テストの自動化が手動のテストと別の効果を狙うように変わっている今となっては違う気がします。とはいえ、ALTA受験者は試験のときには「効率性と正確性」を選んでくださいね。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「6. テストツールおよび自動化」の「6.2 キーワード駆動テスト」の残りについて書きます。
前回のラストで「6.3 テストツールの種類」についても書くとお知らせしたのですが、長くなってしまったので6.3については次回とします。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢1の「効率性と正確性」が81.6%と最も多く、正解も1です。
正解についての私の意見は「はじめに」でコメントしたのでよいとして、「保守性と移植性」に投票された方が18.4%いらっしゃいます。確かにテストデータと自動テストスクリプトを分離することでテストの保守性は良くなるかもしれません。
また、移植性についても例えばブラウザやOSといった環境が変わっても同じテストを実行する（移植性の副特性の「適応性」）は関係しそうです。
「移植性」の3つの副特性の要点を再掲します。
適応性： 製品を固定して環境の変化に適応できる
置換性： 環境を固定して製品を置換できる
設置性： インストール／アンインストールが容易で期待通り
実際には、移植性の評価を目的としてテスト自動化ツールの導入はあまりしないように思います。（手動テストで確認するほうが良いことが多いからです）
復習は以上として、今回のnoteのテーマに移ります。
≡ キーワード駆動テスト
この記事を書く前に、（間違ったことを書かないように、）家にあるテスト自動化を本を5冊ほど見返してみたのですが、キーワード駆動テストに関してこのシラバスと重なることはほとんど書いてありませんでした。
しいて言えば、『システムテスト自動化 標準ガイド』に書いてあるのですが、ふわっとした概念的な書き方なのです。カズさんから「もしかすると、ISO/IEC/IEEE 29119-5:2016(en)の方がいいかもしれませんね。改訂中ですが…」と教えてもらいました。
すみません。ISO/IEC/IEEE 29119-5:2016(en)を持っていないので、今回はシラバスの解説となります。（つまり今回は裏取りしていません。でも、ALTAのテスト準備としてはそのほうがいいかもしれませんね）
また辰巳さんから「KEYWORD-DRIVEN TESTING」というウェブサイトを教えてもらいました。ありがとうございます。
実は、私も自動化に取り組んでいた時期があって、JaSST 2003の時にメンバーが「ダイナミックに操作を補完するテスト自動化について」というタイトルで発表しました。
これは、1990年代にXEROXに出張に行ったときに見てきた「キーワード駆動自動化」を発展させたものでした。
私たちの論文のアイデアは、「各キーワードに前状態と後状態を情報を付与しておき、何かのキーワードを指定されたときに、今現在の状況からそのキーワードの前状態までのキーワードを連鎖させて補完操作（補完シーケンス）を自動的につくる」です。下図（プレゼン資料）の「ユーザー操作」が「キーワード」に当たります。
キーワード駆動アプローチは、上記の補完シーケンスを作ることまでは求めていないと思います。だから、ISO 29119-5という国際標準はあるとしても世の中には色々なバリエーションがあるのだろうなと思います。辰巳さんが教えてくださったページの例もそうですし。
こういった工夫をしているときが楽しいんですよね。
閑話休題。
前回、テスト自動化のアプローチは、「キャプチャ/プレイバックアプローチ」、「データ駆動アプローチ」、「キーワード駆動アプローチ」の順で進化してきたと書きました。その要点は、
■ キャプチャ/プレイバックアプローチ
操作を記録し、再現する。（実際には、記録した操作の再現性が良くなるように操作の記録を編集する）
■ データ駆動アプローチ
操作を記録し、【（入出力する）データ】と【テスト自動実行スクリプト】を切り離し、データ部分をテーブルから読み込みながらスクリプトをループ実行することで、スクリプトの実行バリエーションを増やす。
■ キーワード駆動アプローチ
データ駆動アプローチを更に進め、アクションをキーワードとして呼び出してテストの操作の流れ自体を書けるようにしたもの。
つまり、「記録＆再現」しかできなかったものを「記録＆データを変更しながらバリエーションを増やして再現」に進化させ、さらに「記録した操作を分解してキーワードで呼び出せるように準備しておき、キーワードを並び替えて別の新たな操作を生み出すことを可能とした」ということです。
さて、シラバスの確認を始めます。
■ キーワード駆動テストの主な利点
シラバスでは下記の4点をキーワード駆動テストの主な利点に挙げています。
● 特定のアプリケーションまたはビジネスドメインに関連するキーワードは、ドメインの専門家が定義できる。これにより、テストケース仕様作成のタスクがより効率的になる。
● 主要なドメインの専門知識を持つ人が、基になる自動化スクリプトのコードを理解する必要なく、自動化テストケース実行の利点を受けられる（キーワードをスクリプトとして実装した場合）。
● モジュラー型記述技法を使用すると、テスト対象のソフトウェアの機能およびインターフェースに対する変更が発生した場合に、テスト自動化エンジニアはテストケースを効率的にメンテナンスできる[Bath14]。
● テストケース仕様は、その実装から独立している。
長いので要約します。
● ドメインの専門家がキーワード定義することにより、テストケース仕様作成が効率的になる。
● ドメインの専門家は、自動化スクリプトのコードを理解する必要がなく、テスト自動化の利点を受けられる。
● テスト自動化エンジニアは、機能などの変更が発生した場合にテストケースを効率的にメンテナンスできる。
● テストケース仕様は、その実装から独立している。
要するに、ユーザーがキーワードを決め、テスト自動化エンジニアがキーワードごとに自動化スクリプトのコードを作るという役割分担をするといいよということです。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
6.2 キーワード駆動自動化
TA-6.2.1 （K3）特定のシナリオで、キーワード駆動テストプロジェクトでのテストアナリストの適切な活動を判断する 。
（K2：理解、K3：適用、K4：分析）
《問題》
「キーワード駆動テストの主な利点」を受けるために必要となる前提を選びなさい。
1. ドメインの専門家がキーワード定義する
2. ドメインの専門家がテストケース仕様を作成する
3. ドメインの専門家も自動化スクリプトのコードを理解する
4. 作った後はテスト対象の機能変更を受け付けない
答えは次回に書きます。
≡ おわりに
今回は、「6. テストツールおよび自動化」の「6.2 キーワード駆動テスト」がテーマでした。
「キーワード駆動テストの主な利点」しか書いていませんが、シラバスにもその話しかありません。
データ駆動アプローチよりも、ずっとプログラミングの知識が必要な感じがしたと思います。その印象は正しいです。
「キーワード駆動テスト」をリーディングできるテスト自動化エンジニアは、それを望めば、いわゆる開発者（SEやプログラマー）として十分にやっていける技術を持っているはずです。
テストエンジニアからプログラマーへ異動したい人は、キーワード駆動テスト開発の実績をアピールすると良いかもしれません。
さて、次回は「6. テストツールおよび自動化」の「6.3 テストツールの種類」について書きます。
