2019年6月24日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #8: テスト可能な要件を作成する

テスト可能な要件の原則

「テスト可能な要件」では、要件が満たされていることを判断するためのテストを作成できるよう、アプリケーションの単一の機能、または振る舞いを記述します。テストが可能であるためには、要件に曖昧さがなく、明確で、測定可能でなければなりません。

たとえば、Webショッピングアプリケーションのテストを計画しており、次の要件が提示されたとします。

“簡単で使いやすい、在庫商品の検索”

この要件をテストするには、「簡単で使いやすい」や「在庫商品」といった曖昧な表現が何を意味するのか推測する必要があります。要件をよりテスト可能なものにするには、「高速」や「直感的」、「ユーザーフレンドリー」といった”曖昧な表現が何を意味するのかを明確に“すべきです。

また、要件には「検索ボックスは画面の右上に配置される」といった仕様の詳細を含むべきではありません。要件は”測定可能“であるべきです。次のWebショッピングアプリケーションの次の例で考えてみましょう。

“一致する商品が少なくとも1件あった場合、最大で20件までの在庫商品を、ユーザーの環境設定に従ったソート順序で、グリッドまたはリスト表示する”

この要件は、境界ケースのテストの作成に結びつく情報を提供します。

たとえば「一致する商品なし」「1または 2 件の一致」「19、20、および 21 件の一致」などです。しかし、この要件は複数の機能を表しています。以下のように、3つの要件に分割する方が良いでしょう。

少なくとも1件の一致する商品があった場合、最大で 20 件まで在庫商品を表示する
ユーザーの環境設定に従って、検索結果をグリッドまたはリストで表示する
ユーザーの環境設定に従ったソート順序で検索結果を表示する

“１つの要件に対して1つ機能“の原則は、よりアジャイルな開発を可能にします。理論的には、ある開発サイクルの中で検索機能をリリースし、次の開発サイクルでグリッド表示/リスト表示またはソート順序を選択できる機能を追加する、ということが可能です。

テスト可能な要件に以下を含めるべきではありません：

無関係な文章。単語の数で本の良し悪しを判断できないように、要件定義の文章が長いからといってテスト可能な要件になるわけではありません。要件の理解に貢献しない文章は削除しましょう。
問題を解決する機能ではなく、問題についての説明。
実装の詳細。フォントサイズ、色、配置といった実装の詳細については、個々の要件単位で基準を設けるのではなく、プロジェクト全体での基準を考えましょう。
曖昧さ。仕様は具体的であるべきです。たとえば、「通常」などの測定できない主観的な用語は避けましょう。この場合は「80%」のような、客観的で測定可能な用語に置き換えましょう。

要件定義の手法

要件を記述するには、「従来の要件文書」から、「ユーザーストーリー、テスト駆動開発 (TDD)、受け入れテスト駆動開発 (ATDD)、振る舞い駆動開発 (BDD) といったアジャイル手法」まで、様々な手法があります。これらの手法には、テスト可能な要件の原則を適用するメリットがあります。

ユーザーストーリー

ユーザーストーリーは、目的として記述される要件です。技術用語を避け、エンドユーザーに分かりやすい言語を使って記述します。ユーザーストーリーは簡潔であり、主に次のような書式で作成されます。

＜役割＞として・＜機能＞が欲しい/必要だ・それは＜目的＞のためである

たとえば：

商品を検索する顧客として・リストまたはグリッドを選択して商品の一覧を表示したい・それは商品の比較を可能にするためである

ユーザーストーリーとして要件を記述することは、ユーザーあるいは顧客に焦点を当てます。ユーザーストーリーとして表現された要件は、それ自体では、テスト可能であるために十分な情報を持ちません。

ユーザーストーリーには受け入れ条件を含めるべきです。受け入れ条件を含めることで、開発チームはストーリーが「完了」であるかどうか知ることができます。
ユーザーストーリーの詳細については Agile Alliance のWebサイトを参照してください。

テスト駆動開発 (TDD)

TDDでは、要件は単体テストとして作成されます。単体テストはコーディングの前に実行され、失敗するはずです。なぜなら、単体テストが表現するコードがまだ存在しないからです。次に、テストケースを成功させるために、コードが作成またはリファクタリングされます。そして成功することを確認するために単体テストが再び実行され、必要があればリファクタリングが実施されます。

