例による仕様

例示による仕様記述（SBE）は、抽象的な記述ではなく現実的な例を使用して要件を捉え、説明することに基づいて、ソフトウェア製品の要件とビジネス指向の機能テストを定義するための共同アプローチです。これは、アジャイルソフトウェア開発手法、特に動作駆動開発のコンテキストで適用されます。このアプローチは、ドメインと組織の複雑さが非常に大きい大規模プロジェクトの要件と機能テストの管理に特に効果的です。^[1]

例による仕様記述は、例駆動開発、実行可能要件、受け入れテスト駆動開発（ATDD ^[2]またはA-TDD ^[3]）、アジャイル受け入れテスト、^[4]テスト駆動要件（TDR）としても知られています。

利点

非常に抽象的または斬新な新しい概念は、具体的な例がなければ理解するのが難しい場合があります。^[要出典]例による仕様は正確な理解を構築することを目的としており、ソフトウェア開発におけるフィードバックループを大幅に削減します。これにより、やり直しが減り、製品の品質が向上し、ソフトウェア変更のターンアラウンドタイムが短縮され、テスター、アナリスト、開発者など、ソフトウェア開発に関与するさまざまな役割の活動の調整が改善されます。^[1]

真実の唯一の情報源としての例

例示による仕様の重要な側面は、あらゆる観点から必要な変更に関する唯一の真実のソースを作成することです。ビジネスアナリストが独自のドキュメントで作業し、ソフトウェア開発者が独自のドキュメントを維持し、テスターが別の機能テストセットを維持する場合、さまざまな真実のバージョンを常に調整して同期する必要があるため、ソフトウェア配信の有効性が大幅に低下します。短い反復サイクルでは、このような調整は毎週または隔週で必要になることがよくあります。例示による仕様では、さまざまな役割が参加して、全員の理解をキャプチャする唯一の真実のソースを作成します。例は、明快さと正確さを提供するために使用され、同じ情報を仕様とビジネス指向の機能テストの両方で使用できます。機能ギャップの明確化、不足または不完全な要件、追加のテストなど、開発または配信中に発見された追加情報は、この唯一の真実のソースに追加されます。機能に関する真実のソースは 1 つだけなので、配信サイクル内での知識の調整、翻訳、解釈は必要ありません。

要求された変更に適用された場合、洗練された一連の例は事実上仕様であり、ソフトウェア機能の受け入れに関するビジネス指向のテストです。変更が実装された後、例を含む仕様は既存の機能を説明するドキュメントになります。このようなドキュメントの検証は自動化されているため、頻繁に検証されると、このようなドキュメントは基盤となるソフトウェアのビジネス機能に関する信頼できる情報源になります。このようなドキュメントとすぐに古くなる一般的な印刷されたドキュメントを区別するために、^[4]例を含む完全な仕様セットは Living Documentation と呼ばれます。^[1]

主な実践

例示による仕様適用を成功させるチームは、一般的に以下のプロセスパターンを適用します。^[1]

目標から範囲を導き出す
共同で仕様を策定 - チーム全員による仕様策定ワークショップ、小規模な会議、電話会議によるレビューなどを通じて
例を使用して要件を説明する
精製仕様
例に基づいてテストを自動化する
テストを使用して基盤となるソフトウェアを頻繁に検証する
将来の開発をサポートするために、例を含む仕様からドキュメントシステムを進化させる

スクラムフレームワーク内で例による仕様を適用するソフトウェアチームは、通常、共同での仕様指定、例を使用した要件の説明、例の改良など、製品バックログの改良に5％～10％の時間を費やします。^[3]

マッピング例

事例マッピングは、会話を誘導し、短時間で受け入れ基準を導き出すことができるシンプルな手法です。このプロセスでは、ストーリーをルールと事例に分割し、事例による仕様の形式で文書化します。これは、BDDの分野で広く使用されている手法です。^[5]

適用範囲

例示による仕様は、ビジネスドメインの観点から要件を理解したり伝えたりする際に問題を引き起こすほど組織的およびドメイン的に複雑なプロジェクトに適用されます。純粋に技術的な問題や、主要な複雑さが知識の理解や伝達にない場合には適用されません。このアプローチは、投資銀行、金融取引、保険、航空券予約、オンラインゲーム、価格比較などの分野で文書化されています。^[1]同様のアプローチは、原子力発電所のシミュレーションプロジェクトでも文書化されています。^[3]

共有された例に基づくテストは、ビジネスの観点からソフトウェアを提供しながらチームをサポートするように設計されたテストのカテゴリに最も適しています（アジャイルテストクアドラント^[6]を参照）。つまり、適切な製品が構築されていることを保証します。これらは、純粋に技術的な観点からソフトウェアシステムを見るテスト（単体テスト、コンポーネントテスト、または技術統合テストなど、製品が適切に構築されているかどうかを評価するテスト）や、開発後の製品を評価するテスト（セキュリティ侵入テストなど）に代わるものではありません。

歴史

ソフトウェアプロジェクトにおいて、要件と自動テストの唯一の真実の源として現実的な例が使用された最も古い文書は、 1996年にWard Cunninghamが論文「競争的開発のパターン言語」^[7]^[8]で説明したWyCash+プロジェクトです。Specification by Exampleという名前は、2004年にMartin Fowlerによって造られました。 ^[9]

例示による仕様記述は、 1997年頃に提案されたエクストリームプログラミングの顧客テスト^[10]の実践と、2004年のドメイン駆動設計からのユビキタス言語^{[11]の考え方が発展したもので、1989年にWeinbergとGause}^[12]によって記述された要件としてのブラックボックステストの考え方を使用しています。

