この記事は6 Reasons You Should Be Doing Behavior-Driven GUI Testing With Squishの抄訳です。

振る舞い駆動開発(BDD)という概念は目新しいものではありません。実は2009年の時点で、このトピックに関する複数のプレゼンテーションがネット上で公開されているのです。それでも、多くの人はこの概念から少し距離をおいて、次のような疑問を抱いています。

• BDDは単なる一時的な流行なのか、それとも本質的な何かなのか？
• 自分の仕事と関係があるのか？
• なぜ、テスト開発において振る舞い駆動型アプローチを考慮する必要があるのか？

この3つの質問に対する答えは....声高らかな「Yes！」です。Squishを使用したGUIテスト自動化への動作駆動型アプローチは、より早い段階でのテストの作成や異なる役割を担うより多くの人々の品質保証プロセスへの参加、さらにテストケースのモジュール化やツールによるサポートのような、実質的かつ具体的な利点だけではなく、テスト結果分析のより洗練された方法など、大きな利益をもたらします。

では、それぞれのメリットを詳しく説明し、その内容を見ていきましょう。

1. 抽象化による、より堅牢なテストの作成。「どのように」ではなく「なにを」をベースにしたテストケース
2. 共通の言語によるチーム間のコラボレーションの改善
3. 完全な実装を待たずにソフトウェアテストを開始できる
4. より良いツールサポート
5. テストスクリプトの自動モジュール化
6. テスト結果分析の単純化

しかし、その前にまずはBDDとは何かということを確認しておきましょう。

振る舞い駆動開発とは？

振る舞い駆動開発とは、ソフトウェア開発者、テストエンジニア、技術者以外のチームメンバーなど、ソフトウェアプロジェクトにおける異なる役割間のコラボレーションを促進する、ソフトウェアエンジニアリングのアプローチです。その中心的な考え方は、メンバーの会話を促し、例を用いて、ソフトウェアがどのように機能すべきかについて全員の共通理解を作ることです。

これは、動作と期待される結果の記述に自然言語（例えば、日本語で記述した文章）を用いた単純なドメイン固有の記法を使用することによって、実現されます。そのために使用されるGherkin記法は、期待される動作を表現するための準標準となる記法です。

Gherkin記法を使うと、ソフトウェアの機能は、Feature（たとえば、「プレビューレンダリングを実施する」など）をベースとして記述されます。次に、それぞれのFeatureに対して「緑色のキューブ型オブジェクトのプレビューレンダリングを作成する」というような、より具体的かつ異なるユースケース（シナリオ）が記述されていきます。

各シナリオは一連のステップとして表現され、通常「Given/When/Then」キーワードを使用した構造としてそれぞれグループ化されます。

BDDは基本的に、ビジネス上の利益と技術的な観点の両方によってソフトウェア開発を管理する手法ですが、実際にBDDにのっとった開発を行う際には、開発プロセスをサポートするための特別なソフトウェアツールの使用を前提としています。Squishは、振る舞い駆動型GUIテスト自動化プロジェクトに対する実践的なサポートを備えています。

Squishで振る舞い駆動のGUIテスト自動化を行う方法については、bdd.tipsというウェブサイト、もしくはSquishマニュアルをご覧ください。

1. 抽象化による、より堅牢なテストの作成。「どのように」ではなく「なにを」をベースにしたテストケース

自動テストの重要な要件は、それらが安定していることです。これは、テスト対象のアプリケーション(AUT) が変更された場合でも、テストが継続的に実行可能であることを意味します。Squishでは、これを確実にするために多くの改善が行われました。これらの対策のほとんどは、中心的で基本的な洞察を実装することに落ち着きました：「テストコードは可能な限り抽象的であるべき」という考えです。

つまり、何かがどのように行われるか（例えば、「特定のボタンをクリック」や、もっと良くないケースだと、「画面上のX/Y座標をクリック」など）という観点からテストを記述するのではなく、何が行われるか（例えば、「アカウント作成の確認」）に焦点を当てるということです。

しかし、スクリプト言語での作業では、得てして抽象度を間違えやすいものです。「何をするか」に集中するためには、かなり意識的な作業が必要です。