この手法は開発者テストと呼ばれることもあります。この理由は、このテストは開発者によって実施されること、および開発サイクルでテストが実施されるためです。しかし、TDD では開発者だけではなく、テスターが重要な役割を果たします。

テスターは、より良い単体テストを作成するために、開発者と連携し、境界値分析、同値分割、リスク分析といった手法を使用することができます。また、必要な統合テストとワークフローテストを確実に実施することを促します。

TDDテストは、一般的に、JUnitやVBUnitといったツールで作成され、アプリケーションの文書化の重要な部分を担います。TDD の詳細については Agile Alliance のWebサイトを参照してください。

受け入れテスト駆動開発 (ATDD)

ATDD では、ユーザーストーリーとそれに付随する受け入れ条件が、アプリケーションが意図したとおりに動作することを顧客に証明するためのテストになります。

通常、受け入れテストは「スリーアミーゴス (3 人の友人)」と呼ばれる 3 人体制のチームによって作成されます。このチームはユーザー、開発者、およびテスターの観点を持つメンバーから構成されます。チーム全員が理解できるテストにするために、受け入れ条件は、技術用語ではなく「事業領域」における用語で記述されます。

ATDDのワークフローはTDDに似ています。まず、ユーザーストーリーが作成され、その後に受け入れテストが作成されます。次に、ユーザーストーリーが実装され、それが成功することを確認するために受け入れテストが繰り返し実行されます。最後に、必要なリファクタリングが実施されます。TDDとATDDを同時に実施することは可能です。

良い受け入れテストを作成するための推奨事項については、Jeff Langr による記事（The ABCs of Acceptance Test Design）を参照してください。

振る舞い駆動開発 (BDD)

要件を明確にするための方法のひとつは、抽象的な用語を使わずに、現実的な例で要件を記述することです。この手法は、実例による仕様書 (SBE（specification by example）)または、振る舞い駆動開発 (BDD)と呼ばれます。BDDはATDDに似ていますが、Gherkinという特別な構文を使用します。BDDでは、ユーザーストーリーは「シナリオ」を作成するために実例で補完されます。機能のシナリオは、実行可能な仕様書として機能ファイルにまとめて格納されます。

BDD のシナリオは、以下の例で示すように、GIVEN-WHEN-THEN (前提-条件-結果) という構文を使って記述します。

機能: 検索結果の表示
商品を検索している顧客として、
商品の一覧をリストまたはグリッドで表示する選択肢が欲しい。
そうすることで、商品を比較することができます。

シナリオ 1
Given：在庫商品を検索する
And：検索に、少なくとも 2 つの商品がヒットする
When：環境設定ではリスト表示を指定している
Then：検索結果が返す在庫商品の一覧がリスト表示される

シナリオ 2
Given：在庫商品を検索する
And：検索に、少なくとも 2 つの商品がヒットする
When：環境設定ではグリッド表示を指定している
Then：検索結果が返す在庫商品の一覧がグリッドで表示される

シナリオ 3
Given：在庫商品を検索する
And：検索にヒットする商品がない
When：環境設定ではリスト表示を指定している
Then：代わりのおすすめ商品の一覧が表示される

テスト可能な要件のためのツール

テスト可能な要件を作成するために、特別なツールは必要ありません。
ワープロやメモ帳で文書化することができます。しかし、ツールを使用することで、作成プロセスを効率化できます。

ATDDのテストでは、FitNesseなどのツールを使ってキャプチャーして自動化できます。BDDでは、GherkinのGIVEN-WHEN-THEN構文で要件を記述して自動化の準備ができる以下の言語固有のツールがあります。

Ruby：Cucumber
Java：Jbehave
C#：SpecFlow
JavaScript：Jasmine

※Ranorex Studioと、オープンAPIは、TDD、ATTD、BDDを含め、あらゆるテスト手法をサポートします。Ranorex StudioをSpecFlowと統合して BDDシナリオを自動化する方法については、Ranorex Blogの記事（How to Use Ranorex Studio in Your BDD Process）を参照してください。