BDD-例による仕様

「SpecificationbyExample」の著者であるGojkoAdzicによると、Specification by Exampleは、ソフトウェア製品の変更を容易にして、適切な製品が効率的に提供されるようにする一連のプロセスパターンです。」

例による仕様は、抽象的なステートメントの代わりに現実的な例を使用して要件をキャプチャして説明することに基づいて、ソフトウェア製品の要件とビジネス指向の機能テストを定義するための共同アプローチです。

例による仕様–概要

例による仕様の目的は、優先順位が付けられ、検証可能なビジネス要件の開発と提供に焦点を当てることです。例による仕様の概念自体は比較的新しいものですが、それは単に既存の慣行を言い換えたものです。

ユビキタス言語として知られる非常に具体的で簡潔な語彙をサポートします。

実行可能要件を有効にします。
チームの全員が使用します。
部門の枠を超えたチームによって作成されます。
みんなの理解を捉えます。

例による仕様は、ビジネスドメインを反映する自動テストを構築するための直接入力として使用できます。したがって、Example by Exampleの焦点は、適切な製品の構築と製品の適切な構築にあります。

例による指定の目的

例による仕様の主な目的は、適切な製品を構築することです。理解の共有に焦点を当てているため、信頼できる唯一の情報源が確立されます。受け入れ基準の自動化が可能になるため、欠陥の検出ではなく欠陥の防止に重点を置くことができます。また、欠陥を早期に発見するための早期テストを促進します。

SbEの使用

例による仕様は、ビジネス価値を説明する予想されるシステム動作を説明するために使用されます。この図は、具体的で実際の例によるものです。これらの例は、次のような実行可能要件を作成するために使用されます。

翻訳なしでテスト可能。
ライブドキュメントにキャプチャされます。

以下は、特定の仕様を説明するために例を使用する理由です。

それらは理解しやすいです。
彼らは誤解しにくいです。

SbEの利点

例による仕様を使用する利点は次のとおりです。

品質の向上
無駄の削減
生産欠陥のリスクの低減
集中的な取り組み
より安全に変更を加えることができます
ビジネスへの関与の改善

SbEのアプリケーション

例による仕様は、-でアプリケーションを検索します

複雑なビジネスまたは複雑な組織。
純粋に技術的な問題にはうまく機能しません。
UIに焦点を当てたソフトウェア製品ではうまく機能しません。
レガシーシステムにも適用できます。

SbEと受け入れテスト

受け入れテストに関する例による仕様の利点は次のとおりです。

詳細な要件とテストの両方に1つの図が使用されます
プロジェクトの進捗状況は、受け入れテストの観点からです-
- 各テストは、動作をテストすることです。
- テストは動作に合格しているか、合格していないかのどちらかです。
- 合格テストは、特定の動作が完了したことを表します。
- 100のビヘイビアを完了する必要があるプロジェクトで60のビヘイビアが完了した場合、60％完了します。
テスターは欠陥修正から欠陥防止に切り替え、ソリューションの設計に貢献します。
自動化により、要件の変更がソリューションに与える影響を即座に理解できます。

例による仕様–さまざまな役割の意味

例による仕様の目的は、プロジェクト全体を通じて顧客を含むチームの全員のコラボレーションを促進し、ビジネス価値を提供することです。理解を深めるために、誰もが同じ語彙を使用します。

役割	SbEの使用
ビジネスアナリスト	要件は明確で、機能的なギャップはありません。開発者は、実際に仕様を読んでください。
開発者	開発者は、何が開発されているかをよりよく理解します。正しく開発された仕様を数えることにより、開発の進捗状況がより適切に追跡されます。
テスター	テスターは、何がテストされているかをよりよく理解します。テスターは最初から関与し、設計に関与します。テスターは、欠陥の検出ではなく、欠陥の防止に取り組みます。
全員	エラーを最初から特定することで時間を節約できます。高品質の製品は最初から製造されています。

SbE –一連のプロセスパターン

この章の冒頭で見たように、「例による仕様」は、適切な製品が効率的に提供されるようにソフトウェア製品の変更を容易にする一連のプロセスパターンとして定義されています。

プロセスパターンは次のとおりです。

共同仕様
例を使用した仕様の説明
仕様の改良
自動化の例
頻繁に検証する
生きている文書

共同仕様

共同仕様の目的は次のとおりです。

チーム内のさまざまな役割を取得して、共通の理解と語彙の共有を実現します。
全員をプロジェクトに参加させて、機能に関するさまざまな視点を提供できるようにします。
機能の共有コミュニケーションと所有権を確保します。

