BDD/ATDDを学ぶ上で最適な書籍『The BDD Books - Discovery』を翻訳して出版しました! #bddbooks

2018年2月に出版された『The BDD Books - Discovery』日本語に翻訳してLeanpubにて出版しました!

表紙はこんな感じ。

書籍紹介および購入はこちらから。

leanpub.com

原著はLeanpubおよびAmazonにあります。

本書籍(翻訳版)は、今までと同様Leanpubを利用しています。

今までLeanpubを利用して出版した書籍はこちら。

nihonbuson.hatenadiary.jp

本記事では、この本がどんな内容なのかを書きます。

どんな想いで翻訳・出版に至ったか

想いについては、本書の訳者まえがきに書いた内容を一部抜粋して紹介します。

訳者まえがき

読者の皆さんは、「BDD」「振る舞い駆動開発」と聞いて、どんなことをイメージするでしょうか?

「Given/When/Then を用いた方法」というイメージを持つかもしれません。 テスト自動化やプログラミングを連想するかもしれません。結果として、本書籍の読者対象が開発者専用というイメージを持たれるかもしれません。

ただし、それは違います。 特に、3 冊ある「The BDD Books」シリーズの 1 冊目である本書籍は、開発者やテスターだけでなく、PO やビジネスチームの方々にも読んでいただきたい本です。

本書籍は、「business」という単語が非常に多く出てきます。 これは、単なるプログラミング手法としてではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、しきりに考えているためです。

(中略)

BDD やテスト自動化と聞くと、まずはどのように自動化のコードを書くのか考えがちです。本書籍ではそのような現状に対して警鐘を鳴らし、その前に考えるべきものを明確に示しています。 著者は、本書籍の範囲である「Discovery」の段階で、冒頭書いた「Given/When/Then」を使用することに拘ってはいけませんと言っています。(詳しく は第 2 章「構造化された会話」をご覧ください)

先ほど書いたように、本書籍は 3 冊ある「The BDD Books」シリーズの 1 冊目です。 本書籍は要件定義の段階の話が多く、コーディングの話は 3 冊目の『Automation』で多く語られると予想しています。しかし、1 冊目から読むことを著者は強く推奨しています。私も同じ意見です。なぜならば、仮に 3 冊目の「Automation」を読んで、自動化できたとしても、得られるメリットは非常に限定的だからです。

BDDやテスト自動化において、本書籍のような部分を説明している書籍に出会うことは非常に少ないです。特に、日本語で書かれている書籍で限定すると、ほとんど無いに等しいでしょう。なので、私は翻訳することにしました。

また、本書籍の第2章「構造化された会話」で、WIMPチームという具体的な事例を用いて説明している点が素晴らしいです!これは、「具体例を用いて説明することこそ重要である」というBDDで大切にしている考え方を、本書籍自身が体現しているといっても過言ではありません。

そのため、読者の皆さんも(開発者/テスター/PO/ビジネスチームのメンバーのどなたでも)、きっと楽しく読み進めることができるはずです。

(中略)

最後に、本書籍を読んで、BDDをしている方々やこれからBDDを始めようとしている方々のお役に立てば幸いです。

訳者まえがきの補足

BDDはビジネスを意識して考える必要がある

本書籍を読むと、BDDは単にGiven/When/Thenを用いているのではなく、特にビジネスを意識していることが分かると思います。

それは、いくら自動化したところで、本来のビジネス上の要求と合致しないものを作成してしまっては意味がない、それどころかリソースを無駄に使ってしまうからです。

そのために、BDDを3つのプロセスに分け、本書籍では特にビジネスを意識する部分に注目しています。

本書籍は「The BDD books」シリーズの1冊目であり、自動テストを書く前に行うべきことについて書いている

上述したように、 BDDで行う上で、ユーザーストーリーから動くソフトウェアができるまでの過程を、3つのプロセス「Discovery」「Formulation」「Automation」に分けて説明しています。

参照元:Behaviour-Driven Development

「The BDD books」シリーズでも、この3つのプロセスに当てはめて書かれています。

今回の『The BDD Books - Discovery』は1冊目として上記の画像の「Discovery(発見)」に焦点を絞って説明しています。

Agile, DevOps=自動化?

AgileやDevOpsというと、どうしても「自動化」がセットで語られることが多いです。

AgileやDevOpsでのテストの事例を探すと、すぐに「自動テスト」についての事例を見つけることができるでしょう。

「自動化」「自動テスト」は確かに重要です。しかし、AgileもDevOpsも自動化が全てではないはずですし、それ以外にも大切にしていることがあるはずです。

例えば、DevOpsDays Tokyo 2021にて、DevOpsDaysの創始者であるPatrickは下記のように語っていたようです。(kobaseさんのブログ記事より引用)

「DevOps=自動化」と結びつけられている時がある 元々の意図はそこではなかった

「DevOps Interview with Q&A」のメモ #DevOpsDaysTokyo 2021 - 名前考えるの苦手

本書籍も同様に、自動化だけでなく、それ以前に考えるべきことがあると教えてくれています。特に、SpecFlow(ATDD/BDD フレームワーク)の作成者かつメインコントリビュータと、『The Cucumber for Java Book』の著者が本書籍を書いていることが素晴らしいです。つまり、「もっと自動化ツールをどんどん使おうぜ!」と言いがちな立場の人たちが、「自動化ツールを使う以前に考えるべきことがあるだろ」と言ってくれているのです。

日本語書籍の少なさ

訳者まえがきで次のように書きました。

BDDやテスト自動化において、本書籍のような部分を説明している書籍に出会うことは非常に少ないです。特に、日本語で書かれている書籍で限定すると、ほとんど無いに等しいでしょう。

同じような感想を、今回の書籍のレビュアーにもなっていただいた @goyoki さんもツイートしています。

一方で、日本国内でもATDD(受け入れ駆動開発)の利用事例が増えていると感じています。

そこで、ATDD, BDD(振る舞い駆動開発), Specification by Example(SbE, 実例による仕様)といった分野についての本を翻訳しようと考え、数ある中から本書籍を選びました。

謝辞

本書籍の日本語翻訳版を公開するにあたり、今回も下記のたくさんの方々にサポートいただきました。本当にありがとうございました!

  • 浅黄友隆(@tom_asa)さん
  • 井芹洋輝さん
  • 末村拓也(@tsueeemura)さん
  • 東口和暉(@hgsgtk)さん
  • 根本紀之(@nemorine)さん
  • てらひで(@terahide27)さん
  • @koma_koma_dさん
  • 石田礼(@movrish)さん
  • 伊藤由貴(@yoshikiito)さん
  • きょん(@kyon_mm)さん
  • 山口鉄平(@teyamagu)さん

さいごに

繰り返しとなりますが、本書籍は開発者・テスターのみならず、POやビジネス関係者にもおすすめの本です。

内容も一部会話形式になっており、非常に分かりやすいと思いますので、興味のある方はぜひご購入の検討をお願いします!