先日、友人の風間さんが『The BDD Books - Discovery』の日本語翻訳版を出版されました。

参照
　BDD/ATDDを学ぶ上で最適な書籍『The BDD Books - Discovery』を翻訳して出版しました！ #bddbooks - ブロッコリーのブログ

ありがたいことに推薦文を書く機会を頂いたので、出版より一足先に読ませていただきました。

私の推薦文は以下のように書いてます。

BDDについてなんとなく知っている、という方は必読です。 一段階深い理解と納得が得られるはずです。私がそうでした。 ビジネスと開発の協調について本書を読み、考え、そして実践することで、日々のソフトウェア開発をより良くできると思います。

推薦文には文字数の目安があったのでかなりさらっと書いてますが、もっと感想を言いたいのでこの記事を書いている次第です。

本はこちらから買えます。

BDD Books - Discovery… Gáspár Nagy 著 et al. [PDF/iPad/Kindle]

（関係ないけど、LeanPubだと円安の影響を受けますねー

本書の概要

まずこの本に何が書いてあるのか、ですが、

  • BDDを学ぶ上でありがちな間違いを避ける
    • 本書では”BDDの学習期間を楽に過ごせるようにする”と書かれている
  • そもそもBDDとは何なのか
    • ATDD, Specification By Exampleと何が違うの？
  • BDDをビジネスチームとデリバリチームの架け橋として活かすために何をすべきか

などが書かれています。

大事なポイントは「架け橋」のところで、ここを「BDDを雰囲気でしかしらない」人は誤解している、と思います。 （というか私が本書を読むまでわかってませんでした）

一応公式の「本書について」も引用。

本書籍は、振る舞い駆動開発(Behavior Driven Development, BDD)や受け入れテスト駆動開発(Acceptance Test-Driven Development, ATDD)の発見フェーズを最大限に活用する方法を提供します。 書籍内では、優れたコラボレーション手法を具体例で示しており、実用的なガイドとなっています。 本書籍は、SpecFlowの作成者と書籍『The Cucumber for Java Book』の著者によって書かれました。

本書籍は、プロダクトオーナー、ビジネスアナリスト、開発者、テスターなど、ソフトウェアの仕様とデリバリーに携わるすべての人を対象としています。 本書籍では、なぜBDDが誕生した理由の説明から始まり、ビジネスチームとデリバリーチームのメンバー間のコラボレーションを最大限に活用するためのテクニックを説明します。

これは、協調して作成した仕様と生きたドキュメントを活用して開発を成功させるために必要な特定の技術的なプラクティスを含む、開発プロセス全体をガイドするBDD Booksシリーズの1冊目です。

BDDとは何か、を知る

BDD、という単語を聞いたときに私が思い浮かべていたのは、Cucumberとか、ちょっと違うけどGaugeとか、そういったものでした。恥ずかしながらツールが先に出てきていた状態、ということです。

本書の冒頭で、明確に否定されています。

典型的な間違いの 1 つは、BDD をツールとして見ることです。 BDD は、主に協調と ドメインの発見に関するものです。 「BDD ツール」は、このプロセスをサポートする場 合にのみ役立ちます。

ツールではなく何なのか、は本書の前半に書かれていますが、私は

  • 要件とソフトウェアの間の架け橋

と捉えました。上ではこれを「ビジネスチームとデリバリチームの架け橋」と表現しましたが、同じ意味です。

つまり、ビジネスチームが考えていること≒要件と、デリバリチームが作るもの≒ソフトウェアを紐づける架け橋としてBDDで言う振る舞い（シナリオ、具体例、etc）が存在する、ということです。

関連して、非常に腹落ちというか「それだ！」と思った文章が以下。

