「The BDD Books - Discovery (Japanese Edition)」を読んだ感想

The BDD Books - Discovery (Japanese Edition)を読んだので、その学んだことと感想を書きます。

なぜ読んだか

BDD(振る舞い駆動開発)、ATDD(受け入れテスト駆動開発)という単語は知っていたが、中身を全く知らなかったため学びたかった。
強いて知っていることと言えば、BDDはGiven/When/Then を使ってCucumberのようなツールを動かす、くらいでした。

学んだこと

BDDとは

• BDDとATDDと実例による仕様は、同じものに対して名前が違うもの
• 開発担当者だけでなくビジネス担当者も読めるもの
• 具体例で構築され、十分な具体例＝システムの振る舞いとなる
  • 具体例はビジネス言語で表現され、具体例に注目するとルールの意図が明確になる
• 目標
  • 要件分析と詳細仕様の間に導入し、本番環境での問題を防ぐこと
  • ビジネスチームとの早期の直接的なコミュニケーションに焦点を当て、誤解を減らし、やり直しを減らすことで、コミュニケーションの効率を向上させること
• 使用することのメリット
  • やり直し/受け入れ拒否の削減
  • バグの削減、ビジネス側が求めていることへの理解促進
• プラクティス
  1. 発見
     • この本では発見のプラクティスを中心に解説されている
  2. . 定式化
  3. . 自動化

具体例について

• 十分な具体例(システムの振る舞い)は「コンテキスト」、「アクション」、「結果」で構成される
• 具体例は"明確"で具体的なデータを使用する必要がある
• 全ての情報を指定すると非常に長くて退屈になるので、具体例は振る舞いに直接関連する具体的なデータを使用する
• 複数のルールを表す具体例を書いているとき
  • 1つのルールに対しての具体例であって、他のルールに焦点をあてない
• 具体例は「すでに知っていることを説明するため」と「仮定に疑問を投げかけるため」の両方に使用される

要件ワークショップ

• 目的
  • 明確な具体例を用いて要件をすばやく調査し、求められている内容を全員が正確に理解すること
  • 詳細レベルを得ることではない
• 要件ワークショップで具体例を集める
• Given/When/Then を使用しないで書くべき

その他

• アジャイルテストの基本コンセプト
  • アプリケーションの問題を見つけて報告することから、そもそも問題をコードに含めないようにすること
    • シフトレフトの考え方に近いかも？
• ハッピーパス＝正常系の中でも特に大事なもの
• テスターは、通常、要件と解決策の間の仲介役として機能するため

感想

BDDは名前しか知らず内容を知らなかったので、今回BDDが何であるかを知れたのは非常に有益でした。協調という点で、良いものを作るために様々な役割の視点から具体例を使用してイメージをしていくことの重要性を学べました。
実例マッピングのやり方についての具体的な例があるのはイメージしやすかった部分なので良かったです。
一方で、アジャイルは机上でしか理解してないので、スクラムにおけるBDDと,リーンカンバンにおけるBDDの話はあまり理解できず...ここら辺はアジャイルを経験したらまた読み直したい部分です。
そういえば、Given/When/Thenに関することはあまり触れていなかった気がします。定式化についてはこの本の対象外なので、おそらく定式化で使うのかなーと思っています。

あとは、ドメイン駆動設計の話も少し出てきたので、いずれそれも学びたいです。
これからも色々と学んでいきます！