キーワード駆動テストとは？データ駆動との違い・仕組み・導入例を解説
キーワード駆動テストとは、「ログイン」「商品を検索する」「注文を確定する」といった操作を再利用可能な「キーワード」として定義し、その組み合わせによってテストケースを作成する手法です。
テストケースにプログラムの細かな処理を直接記述するのではなく、業務上の意味を持つ言葉でテストシナリオを表現できるため、テストの「設計」と「実装」を分離しやすい点が大きな特徴です。
そのため、テスト自動化エンジニアだけでなく、QA担当者や業務知識を持つメンバーもテスト設計やレビューに参加しやすくなります。
一方で、キーワードの粒度や命名ルールを適切に設計しなければ、キーワードが増えすぎて管理が複雑になることもあります。
本記事では、キーワード駆動テストの基本的な仕組みから、データ駆動テスト・BDD・キャプチャー＆リプレイとの違い、具体的なテストケース、メリット・デメリット、代表的なフレームワーク、導入手順まで解説します。
キーワード駆動テストとは？
キーワード駆動テスト（Keyword-Driven Testing）とは、テストで行う操作や検証を「キーワード」として抽象化し、キーワードとテストデータを組み合わせてテストケースを表現するアプローチです。
ISTQBの用語集では、高レベルのキーワードを含むテストスクリプトと、それらのキーワードを実装する低レベルのスクリプトを組み合わせるスクリプティング技法として定義されています。JSTQBが公開しているシラバスでも、キーワードとデータの定義をテストアナリストが担当し、そのキーワードを自動化コードへ変換する役割をテスト自動化担当者が担う形が解説されています。
また、ISO/IEC/IEEE 29119-5:2024では、キーワード駆動テストの考え方だけでなく、フレームワークやツールに求められる要件、キーワードの階層化などについても規定されています。
「ログイン」を例に考えてみる
例えば、Webサービスへのログインテストを考えてみましょう。
通常の自動テストでは、
- ユーザー名入力欄を取得する
- ユーザー名を入力する
- パスワード入力欄を取得する
- パスワードを入力する
- ログインボタンを取得する
- ボタンをクリックする
- ログイン後の画面を確認する
といった具体的な処理をコードで記述します。
キーワード駆動テストでは、これらを例えば以下のように表現できます。
| キーワード | データ | 目的 |
| ブラウザを開く | ログイン画面URL | 対象画面を表示する |
| ログインする | user01 / password | 認証を実行する |
| ダッシュボードを確認する | － | ログイン成功を検証する |
| ブラウザを閉じる | － | テストを終了する |
「ログインする」というキーワードの内部では、ユーザー名入力、パスワード入力、ログインボタンのクリックといった複数の処理が実行されます。
しかし、テストケースを作成する側は内部の細かな実装を意識する必要がありません。
これが、キーワード駆動テストにおける「設計と実装の分離」です。
キーワード駆動テストと類似手法の違い
キーワード駆動テストは、データ駆動テストやBDD、キャプチャー＆リプレイなどと混同されることがあります。
それぞれの違いを整理すると以下のようになります。
| 手法 | 主に抽象化するもの | 特徴 | 向いているケース |
| キーワード駆動 | 操作・テストロジック | 操作をキーワードとして再利用する | 複数の業務シナリオを自動化したい |
| データ駆動 | 入力・期待値 | 同じ処理を異なるデータで繰り返す | 入力パターンが多い |
| BDD | システムの振る舞い・要求 | Given／When／Thenなどで仕様を共有する | 要求や受け入れ条件をチームで共有したい |
| キャプチャー＆リプレイ | 実際の画面操作 | 操作を記録して再生する | 小規模な自動化を素早く始めたい |
データ駆動テストとの違い
データ駆動テストは、テストの処理自体は同じまま、入力値や期待結果だけを外部データとして切り替える手法です。
例えばログインテストなら、
- 正しいID・正しいパスワード
- 正しいID・誤ったパスワード
- 存在しないID
- 未入力
といった複数のデータパターンを、同じテストロジックで実行します。
一方、キーワード駆動テストでは「ログインする」「商品を検索する」「カートに追加する」など、テストで実行する処理そのものをキーワードとして組み合わせます。
つまり、
データ駆動テスト：同じ操作を異なるデータで実行する
キーワード駆動テスト：異なる操作をキーワードの組み合わせで表現する
という違いがあります。
両者は排他的なものではありません。
例えば「ログインする」というキーワードに複数のID・パスワードを渡すなど、キーワード駆動とデータ駆動を組み合わせることも可能です。
BDDとの違い
BDD（Behavior-Driven Development：ビヘイビア駆動開発）は、システムがどのように振る舞うべきかを、開発者・QA・ビジネス担当者などの関係者で共有するためのアプローチです。
Given（前提条件）、When（操作）、Then（期待結果）などを使ってシナリオを表現する方法がよく知られています。
一方、キーワード駆動テストの中心にあるのは、テスト操作を再利用可能なキーワードとして構造化することです。
目的は異なりますが、両者を組み合わせることもできます。
実際にRobot Frameworkでも、キーワード駆動、データ駆動、BDDスタイルを使ったテストケースを作成できます。
キャプチャー＆リプレイとの違い
キャプチャー＆リプレイは、テスト担当者が実際に行った画面操作をツールで記録し、後から自動で再生する方法です。
簡単に自動テストを作成できる反面、記録されたテストが画面要素に直接依存すると、UI変更の影響を受けやすくなります。
キーワード駆動テストでは、画面操作の詳細とテストシナリオの間にキーワードという抽象化層を設けます。
そのため、例えばログインボタンのHTML構造が変更されても、「ログインする」というキーワードの実装部分だけを修正する設計にしておけば、そのキーワードを使用している複数のテストケースを個別に書き換える必要がありません。
キーワード駆動テストの仕組み
キーワード駆動テストは、大きく以下の要素から構成されます。
- テストケース
- キーワード
- テストデータ
- キーワードの実装コード
- テスト自動化フレームワーク
それぞれの役割を見ていきましょう。
テストの「設計」と「実装」を分離する
キーワード駆動テストの最大の特徴は、テストの設計と実装を分離できることです。
テストケース側には、
「ログインする」
「商品を検索する」
「カートに追加する」
「注文が完了したことを確認する」
といった業務上理解しやすいキーワードを記述します。
一方、その内部でWebブラウザをどのように操作するか、どの画面要素を取得するかといった技術的な処理は別のコードとして実装します。
これにより、
QA・業務担当者：何をどの順序でテストするか
自動化エンジニア：各キーワードをどう動作させるか
という役割分担がしやすくなります。
キーワードの役割
キーワードは、単なる操作名ではありません。
キーワード駆動テストを分かりやすく保つためには、テストの目的や業務上の意味が伝わる名前を付けることが重要です。
例えば、
「テキストフィールドAに値を入力する」
よりも、
「配送先住所を入力する」
のように、業務上の意味を表すキーワードを使用した方が、テストシナリオを理解しやすくなります。
一方で、「ボタンをクリックする」「値を入力する」といった低レベルのキーワードも必要です。
そのため実際には、
業務レベル：商品を購入する
↓
操作レベル：カートに追加する → 配送先を入力する → 注文を確定する
↓
技術レベル：入力する → クリックする → 表示を確認する
というようにキーワードを階層化すると管理しやすくなります。
ISO/IEC/IEEE 29119-5:2024でも、こうした階層化されたキーワードが扱われています。
実装コードとの対応付け
定義したキーワードには、実際にシステムを操作するコードを対応付けます。
例えば「ログインする」というキーワードなら、内部的には、
- ユーザー名を入力する
- パスワードを入力する
- ログインボタンをクリックする
- ログイン後の画面を確認する
といった処理を実行します。
テスト自動化フレームワークは、テストケースに書かれたキーワードを読み取り、対応する処理を呼び出してテストを実行します。
テストスクリプトの構造
使用するフレームワークによって形式は異なりますが、キーワード駆動テストでは、テストケースを表形式や読みやすいテキスト形式で記述できます。
例えば以下のような構造です。
| No. | キーワード | 引数1 | 引数2 |
| 1 | ログイン画面を開く | － | － |
| 2 | ログインする | test_user | password |
| 3 | 商品を検索する | テスト自動化 | － |
| 4 | 商品をカートに追加する | 商品A | － |
| 5 | カートの商品を確認する | 商品A | － |
この形式であれば、プログラミングコードを読まなくても「何をテストしているのか」を把握できます。
Robot Frameworkを使ったキーワード駆動テスト
キーワード駆動型のテスト自動化を実現する代表的なフレームワークの一つが、オープンソースの「Robot Framework」です。
Robot FrameworkはPythonベースの拡張可能な自動化フレームワークで、公式ドキュメントではキーワード駆動のほか、データ駆動やBDD形式のテストにも対応しています。また、既存のキーワードを組み合わせて、より上位レベルの再利用可能なユーザーキーワードを作成できます。
例えば、概念的には以下のようなテストケースを記述できます。
Test Cases
正常にログインできること
ログイン画面を開く
ログインする test_user password
ダッシュボードが表示されること
「ログインする」というキーワードの中に、ユーザー名入力・パスワード入力・ボタンクリックなどの処理をまとめておけば、別のテストケースでも同じキーワードを再利用できます。
Robot Frameworkのほかにも、キーワードを利用したテスト設計や自動化を支援するツールは存在します。
重要なのはツールそのものではなく、
- キーワードをどう設計するか
- どの粒度で再利用するか
- 誰がキーワードを管理するか
を事前に決めることです。
キーワード駆動テストのメリット
テストの保守性を高めやすい
キーワード駆動テストでは、テストケースと具体的な実装を分離できます。
例えばUIの変更によってログイン処理の実装を変更する必要が生じても、「ログインする」というキーワードの実装を修正するだけで、そのキーワードを利用している複数のテストケースに変更を反映できます。
同じ処理を各テストケースに重複して記述するよりも、変更箇所を集約しやすくなるため、長期間運用する回帰テストなどで効果を発揮します。
キーワードを再利用できる
一度作成したキーワードは、複数のテストケースで再利用できます。
ECサイトであれば、
- ログインする
- 商品を検索する
- カートに追加する
- 注文する
- ログアウトする
といったキーワードを組み合わせることで、さまざまなユーザーシナリオを構築できます。
テストケースが増えるほど、共通処理を再利用できるメリットも大きくなります。
テストの意図を理解しやすい
テストケースを業務用語に近いキーワードで記述することで、プログラムコードよりもテストの目的を把握しやすくなります。
そのため、自動化エンジニアだけでなく、QA担当者、プロジェクトマネージャー、業務担当者などもレビューに参加しやすくなります。
ISTQBの資料でも、キーワード駆動によって自動テストの可読性や理解しやすさを高められることがメリットとして挙げられています。
データ駆動テストと組み合わせられる
キーワード駆動とデータ駆動を組み合わせることで、再利用性をさらに高められます。
例えば「ログインする」というキーワードを一つ作り、
| ユーザー名 | パスワード | 期待結果 |
| user01 | correct123 | 成功 |
| user01 | wrong123 | 失敗 |
| invalid | correct123 | 失敗 |
のように複数のデータを渡せば、同じキーワードを利用しながら異なる入力パターンを効率よく検証できます。
キーワード駆動テストのデメリット
初期構築にコストがかかる
キーワード駆動テストを始めるには、最初に、
- 自動化する対象を決める
- キーワードを設計する
- 命名ルールを決める
- キーワードに対応するコードを実装する
- 実行基盤を構築する
といった準備が必要です。
そのため、少数のテストを短期間だけ自動化する場合は、構築コストの方が大きくなることがあります。
キーワード駆動テストは、テストケースが継続的に増える環境や長期的な回帰テストほどメリットを得やすい手法です。
キーワードが増えすぎると管理が難しくなる
プロジェクトの規模が大きくなると、キーワードの数も増えていきます。
管理ルールがないまま追加すると、
- 「ユーザーを作成する」
- 「新規ユーザーを作る」
- 「ユーザー登録」
- 「会員を登録する」
など、同じような役割を持つキーワードが乱立する可能性があります。
その結果、どのキーワードを使えばよいのか分からなくなり、本来の再利用性や可読性が低下します。
命名規則やキーワード辞書を整備し、定期的に重複や不要なキーワードを整理する必要があります。
抽象化しすぎるとテスト内容が分かりにくくなる
「購入処理」のような大きすぎるキーワードの中に何十個もの処理をまとめてしまうと、テストケースだけを見ても具体的に何を検証しているのか分からなくなることがあります。
逆に、「ボタンをクリックする」「文字を入力する」といった低レベルなキーワードばかりにすると、通常のテストコードと変わらないほど記述量が増えます。
そのため、適切な粒度でキーワードを設計することが重要です。
チームへの定着に時間がかかる
キーワード駆動テストでは、
- 誰が新しいキーワードを作成するのか
- 既存キーワードをどう検索するのか
- 変更時に誰がレビューするのか
- 廃止したキーワードをどう扱うのか
といった運用ルールが必要です。
仕組みだけ導入しても、チームでルールが共有されていなければ定着しません。
ドキュメントやキーワード辞書を整備し、レビュー体制を作ることが重要です。
キーワード駆動テストが向いているケース
キーワード駆動テストは、特に以下のようなプロジェクトに適しています。
同じ業務操作を複数のテストで利用する
ログイン、ユーザー登録、検索、注文など、同じ操作が多くのテストケースで登場する場合はキーワード化による再利用効果が高くなります。
回帰テストを長期間運用する
リリースのたびに同じテストを繰り返す場合、変更箇所をキーワードの実装へ集約できるため、保守性を高めやすくなります。
QAと自動化エンジニアが分業している
業務要件を理解しているQA担当者がテストシナリオを設計し、自動化エンジニアがキーワードを実装する、といった役割分担と相性が良い手法です。
非エンジニアもテスト内容をレビューする
業務用語に近いキーワードで記述することで、プログラムコードに詳しくないメンバーでもテスト内容を確認しやすくなります。
キーワード駆動テストが向いていないケース
反対に、以下のようなケースでは十分な効果を得られない可能性があります。
- 自動化するテストケースが非常に少ない
- 短期間で終了するPoC
- 再利用できる共通操作がほとんどない
- テスト対象や仕様が極端に頻繁に変わる
- キーワードを継続的に管理する担当者を置けない
すべての自動テストをキーワード駆動へ置き換える必要はありません。
対象となるテストの規模や運用期間を考え、キーワード化することで十分な効果が見込める領域から導入することが重要です。
キーワード設計で失敗しないための5つのポイント
1. キーワードの粒度を統一する
「ログインする」と「ログインボタンをクリックする」のように、異なる粒度のキーワードが無秩序に混在すると使いにくくなります。
業務レベル、操作レベル、技術レベルなど、階層を意識して整理しましょう。
2. 業務上の意味が伝わる名前を付ける
可能な限り、「クリックする」ではなく「注文を確定する」のように、何のための操作なのかが伝わる名称にします。
3. 同義のキーワードを増やさない
新しいキーワードを作る前に、既存キーワードで代替できないか確認するルールを設けます。
4. キーワード辞書を作成する
最低限、以下の情報を管理すると運用しやすくなります。
- キーワード名
- 目的
- 引数
- 戻り値
- 使用例
- 管理者
- 関連する実装
- 廃止予定の有無
5. 定期的に整理する
使われなくなったキーワードや重複キーワードを放置すると、時間の経過とともに管理コストが増大します。
コードレビューと同じように、キーワードについても定期的なレビューを行うことが重要です。
キーワード駆動テストの導入手順
実際に導入する場合は、いきなりすべてのテストをキーワード化するのではなく、段階的に進めることをおすすめします。
1. 自動化対象を選定する
まず、繰り返し実行される回帰テストなど、自動化による効果が高いテストを選びます。
2. 共通操作を洗い出す
複数のテストケースに登場する操作を抽出します。
例えば、
- ログイン
- 検索
- 登録
- 更新
- 削除
- ログアウト
などです。
3. キーワードと命名ルールを決める
抽出した操作を、誰が読んでも意味が分かるキーワードとして定義します。
この段階で粒度や命名規則を統一しておくことが重要です。
4. 小規模なPoCを行う
代表的なシナリオを数件選び、実際にキーワード駆動で自動化します。
PoCによって、
- キーワードの粒度は適切か
- 再利用できるか
- メンテナンスしやすいか
- チームが理解できるか
を確認します。
5. キーワード辞書と運用ルールを整備する
PoCで得られた知見をもとに、キーワードの追加・変更・廃止に関するルールを決めます。
6. 適用範囲を段階的に拡大する
効果が確認できたら、対象となる回帰テストやシステムへ適用範囲を広げていきます。
キーワード駆動テストに関するよくある質問
キーワード駆動テストとデータ駆動テストは併用できますか？
可能です。
キーワードによってテスト操作を抽象化し、そのキーワードへ複数のテストデータを渡すことで、両方のメリットを活用できます。
キーワード駆動テストならプログラミングは不要ですか？
テストケースを作成する人が必ずしもプログラムを書く必要はありませんが、キーワードの実装や自動化基盤の構築にはプログラミングやテスト自動化に関する知識が必要になる場合があります。
「ノーコードで自動化できる手法」というより、テスト設計者と実装者の役割を分離しやすくする手法と考えた方が適切です。
Robot Frameworkは必須ですか？
必須ではありません。
Robot Frameworkはキーワード駆動型の自動化を実現できる代表的なフレームワークの一つですが、他のツールや独自フレームワークでもキーワード駆動の考え方を採用できます。
キーワードは細かく分けるほどよいですか？
必ずしもそうではありません。
細かすぎるキーワードはテストケースを冗長にし、大きすぎるキーワードは内部で何をしているのか分かりにくくします。
「テストの意図が分かること」と「再利用できること」のバランスを取ることが重要です。
まとめ
キーワード駆動テストとは、テストで行う操作や検証を「キーワード」として抽象化し、テストの設計と実装を分離するアプローチです。
「ログインする」「商品を検索する」といった業務上理解しやすいキーワードを組み合わせてテストケースを表現できるため、テストの可読性や再利用性を高めやすく、QA担当者と自動化エンジニアの分業にも適しています。
また、データ駆動テストと組み合わせたり、Robot Frameworkのようなフレームワークを利用したりすることで、さまざまなテスト自動化へ応用できます。
一方で、キーワードを増やしすぎると管理が複雑になり、適切な粒度や命名規則を決めなければ、本来のメリットを十分に得られません。
導入時は、すべてのテストを一度にキーワード化するのではなく、再利用性が高い回帰テストなどから小さく始めることが重要です。
長期的に運用するテスト自動化の保守性を高めたい場合や、QA・開発・業務担当者が共通の言葉でテストシナリオを共有できる環境を作りたい場合、キーワード駆動テストは有力な選択肢の一つとなるでしょう。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事の監修
Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。
記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）