振る舞い駆動型テストを表現するために使用される Gherkin記法は、ループや条件式といった典型的なスクリプト言語の機能を備えていないため、抽象的なテストケースの記述を促す形になっています。また、最小限の構文しか使わないので、ほとんどの部分はプレーンテキストと同じように読み書きすることができます。これは、テストケースの抽象度を高く保つことに大いに役立ちます。

2. 共通の言語によるチーム間のコラボレーションの改善

ソフトウェア開発はチームで行うものです。最もシンプルなプロジェクトを除いて、ほとんどのソフトウェアはチームによって開発されます。多くの場合、そのプロセスにおいて、さまざまな人が異なる役割を担っています。たとえば、次のようにです。

• ビジネスアナリストは、顧客のニーズを理解するために情報を収集する
• インタラクションデザインの専門家は、適切なユーザーインターフェイスをモデリングする
• ソフトウェア開発者はアプリケーションを実装する
• 品質保証の専門家が製品の品質を検証する

Gherkin記法を使用した振る舞い駆動型仕様書は、メンバー全員が開発中のアプリケーションに対して同一の認識を持っていることを確実にするための、素晴らしい方法です。Gherkin記法によって正しく振る舞いが記載された仕様書は、プロジェクト開始直後から活用することができます。顧客はその妥当性を確認し、インタラクションデザイナーは望ましいユースケースを明確に理解し、テストエンジニアは、Gherkin記法をサポートするソフトウェアツールがあれば、ソフトウェア開発者が開発中のアプリケーションに対するテストケースとして使用することができるのです。

Gherkin記法を使った振る舞い駆動型のテストケースは、同じ情報を全く異なる役割を持つメンバーに正確に伝えることができるだけではなく、実際にテストケースとして実行可能な仕様としても機能します。このテストケースは、真実の唯一の情報源として機能し、チームメンバー間で生じうる誤解を避けることができます。

3. 完全な実装を待たずにソフトウェアテストを開始できる

SquishのBDD機能の大きな利点は、手元に完全なアプリケーションがなくても、Gherkin記法で記述された期待動作を実行できることです。

Gherkin記法を読み込んでSquishでBDDテストケースを作成する場合、Squish IDEは最初、すべてのステップの横に警告アイコンを表示します。

これは、このテストがそのままでは実行できないことを示しています。テストを実行するためには、Squis IDEは、Gherkin記法で記載されたステップごとに、実際にアプリケーションに対して実行する UI インタラクションを知る必要があります。しかし、Squishに各ステップに関連付けられた空の関数である「ステップ実装スケルトン」を生成させることは可能です。ワンクリックで、すべてのステップが空の(アクションのない)実装と関連付けられます。

すべてのステップが実装されたら (実装が空のスケルトンであっても)、テストの実行自体は可能となります。これらのテスト結果はすべて成功となりますが、 空のステップに対しては、まだ実際のインタラクションを実装する必要があるという警告が表示されます。しかし、テストの実行はこの時点で可能なので、テストスイートを継続的インテグレーション（CI）システムに統合して、テストが実行されるようにすることができます。

アプリケーションが実装され、機能が追加されると、空のプレースホルダーに実際のUIインタラクションを実装していくことができます。そうすることで、アプリケーションと並行してテストスイートも成長し、開発とテスト開発が同時に行われていきます。

4. より良いツールサポート

Squish IDEは、Gherkin記法で記述されたファイルの構造を理解できます。テストケースは機能(Feature)、シナリオ(Scenario)、手順(Step)で構成されており、それらは通常「Given/When/Then」構造で記述されます。これを利用することで、IDE は単なるスクリプトベースのテストケースよりも優れたテスト開発のサポートを提供することができます。スクリプトベースのテストは、自由形式であることが強みですが、その分、IDE がスクリプトに対して予測や想定できることが少なくなります。

例えば、スクリプトベースのテストケースを作成する際、SquishはIDE上で関数名を自動補完してくれます。しかし、どのような関数名でも呼び出すことができるため、補完結果はかなり大きくなり、適切な名前を見つけるまで多少のナビゲーションが必要になる場合があります。

BDDテストケースの場合、補完はより正確です。IDEは、「Given（前提条件）」ステップの後、「Then（期待動作）」ステップは確実に不要であることを理解しています。したがって、候補リストの一番上に関連するマッチを見つける可能性が高くなるように、候補リストを最適化することができます。

