キーワード駆動型テスト

キーワード駆動テストは、アクション ワード ベース テストとも呼ばれ(アクション駆動テストと混同しないでください)、手動テストと自動テストの両方に適したソフトウェア テスト手法です。この方法では、テスト ケースのドキュメント (使用するデータと機能の両方を含む) と、テスト ケースの実行方法の規定を分離します。その結果、テスト作成プロセスが、設計および開発段階と実行段階の 2 つの異なる段階に分割されます。設計サブステージでは、要件分析と評価、およびデータの分析、定義、および入力がカバーされます。

この方法では、 Enter Clientなどのテスト対象の機能を象徴するキーワード (またはアクション ワード) を使用します。キーワードEnter Client は、データベースに新しいクライアントを入力するために実行する必要がある一連のアクションとして定義されます。キーワードのドキュメントには次の内容が含まれます。

• テスト対象システム (SUT) の開始状態
• 開始するウィンドウまたはメニュー
• キーまたはマウスをクリックして正しいデータ入力ウィンドウに移動します
• 検索するフィールドの名前と入力する引数
• 追加のダイアログがポップアップ表示された場合（確認など）に実行するアクション
• 送信するためにクリックするボタン
• アクションの完了後に SUT がどのような状態になるべきかについての主張

キーワード駆動型テストの構文では、表形式を使用してテスト ケース (データとアクション ワード) がリストされます (以下の例を参照)。最初の列 (列 A) には、テスト対象の機能であるキーワード Enter Client が含まれます。残りの列 BE には、キーワードを実行するために必要なデータ (名前、住所、郵便番号、市区町村) が含まれます。

別のクライアントを入力するには、テスターはテーブルに別の行を作成し、キーワードとして「クライアントを入力」を入力し、次の列に新しいクライアントのデータを入力します。含まれるすべてのアクションを再リストする必要はありません。

ここでは、次の方法でテスト ケースを設計できます。

• テストを実行するためにアプリケーションおよびシステムと対話するために必要な高レベルの手順を示します。
• 機能が適切に動作していることを検証および認証する方法を示します。
• テストの前提条件を指定します。
• テストの受け入れ基準を指定します。

ソフトウェア開発の反復的な性質を考えると、テスト設計は通常、テストの手動実装よりも抽象的（具体性が低い）ですが、簡単に手動実装に進化させることができます。

キーワード駆動型テストでは、テスト対象のシステム/ソフトウェア (SUT) の変更によるメンテナンスに対する感度が軽減されます。画面レイアウトが変更されたり、システムが別の OS に移行されたりしても、テスト ケースを変更する必要はほとんどありません。変更はキーワード ドキュメントに対して行われます。キーワードがテスト ケースで何回使用されているかに関係なく、キーワードごとに 1 つのドキュメントが作成され、テスト設計の詳細なプロセスが示されます。

また、キーワードの実行方法が非常に詳細に説明されているため（キーワードドキュメント内）、ほとんど誰でもテストを実行できます。したがって、キーワード駆動テストは手動テストと自動テストの両方に使用できます。^[1]

さらに、このアプローチは、テスト作業に関連する、またはテスト作業によって生成されるすべてのツール、資産、データを統合するオープンで拡張可能なフレームワークです。この単一のフレームワークの下で、テスト作業のすべての参加者は、取り組んでいる品質目標を定義し、改善することができます。チームは、このフレームワークで、それらの目標を達成するために実行する計画を定義します。そして、最も重要なのは、いつでもシステムの状態を判断できる 1 つの場所をチーム全体に提供するということです。

テストは、ソフトウェア開発プロセスにおけるフィードバック メカニズムです。テストは、開発作業の任意の反復で、正しい方向に進むために修正が必要な箇所を示します。また、開発中のシステムの現在の品質も示します。テストの実装アクティビティには、テスト ケースを実装する再利用可能なテスト スクリプトの設計と開発が含まれます。実装後、テスト ケースに関連付けることができます。