オートメーション

大規模プロジェクトで例による仕様をうまく適用するには、大量の例 (テスト) に対してソフトウェアの機能を頻繁に検証する必要があります。実際には、例に基づくテストを自動化する必要があります。一般的なアプローチは、テストを自動化しながら、例を技術系および非技術系のチームメンバーが読み取りおよびアクセスできる形式に保ち、例を唯一の真実のソースとして保持することです。このプロセスは、仕様と自動化レイヤーの 2 つの側面に分割されたテストを処理するテスト自動化ツールのクラスによってサポートされています。テストの仕様は、多くの場合、プレーンテキストまたは HTML 形式で、例と補助的な説明が含まれています。自動化レイヤーは、例をテスト対象のソフトウェアシステムに接続します。このようなツールの例を次に示します。

参考文献

^ abcde Adzic, Gojko (2011).例による仕様: 成功するチームが適切なソフトウェアを提供する方法。Manning. ISBN 9781617290084。
^ Pugh, Ken (2011).リーンアジャイル受け入れテスト駆動開発: コラボレーションによるソフトウェアの改善: リーンアジャイル受け入れテスト駆動開発の物語。Addison Wesley。ISBN 978-0-321-71408-4。
^ abc ラーマン、クレイグ; ヴォッデ、バス (2010)。リーンおよびアジャイル開発のスケーリングの実践: 大規模スクラムによる大規模、マルチサイト、オフショア製品開発。ピアソン。ISBN 978-0-321-63640-9。
^ ab Adzic, Gojko (2009).コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト. Neuri. ISBN 0-9556836-1-0。
^ Wynne, Matt (2015 年 12 月 8 日). 「例のマッピングの紹介」. Cucumber ブログ. 2021 年5 月 10 日閲覧。
^ クリスピン、リサ、グレゴリー、ジャネット (2008)。アジャイルテスト：テスターとアジャイルチームのための実践ガイド。アディソン・ウェスリー。ISBN 978-0-321-53446-0。
^ プログラム設計のパターン言語 2 . Addison-Wesley. 1996. ISBN 978-0-201-89527-8。
^ Ward Cunningham. 「EPISODES: 競争力開発のパターン言語パート I」 C2.com 。 2014 年 1 月 8 日閲覧。
^ Martin Fowler 2004 年 3 月 18 日 (2004-03-18)。「SpecificationByExample」。Martinfowler.com。2014年 1 月 8 日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)
^ Beck, K. (1999). 『エクストリームプログラミングの解説：変化を受け入れる』Addison-Wesley. ISBN 978-0-321-27865-4。
^ エヴァンス、エリック (2004)。ドメイン駆動設計: ソフトウェアの核となる複雑性への取り組み。Addison -Wesley。ISBN 0-321-12521-5。
^ ワインバーグ、ジェラルド、ガウス、ドナルド（1989）。要求の探求：設計より品質を優先。ドーセットハウス。ISBN 0-932633-13-7。

外部リンク

Google ディスカッショングループ
Specificationbyexample.com の書籍、ビデオ、ツール、プレゼンテーション
マーティン・ファウラーのブリキの定義

[Adzic11-1] Adzic, Gojko (2011).例による仕様: 成功するチームが適切なソフトウェアを提供する方法。Manning. ISBN 9781617290084。

[Pugh11-2] Pugh, Ken (2011).リーンアジャイル受け入れテスト駆動開発: コラボレーションによるソフトウェアの改善: リーンアジャイル受け入れテスト駆動開発の物語。Addison Wesley。ISBN 978-0-321-71408-4。

[Larman10-3] ラーマン、クレイグ; ヴォッデ、バス (2010)。リーンおよびアジャイル開発のスケーリングの実践: 大規模スクラムによる大規模、マルチサイト、オフショア製品開発。ピアソン。ISBN 978-0-321-63640-9。

[Adzic09-4] Adzic, Gojko (2009).コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト. Neuri. ISBN 0-9556836-1-0。

[ccblog-wynne-5] Wynne, Matt (2015 年 12 月 8 日). 「例のマッピングの紹介」. Cucumber ブログ. 2021 年5 月 10 日閲覧。

[6] クリスピン、リサ、グレゴリー、ジャネット (2008)。アジャイルテスト：テスターとアジャイルチームのための実践ガイド。アディソン・ウェスリー。ISBN 978-0-321-53446-0。

[Cunningham06-7] プログラム設計のパターン言語 2 . Addison-Wesley. 1996. ISBN 978-0-201-89527-8。

[Cunningham06-2-8] Ward Cunningham. 「EPISODES: 競争力開発のパターン言語パート I」 C2.com 。 2014 年 1 月 8 日閲覧。

[9] Martin Fowler 2004 年 3 月 18 日 (2004-03-18)。「SpecificationByExample」。Martinfowler.com。2014年 1 月 8 日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)

[Beck99-10] Beck, K. (1999). 『エクストリームプログラミングの解説：変化を受け入れる』Addison-Wesley. ISBN 978-0-321-27865-4。

[Evans04-11] エヴァンス、エリック (2004)。ドメイン駆動設計: ソフトウェアの核となる複雑性への取り組み。Addison -Wesley。ISBN 0-321-12521-5。

[Weinberg89-12] ワインバーグ、ジェラルド、ガウス、ドナルド（1989）。要求の探求：設計より品質を優先。ドーセットハウス。ISBN 0-932633-13-7。