筆者が所属する会社での取り組み
本節では、筆者が所属する会社でテスト自動化にどのように取り組んでいるか、概要を紹介します。
テスト自動化フレームワーク
弊社で利用されている自動テストのフレームワークは、キーワード駆動の考え方をベースとして開発されています。その主な構成要素は次の4つです。
(a) キーワードの定義
(b) (a)の内部実装である補助スクリプト群
(c) (a)で記述されたテストケース群
(d) (c)を実行するエンジン
さらにここに、データ駆動、キャプチャー・リプレイを組み合わせることで、それぞれの良さを引き出しています。
まず、キーワードに対応するソフトウェアへの操作を自動的にスクリプト化するためにキャプチャーリプレイツールを使用し、(b)を作成する際の土台にしています。また、(c)の中でキーワードごとに指定するデータを、値そのものでなく外部に定義したファイルからも呼び出せるようにすることで、(c)の1行で同じキーワードを繰り返し実行できる仕組みになっています。これはデータ駆動の考え方といえるでしょう。
この仕組みを使えば、たとえば「必要なユーザを事前に100人作成する」という操作を、1行のキーワードと1つの外部ファイルで実現することができます。キーワード駆動においては、(c)のテストケースをスプレッドシート上に記載するのが一般的ですが、その場合、繰り返しの表現が1つの課題になります。データの外部化は、この課題に対する1つの有力な解かと思います。
ロールの区分
キーワード駆動におけるロールは、大きく2つに分けられます。1つは、「どういうテストをすべきか」を考える人で、ドメインエキスパートやテストエンジニアがそれに当たります。もう1つは、テスト自動化フレームワークや補助スクリプトを実装するテスト自動化エンジニアです。
弊社では、後者をさらに2つに分けています。
1つは、自動化を行うフレームワーク自体を担当するチームです。このチームは、フレームワークの設計・構築・保守・改善、各プロジェクトへの導入支援といったタスクに責任を持ちます。もちろんフレームワークのエンジン部分のみならず、JenkinsによるCI（継続的インテグレーション）、SubversionやGitによるソースコード管理、Chefによる環境の自動構築といった、開発インフラ全体まで面倒を見てくれています。
もう1つは、このフレームワークに基づいて自動化を推進する、各プロジェクトの自動化担当チームです。こちらのチームはドメイン知識を有しているので、テスト設計・テスト実装やキーワードの実装を行い、テストを動かすところまでを担当しています。
キーワードの難しさ
さて、キーワード駆動テストについて、ギア本でも、そしてTABOKでもISTQBでも言及されていない、重要な課題があります。それは、「どのようにキーワードを選ぶのか」というものです。キーワードはドメインやテストレベルに強く依存するので一概には決めがたいのですが、粒度を選び間違うと禍根を残しかねないので、慎重な検討が必要です。
弊社のフレームワークでは、作成済みのキーワードを束ねて、別の（より抽象的な）キーワードを定義することが可能になっています。上述のように、テストの目的ごとに必要とされる粒度は異なるので、こういった機能がサポートされていることはとても重要です。
また、「各キーワードをどれだけロバストなものにするか」という点も悩みどころです。先の例でいうと、「発注する」前に「注文の状況を確認する」という使われ方をされかねない（あるいはそういうテストをあえて行う）という前提でエラー処理を作り込んでおくのか、業務に詳しい人間が使うのだから適切な順番で呼ばれることを期待してほどほどの作り込みにとどめるのか、といった度合いも、チームで合わせておく必要があるでしょう。
いずれにしても、ドキュメンテーションは重要なタスクになります。これはギア本で繰り返し強調されることであり、現在でも変わらない現実でしょう。
ソフトウェアテストの標準規格であるISO/IEC/IEEE 29119[3]では、そのPart 5でキーワード駆動テストを扱う予定です。キーワードの適切な選び方・実装の仕方については、この規格にも期待したいですね！
[3] 本稿公開時点では、Part 3の「Test Documentation」までが発行済みです。