BDDテストのもう一つの利点は、新しいテストを録画するのに役立つということです。

従来のスクリプトベースのテストで作業する場合、新しいスクリプトコードを記録する際に、次のような問題に直面することがありました。

• 新しいテストケースをゼロから記録する際に、ログインなどの毎回行われるような一般的なインタラクションシーケンスを何度も繰り返し録画しなければならない。
• スクリプトのスニペット（部分的なスクリプト）を記録する場合、記録した一連のインタラクションをスクリプトコードに挿入する位置をユーザが正確に特定する必要がある。

振る舞い駆動型テストケースはこれらの問題を大幅に改善します。BDDテストケースを録画するとき、Squishはこれから録画するステップがすでにインタラクションの紐づけ済みのステップである場合は当該ステップの録画をスキップし、録画されていないステップの録画のみを行います。そして、一回一回の録画セッションで不足しているステップを徐々に埋めていき、同時に既存のステップの実装（カスタム/リファクタリング可能）が自動的に再利用されるようにすることができます。

BDDテストケースの記録が実際にどのように行われるかは、こちらのビデオをご覧ください。

5. テストスクリプトの自動モジュール化

振る舞い駆動型GUIテストの実装には、もう一つの利点があります。それは、テストスクリプトの自動的なモジュール化です。

従来のスクリプトベースのテストケースは、スクリプトコードが保守・拡張・再利用が困難な巨大な一枚岩に成長しないように、多くの慎重な検討と規範を必要とします。そのため、技術的な負担が大きくなりがちで、この問題を回避するためには、専門的なソフトウェアエンジニアリングのノウハウが必要です。

振る舞い駆動型の GUI テスト開発は、この点でとても役立ちます。スクリプトコードの連続した1つのブロックを扱う代わりに、Gherkin記法に従ってテストケースを作成することで、複雑なテスト手順をより小さなステップに暗黙的に分解することができます。同様に重要なのは、各UIインタラクションを実行するスクリプトがGherkin記法で記述されたテストケース側のステップひとつひとつに紐づいていることです。つまり、何かがどのように行われるか (Create ボタンをクリックする)ではなく、何が行われるか (ユーザーアカウントを作成する)という単位ごとに、それぞれのスクリプト処理が存在するのです。

これによって自動的に適切な抽象化レベルを実現できます。熟練したソフトウェアエンジニアが行うのと同じように、スクリプトコードは個々の関数にうまく分解され、それぞれの関数は、その関数が何を行うべきかとその方法を定義する実装という単位でまとめられます。

6. テスト結果分析の単純化

Gherkin記法で記述された文書は、テストケースとして実行可能な文書です。それらはプロジェクトの開発プロセス全体に付随しますが、テスト報告書も例外ではありません。期待動作をGherkin記法で記述した文書を最終的なテストレポートに関連付けることで、各検証結果は、検証時に実行されたステップと関連付けられます。つまり、どのように検証したのか（「ボタンが有効になっていることを期待したが、有効になっていない」）だけでなく、何を検証したのか（「文書を保存できること」）もテストレポートで確認が可能になります。

さらにそこでは、BDD仕様の構造も踏襲されています。BDDの各テストケースは、テストする機能(Feature)を最上位に、その機能を実行するさまざまなシナリオ(Scenario)を第二階層として、階層的に構成されています。そのため、テストレポートを閲覧する際、従来の非階層的かつ膨大な検証の連続に直面することなく、徐々にドリルダウンし、異なるレベルの粒度でテストレポートを閲覧することができるのです。

これは、Test Centerのような強力なテスト結果管理プラットフォームにおいて特に顕著になります。Gherkin文書の構造がきれいに見えるので、どのようにではなく、何が行われたかに焦点を当てながら、整然としたテスト結果を確認することができます。

おわりに

以上が、記事の内容となります。

SquishをはじめとするQtのQA(品質保証)ツールにご興味のおありの方は、Qt JapanのEメールアドレス：japan@qt.ioまでお気軽にご連絡ください。

概要のご説明から詳細な技術的相談、また無料のツールトライアルのご案内もいたしております。