これらの目的は、ThreeAmigosミーティングとしても知られる仕様ワークショップで達成されます。Three Amigosは、BA、QA、および開発者です。プロジェクトには他の役割もありますが、これら3つは、定義から機能の提供まで責任と説明責任を負います。

During the meeting −

ビジネスアナリスト（BA）は、新機能の要件とテストを提示します。
3つのAmigos（BA、Developer、およびQA）が新機能について話し合い、仕様を確認します。
QAと開発者は、不足している要件も特定します。
3つのアミーゴ
- ユビキタス言語を使用した共有モデルを利用します。
- ドメイン語彙を使用します（必要に応じて用語集が維持されます）。
- 違いや矛盾を探します。
この時点では、実装の詳細にジャンプしないでください。
機能が十分に指定されているかどうかについてコンセンサスを得る。
要件とテストの所有権を共有することで、品質仕様が容易になります
要件はシナリオとして提示され、明示的で明確な要件を提供します。シナリオは、ユーザーの観点から見たシステムの動作の例です。

例を使用した仕様の説明

シナリオは、Given-When-Then構造を使用して指定され、テスト可能な仕様を作成します-

Given <いくつかの前提条件>

And <追加の前提条件> Optional

When <アクション/トリガーが発生します>

Then <いくつかの事後条件>

And <追加の投稿条件> Optional

この仕様は、システムの動作の一例です。また、システムの受け入れ基準も表します。

チームは例について話し合い、例が機能の期待される動作をカバーすることに合意するまでフィードバックが組み込まれます。これにより、良好なテストカバレッジが保証されます。

仕様の改良

仕様を改良するには、

例を正確に書いてください。例が複雑になった場合は、より単純な例に分割してください。
ビジネスの観点に焦点を合わせ、技術的な詳細は避けてください。
正と負の両方の条件を考慮してください。
ドメイン固有の語彙に準拠します。
例についてお客様と話し合います。
- これを達成するために会話を選択してください。
- 顧客が関心を持っている例のみを検討してください。これにより、必要なコードのみを生成でき、不要な可能性のあるすべての組み合わせをカバーする必要がなくなります。
シナリオに合格するには、そのシナリオのすべてのテストケースに合格する必要があります。したがって、仕様を拡張してテスト可能にします。テストケースには、さまざまな範囲とデータ値（境界ケースとコーナーケース）、およびデータの変更をもたらすさまざまなビジネスルールを含めることができます。
複雑な計算、データ操作/変換などの追加のビジネスルールを指定します。
例による仕様として、機能しないシナリオ（パフォーマンス、負荷、使いやすさなど）を含める

例の自動化

自動化レイヤーは非常にシンプルに保つ必要があります。テスト対象のシステムに仕様を配線するだけです。あなたは同じためのツールを使用することができます。

ドメイン固有言語（DSL）を使用してテストの自動化を実行し、入力と出力の間の明確な接続を示します。スクリプトではなく、仕様に焦点を合わせます。テストが正確で、理解しやすく、テスト可能であることを確認してください。

頻繁に検証する

すべての変更（追加/変更）で、開発パイプラインに検証例を含めます。製品の品質を確保するために採用できる（そして採用すべき）多くの技術とツールがあります。それらは3つの主要な原則を中心に展開します-Test Early, Test Well そして Test Often。

弱いリンクを特定できるように、テストを頻繁に実行してください。動作を表す例は、進行状況の追跡に役立ち、動作は、対応するテストに合格した後にのみ完了すると言われています。

生きているドキュメンテーション

仕様はできるだけシンプルで短くしてください。仕様を整理し、作業が進むにつれてそれらを進化させます。チームの全員がドキュメントにアクセスできるようにします。

プロセスステップの例による仕様

この図は、「例による仕様」のプロセスステップを示しています。

アンチパターン

アンチパターンは、ソフトウェア開発における特定のパターンであり、悪いプログラミング手法と見なされます。一般的な問題への一般的なアプローチであり、形式化され、一般に優れた開発手法と見なされているデザインパターンとは対照的に、アンチパターンは反対であり、望ましくありません。

アンチパターンはさまざまな問題を引き起こします。

アンチパターン	問題
コラボレーションなし	多くの仮定間違ったものを作る間違ったことをテストするコードが終了したときに気付かない
コードが終了したときに気付かない	テストを維持するのは難しいスペックがわかりにくい事業担当者からの関心の喪失
詳細すぎる、またはUI中心の例	テストを維持するのは難しい仕様がわかりにくい事業担当者からの関心の喪失
必要な努力を過小評価する	チームは失敗したと思い、早い段階で失望します