キーワード駆動テストの導入

 最近キーワード駆動テストがややバズワード化している傾向を感じている。というのも、キーワード駆動テストの導入で無用な手間を増やしている場面を見るようになっているためだ。
 キーワード駆動テストはフレームワークによっては手間を増やすことがあるので、その導入にあたっては、導入内容が目的に見合っているか多少の注意を向ける必要があると感じる。基本的な事柄であえて言及する必要もない内容かも知れないが、今回はそれについて簡単に触れたい。

キーワード駆動テストの目的

 言及するまでもないかもしれないけれども、何かしらの改善を行う際は、その手段が目的に見合っているか留意する必要がある。ではキーワード駆動テストの目的は何かというと、大雑把にまとめて以下の3つがある。なおこれは排他ではなく、一緒に目指しても良い。

目的(1)テストの保守性改善

 まず目的の一つに、テスト設計やテスト実装物の保守性改善のための構造化手段として、キーワード駆動テストを導入する場合がある。例えば以下のような目的だ。

  • 重複テストコードを共通ロジックに、非重複テストコードをキーワードに展開してテストスクリプトのコピペを削減し、保守のミスを防ぐ。
  • 可変性分析で抽出した流動的要素をキーワードに展開することで、テストケースやテストコードの変更性を高める。

目的(2)非開発者をテスト設計に巻き込む

 次に、非開発者でもテスト設計・実装が行えるようにするのもキーワード駆動テストの主な目的とされる。例えばテスト実装スキルのないユーザやテストエンジニアが、キーワードを組み合わせてテスト設計を行ったり、キーワードの組み合わせでテストをレビューしたりするのを実現する手段として、キーワード駆動テストのフレームワークを導入する。そこでは具体的にはExcelWikiによるテストケースの記述や、非開発者が読めるDSLでのテストケースの記述などが実現される。
 キーワード駆動テスト向けのフレームワークは、基本こちらの目的に対応したものが多い。

目的(3)テストの抽象化

 その他としては、テストの保守性と被る部分もあるが、テストケースの抽象化手段として用いられることがある。例えば、抽象的な手順をアクションワードで表現し具体的な手順はフレームワークが担保することで、以下を実現する。

  • テスト対象が変更されてもテストケースに影響がないようにする(フレームワークが変更部分を吸収する)。
  • 一つのアクションワードを複数の環境や条件間のテスト手順に横断的に展開できるようにする。

 この目的も、キーワード駆動テストの目的として一般的だ。

キーワード駆動テストの導入の注意点:目的を取り違えないこと

目的(2)のツールを導入する場合の注意点

 まず、見ていて注意が必要だと感じているのが、上記の目的(1)目的(3)の達成のために、目的(2)の用途のフレームワークや技術を導入してしまうパターンだ。
 目的(2)のために作られたフレームワークは、非技術者でもテスト設計を担当できるようにする。その代償として、保守性の作りこみに制限をかけたり、キーワードをテストスクリプトに落としこむ手間でテスト実装の効率性を落としたりすることがある。極端な例だと、「テストケース仕様をExcelで書くようにして構成管理コストを悪化させる」「テストケースのフォーマットをキーワード形式に無理に合わせるためにテストの可読性を犠牲にする」といったものがある。
 そのため、目的(2)のフレームワークを導入すると、目的(1)(3)の達成を難しくする場合がある。そして上記でも軽く触れたけれど、商用のキーワード駆動テストのフレームワークは目的(2)の用途を想定したものが多いので注意が必要だと感じる。目的(2)の達成も十分価値があることだけれど、その価値が活かせない環境ならば、手間が増えるだけになってしまうかもしれない。

目的(1)(3)の改善が必要な場合の注意点

 一方、目的(1)目的(3)が要求される状況では、背景としてそもそもテストスクリプトの品質の悪さが根本原因である場合が少なくない点に留意が必要だ。フレームワークを導入してキーワード形式でフォーマットを固定するよりも、愚直にテストスクリプトの設計改善を行ったほうが問題が解決することがある。
 コードやスクリプトの形式をフレームワークで固定して設計品質を向上させるのはDIやバインディングなどであるけれども、それは設計品質の向上を意図して作られているからできるというのを忘れてはいけない。

目的(2)の改善が必要な場合の注意点

 また目的(2)が要求される場合、そもそもスキル的な問題が根本原因にあることがある。そこではフレームワークを導入するより、テストスクリプトを書けるように教育・人員確保を行ったり、スクリプトの保守性を上げて部分的にでも非開発者がメンテナンスできるようにしたほうが、全体の生産性が高まる場合がある。
 あと目的(2)については、キーワード駆動テストにスクリプトを無理に合わせこむことで、ユーザ等にとってかえってテストがわかりにくくなり書きづらくなることがある。今では柔軟なDSLでテストを書けるフレームワークが複数出ているので、キーワード駆動テスト以外の選択肢の必要性も考慮したほうが良いと思う。

まとめ

 とにかく、キーワード駆動テストを導入する際は、新技術だから、流行っているからという印象でフレームワークに飛びすくのではなく、目的とフレームワークの方向性が一致しているか検討するのも大事だと思う。極端に言えば「担当者は皆テストコードが書けるのに、新技術という事であえてテストをコードでなくExcelで書くように変更した」と同じようなことをしてしまっている可能性もあると感じる。