実装はテスト プロジェクトごとに異なります。1 つのプロジェクトで、自動テスト スクリプトと手動テスト スクリプトの両方を作成することに決める場合があります。^[2] 一方、テストの設計は反復的なプロセスです。ユース ケース仕様、要件、プロトタイプなどに基づいてテスト設計を行うことで、システム実装の前にテストの設計を開始できます。システムがより明確に指定され、作業するシステムのビルドが用意されるにつれて、設計の詳細を詳しく説明できます。テストを設計するアクティビティは、「テストをどのように実行するのか」という質問に答えます。完全なテスト設計は、システムで実行する必要があるアクションと、システムが適切に機能している場合に観察される動作と特性について読者に通知します。

テスト設計は、テスト実装の構築方法を決定する際に実行する必要がある設計作業とは異なります。

キーワード駆動型テスト方法では、テスト プロセスの実行をいくつかの段階に分割します。

1. モデルベース/プロトタイピング: 要件の分析と評価。
2. テスト モデルの定義: 要件評価の結果に基づいて、独自のソフトウェア モデルにアプローチします。
3. テスト データの定義: 定義された独自のモデル、開始キーワード、およびメイン/補足データの定義に基づきます。
4. 試験対策：入学試験対策など
5. テスト設計: テストベースの分析、テストケース/手順の設計、テストデータの設計。
6. 手動テスト実行: キーワード ドキュメントを実行ガイドラインとして使用して、テスト ケースを手動で実行します。
7. テスト実行の自動化: キーワード ドキュメントに従ってアクションを実行する自動スクリプトの作成。
8. 自動テスト実行。

キーワードまたはアクション ワードは、テスト オブジェクトに対するアクションの定義済みの組み合わせであり、テスト ラインの実行方法を説明します。アクション ワードには引数が含まれており、テスト アナリストによって定義されます。

テストは開発プロセスの重要なステップであり、オブジェクト（システム/SWテスト - SUT）に一連のテストまたはチェックを適用する必要があります。テストではエラーの有無は示せませんが、エラーが存在しないかどうかは示せないことを常に覚えておいてください。RTシステムテストでは、SUTが正しい出力を生成するかどうかを確認するだけでは不十分です。出力を生成するのにかかる時間が予想どおりであるかどうかも検証する必要があります。さらに、これらの出力のタイミングは、入力のタイミングに依存する場合もあります。次に、適用可能な将来の入力のタイミングは、出力から決定されます。^[2]

実装段階はツールやフレームワークによって異なります。多くの場合、自動化エンジニアは「チェック」や「入力」などのキーワードを提供するフレームワークを実装します。^[1]テスターまたはテスト設計者（プログラミングの知識は必要ありません）は、エンジニアが実装した計画段階で定義されたキーワードに基づいてテストケースを作成します。テストは、キーワードを読み取り、対応するコードを実行するドライバーを使用して実行されます。

他の方法論では、オールインワンの実装段階を使用します。テスト設計とテストエンジニアリングのタスクを分離するのではなく、テスト設計がテスト自動化になります。「編集」や「チェック」などのキーワードは、必要なコードがすでに記述されているツールを使用して作成されます。キーワードの実装がすでにツールの一部になっているため、テストプロセスに追加のエンジニアが必要なくなります。例としては、 GUIdancer やQTP などがあります。

• 長期的にはメンテナンスの負担は少ない:
  • テストケースは簡潔である
  • テストケースは関係者にとって読みやすい
  • テストケースは簡単に変更できる
  • 新しいテストケースでは既存のキーワードをより簡単に再利用できる
• 複数のテストケースにわたるキーワードの再利用
• 特定のツールやプログラミング言語に依存しない
• 分業
  • テストケースの構築には、より高度なドメイン専門知識が必要であり、ツールやプログラミングのスキルはそれほど必要ではない
  • キーワードの実装には、より高度なツール/プログラミングスキルが必要であり、ドメインスキルは比較的低い
• レイヤーの抽象化

• 市場投入までの時間が長くなる（手動テストや記録と再生の手法と比較して）
• 最初は学習曲線が中程度に高い

• データ駆動型テスト
• テスト自動化フレームワーク
• テスト駆動開発

• アクションベースのテスト
• キーワード駆動テストの成功要因、Hans Buwalda 著
• SAFS (ソフトウェア自動化フレームワーク サポート)
• テスト自動化フレームワーク
• 自動化フレームワーク - gFast: 自動化ソフトウェアテストの汎用フレームワーク - QTP フレームワーク