Dan North はこの問題に気づき、要件との関係を維持するためにテストメソッドに名前を付けて構造化するためのいくつかの実用的なルールを提案しました。 彼はまた、テストが期待した振る舞いを示しているかどうかを確認する最も簡単な方法は、ビジネス担当者にそれらを示すことであると説明しました。 しかし、ビジネス担当者がソースコードを読むことはめったにないため、テスト結果を読みやすくなるようにいくつかの簡単な変換を実行する小さなツールを開発しました。 Dan はこの概念を振る舞い駆動開発（BDD）と呼び、「テスト」という言葉を意図的に削除しました。 なぜならば、ビジネス担当者がプロセス全体を通して参加し続けることを促進したいためです。

※強調は本記事筆者（伊藤）

「CucumberとかGaugeみたいなやつでしょ？」という浅いレベルでBDDを捉えていた頃の自分は、まさにBDDをツールとして、もっというとシステムテストやE2Eテストの仲間であるツールとして考えていました。かつ、暗黙にそう捉えていて、自覚的ですらありませんでした。

ところが言われてみるとBDDは「開発」であり「テスト」とは表現されていない。この理由を（恥ずかしながら）知って、自分としてはグッと本書に掴まれました。

BDDへの入り方

本書によると、私のようにBDDをテスト的ななにかと捉える人は少なくないようで、以下のように書かれています。

多くの開発チームは、テスト自動化を改善したいという願望から BDD にやって来ます。 テスト自動化の改善は、BDD のアプローチに従うことの重要な成果の 1 つですが、それは下流の成果です。説明している順序（発見、定式化、自動化の順）でプラクティスを採用しない限り、期待されるメリットは得られません。

例えばキーワード駆動テストなんかは、テスト自動化の改善を狙って導入してもいまひとつ効果が出づらいものの一つだと思います。

おそらくBDDも、同じような狙いで始めると成果（と自分たちが思いたいもの）が出ないことがほとんどではないかと。これは過去の自分の経験としても、実感があります。

それが上の引用箇所で答えを示された形でした。

まさに、なことを本書を読む前の自分がTweetしてました・・・。

そもそも「ビジネスとデリバリの架け橋」であるBDDを「システムテストの自動化をなんとかしたい」、もっというと「コードかけない人でも自動化してコスト削減だ」というつもりで扱ったとしたら・・・うまくいかなくて当然ですね。

似た箇所として、以下も引用しておきます。

BDD の活動の中でテストが行われているのは確かです。 しかし、その目的は、開発が正しい方向に進んでいることを関係者全員に保証することであり、正しいコードが記述されていることを徹底的に確認することではありません。 これは、開発者とテスターの専門的なプラクティスによってまだカバーされています。開発者は自動のプログラマーテストを作成し、テスターはスクリプト化したテストと探索的テストを使用して解決策を検証します。

QAも、テスト自動化エンジニアも、POもPMも読んでほしい

実はここまで書いてきた感想でカバーしているのが「第１章　BDDとは何ですか？」までという、感想長すぎて書籍のほう読んでもらったほうが速くて確実では・・・という状態になってきたので、私の感想はここで止めておきます。

２章以降は

  • 第２章　構造化された会話
  • 第３章　具体例とは何ですか？
  • 第４章　誰がいつ何をするか
  • 第５章　ビジネスチームのメンバーを参加させる方法

と続いていきます。

このThe BDD Books - Discoveryは３部作のうち１冊目で、具体的なBDDのテストの書き方はこの後の本で出てくるそうです。

１冊目としての本書はBDDの考え方から、実際行うにあたってビジネスサイドの巻き込み方まで書かれていて、これだけでも非常に充実。

全体通じて「架け橋」あるいは「協調」というのが大事なキーワードになっていて、要はひとつのロールだけが小手先の改善のためにBDDを始めるのでは本領発揮できない、ということだと理解しました。

本書はとにかくQA、開発、それからプロダクトオーナーやプロジェクトマネージャや、開発にかかわるみんなで読めるとよさそう。きっと輪読とか向いてると思います。

BDDのことを日本語で読める本ほぼ無いのでは・・・と思うので、貴重です。