読書メモ。2025年26冊目。
『The BDD Books - Formulation』を読んでの感想となります。（2025/4/5記載）
本の概要
本書籍は、振る舞い駆動開発(Behavior Driven Development, BDD)や受け入れテスト駆動開発(Acceptance Test-Driven Development, ATDD)の定式化フェーズを最大限に活用する方法を提供します。
発見フェーズで生成される具体例をビジネスチームが読みやすいGherkinシナリオ（BDDでよく知られている仕様構文）へと効果的に定式化する方法を読者に提供します。生きたドキュメントを作成するチームを追って、製品の機能追加を行うにあたり、(Given/When/Then を使用して) より良いシナリオを書くための実践と原則を示した実用的なガイドとなっています。
本書籍は、SpecFlowの作成者と書籍『The Cucumber for Java Book』の著者によって書かれました。
本書籍は、プロダクトオーナー、ビジネスアナリスト、開発者、テスターなど、ソフトウェアの仕様とデリバリーに携わるすべての人を対象としています。 この本では、すべての関係者が製品仕様の作成にどのように関与する必要があるかについて説明しています。どのように参加するかは、あなたのスキル、他の時間の約束、その他の多くの要因によって異なりますが、関係者全員の参加が不可欠です。したがって、言葉を考え出すときも、情報をインプットするときも、建設的なフィードバックを提供するときも、この本は欠かせないものであることがわかるでしょう。
これは、協調して作成した仕様と生きたドキュメントを活用して開発を成功させるために必要な特定の技術的なプラクティスを含む、開発プロセス全体をガイドするBDD Booksシリーズの2冊目です。
引用：
動機
- 『The BDD Books - Discovery』の内容が今の開発の課題と合っていたので、BDDをもっと学びたい。
- 今の開発で運用されているGivenWhenThenが本当に目的に適っているのか分かっていない。
- ドキュメンテーションに対する課題もあるため、定式化も学びたい。
感想
『The BDD Books - Discovery』に続き、プロダクトのステークホルダ全体で共通認識を持つ重要性を学びました。
用語を揃えることはちょうど今悩んでいることのひとつでもあり、プロダクトが成長するにつれてもともとの命名と用途がずれていくことに対処を悩んでいます。
ただ、当時言語を揃える重要性を想起できなかったことは確かなので、今後は揃えたい。
というと、先送りして機会を逃してしまうので、次の改修から揃える。いつかリファクタリングかけることも詰む。
定式化（Gherkin化）はそこそこ重たい印象を受けました。
E2E自動化も含めて考えると効果は抜群と思いますが、ドキュメントとしての用途だけで考えると、重荷になるとも思いました。
今Gherkinで表しているものは実例マッピングに移行し、E2E自動化に着手する際に定式化していくのが現実的なのかも知れない。
ただ、E2E自動化を後回しにしていくことが本当に良いのかも、成り行きではなく判断はしたい。
本当に必要であれば今からでも始めるべき。後回しにする理由があるとすれば、その理由が解消されたら始めることを考えたい。
総じて、戦略を持って計画を立てたい。その検討のためにも『Automation』も読みたい。
ひとまず実例マッピングは実開発で試すことになりました。わくわくしています。
忘れたくないメモ
■広範囲なドメイン知識を持つテスター
ドメイン知識を持つテスターの経験と視点は発見フェーズでは不可欠。
開発ライフサイクル全体で価値のある幅広い専門的なテスト手法が必要。
探索的テストにはテストとドメインに関する深い知識が必要。
■BDDとは
要件、ドキュメント、テストを結びつけ、コラボレーションを強調するソフトウェア開発アプローチ。
■定式化の主な目的
システムがどのように振る舞うべきかについての共通理解をビジネスチームが読みやすい仕様に変えるプロセス。
ビジネスチームとデリバリーチームの代表者からのインプットにより、ビジネスドメインに根付く用語を使用し、システムで期待される振る舞いについての共通理解を文書化する。
メンバーごとに違う用語を使うことにより、コラボレーション時の用語変換コストや、変換誤りによるエラーリスクを防止する。
定式化したシナリオは、システムの文書化の一部として検討すべき。
■ジャーニーシナリオ
ジャーニーシナリオが、必要ビジネス上のプロセスがどのように機能するかについての幅広いエンドツーエンドの視点を実現するために必要。
システムがどのような有用な成果をもたらすかを読者が確実に理解できるようになるために、ジャーニーシナリオは少しにすべき。
■定式化されたシナリオの2つの明確な利点
システムの振る舞いに関する共通理解を文書化できる。
システムが期待どおりに振る舞うことを自動的に確認できる。
■シナリオ
シナリオは、ドキュメントとして考えるべき。読みやすさが常に私たちの主な関心事。
システムの期待する振る舞いを説明し明確にするためにシナリオを作成する。
シナリオのステップには、特定のルールを説明する必要最低限の情報のみにすべき
不要な詳細は、説明したいルールとは関係のない情報で読者に負担をかけるため、理解しにくくなる。
網羅ではなく、説明的にすることを目標とする。
シナリオは、ビジネスチームとデリバリーチームのコラボレーションを可能にすべき。
システムの作成と進化に貢献するすべての人が理解できるように作成すべき。
シナリオは、製品の進化をサポートすべき。無関係な振る舞いが変更されたときに変更の必要がないようにする。
■BRIEFの原則
・ビジネス用語（Businesslanguage)
ソフトウェアシステムはビジネス価値を提供するため、
システム提供者全員ビジネス用語を理解しなければならないの。
・実際のデータ(Realdata)
実際の値や具体的な例は、開発プロセスの早い段階で境界条件と基礎となる仮定の明確化に役立つ。
シナリオ作成時、意図の明確化に役立つ場合は常に実際のデータを使用すべき。
・意図の明確化(Intentionrevealing)
シナリオ名を意図が明確なものにするから始め、次にシナリオのすべての行がメカニズムではなく意図を記述しているか確認すべき。
・必須(Essential)
シナリオの中で、どのように振る舞うべきか直接説明していない部分は削除すべき。
読者が期待している振る舞いについて理解を深めないシナリオは、ドキュメントに記載する意味がない。
・焦点を絞る(Focused)
ほとんどのシナリオは、単一のルールの説明に焦点を絞るべきです。
・簡潔にする(Brief)
ほとんどのシナリオは5ステップ以下に制限する。
■自然言語でシナリオを作成する目的
自然言語でシナリオを作成する主な目的は、すべての利害関係者がコラボレーションできる状態にすること。
そのため、すべての利害関係者が理解できるシナリオの作成に集中すべき。
シナリオが長いとレビューが難しくなり、レビュー担当者は不満になる。
ドメインの抽象化に焦点を絞り、シナリオを実装の詳細から切り離し、ユーザーインターフェイスや顧客のワークフローの変更に直面した場合の影響を軽減できる。
■ビジネス言語の使用
ビジネス言語について議論するプロセスには、用語を洗練し、今後のフィーチャーの要求についての議論が簡単になる利点がある。
■featureファイル
各featureファイルは、製品の機能のうちの1つに焦点を絞るべき。
フィーチャーが複雑になるにつれ、ドキュメントを複数のfeatureファイルに分けると便利。
■Gherkinの強み
Gherkinの強みの1つは、技術者以外のユーザーでも読みやすく、コンピューターで自動化できるドキュメントを作成できること。
■Givenステップ
システムがどのようにその状態になったのか経緯を説明するのではなく、システムの状態を宣言すべき。
■Whenステップ
有効化制約としてWhenステップを1つだけ含める。これにより、システムの詳細な振る舞いの検討と各振る舞いの前提の正確な特定が強いられる。
■Thenステップ
各シナリオは1つのルールのみを示すべき。結果（Then）ステップが1つしかないことを意味する。
■And、Or
「Or」接続詞が受け入れられる状況はない。非決定論を導入してしまうので、どんな犠牲を払ってでも避けるべき。
シナリオを2つに分割し、「Or」句の両方をカバーする。
「And」接続詞は使用が適切かどうかを慎重に検討すべき。
■発見セッション
発見セッションの目標は、システムがどのように意図して振る舞うかについて、チーム全体で共通理解を持つこと。
発見と定式化を組み合わせようとすると、物事が遅くなり、チームの関与が制限される。
■価値のデリバリー
デリバリーチームは要件のビジネスコンテキストを理解して、価値をデリバリーする。
シナリオ作成は、開発者とテスターがビジネス要件とビジネス用語の理解を確認するための理想的な方法。
■シナリオのレビュー
すべてのチームメンバーがシナリオをレビューする。
定式化は、ビジネスチームが読みやすい用語を使用し た共通理解の取り込みが目的。
シナリオがシステムの振る舞いの理解を明確に示していることに、チーム全体で同意する必要がある。
■ストーリー
ユーザーストーリーは要件ではない。
ストーリーのデリバリーが優先されるまで、詳細な要件分析を延期する方法。
ルールは要件であり、シナリオは、要件が実装された後のシステムに期待する振る舞い。
小さなストーリーがあると、必要な機能の段階的なデリバリーを計画、POの細かい粒度での優先順位付けに役立つ。
■featureファイル
一貫性のある機能ごとにfeatureファイルを整理すると、安定性とナビゲーション性の両方を示すドキュメントを提供できる。
すべてのストーリーごとにfeatureファイルを作成しようとすると、ドキュメントが使い物にならなくなる。
■ジャーニーシナリオ
ジャーニーシナリオは、事例的なシナリオと同じfeatureファイルに作成しない。
単一の振る舞いの適用を示しているのではなく、一部の利害関係者に価値のある結果をもたらす多数の振る舞いの相互作用を文書化している。
■発見と定式化
チームは発見フェーズに実例マッピングを使用してコードの振る舞いをリバースエンジニアリングする。
さらに、実例マッピングの明確な具体例から事例的なシナリオを定式化する。
このプロセスで見つけた知見は、現在開発者がコードに加えた変更がシステムを破壊していないことの確認と将来すべての利害関係者がシステムの現在の振る舞いを自信を持って判断できるようことに役立つ。
知識を取り戻して文書化するために発見と定式化を利用する。
レガシーコード全体に発見と定式化を適用するのではなく、リスクベースを用いた段階的な戦略を採用する。
