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やビジネス関係者にもおすすめの本です。

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

Developers Summitで発表しました #devsumi

ここでの報告が遅くなりましたが、先月、Developers Summitで発表をしました。

発表内容

発表資料はこちら

speakerdeck.com

2022/04/24追記:講演動画はこちら(動画視聴にはCodeZineのログインが必要です)

codezine.jp

今回は二部構成にしました。

第一部「Agileの中で行われるTesting活動」

第一部では、さらに2つに分けて紹介しました。

「Sprint開始前に行う活動」では、実例マッピングを取り上げて紹介しました。これは、Scrum Fest OsakaやDevLoveでも発表した内容に少し追加して話しました。

「テスト活動面に注目したScrumの例」では、実際にScrumでテスト活動を取り入れていくとどのような形になるのか、一例を紹介しました。

第二部「Agile Testingとは特別な存在なのか」

第二部では、下記のようなAgile Testingの年表を紹介しつつ、1998年以前にあるTesting活動ではAgile Testingで言われているようなものと同じような考え方が存在していなかったのか考察しました。

次の登壇に向けて

今回は上記のような構成で話した結果、聴講者の満足度は高かったようです*1

ただし、第二部については時間の都合で語りきれなかったというのが正直なところです…。

なので、この第二部の部分をさらに掘り下げた発表を、Scrum Fest Niigataのプロポーザルとして提出しました!

confengine.com

第二部について興味のある方、プロポーザルが万が一通った場合は、Scrum Fest Niigataでお待ちしてます。

www.scrumfestniigata.org

*1:アンケート結果からの判断

QA(テスター)が開発工程の上流に参加して実際に行うこと

はじめに

本記事は、ソフトウェアテストの小ネタ Advent Calendar 2021の24日目の記事です。*1

目次

QAが開発工程の上流に参加する目的はインプット?

近年、単にテストをするだけでなく、「要件定義レビュー」「設計レビュー」「リファインメント」「Planning」といった開発工程の上流(早い段階)にQA(テスター)も参加する話を聞くようになりました。

しかし、その際に下記のようになっていないでしょうか?

レビュー時にQAは聞いているだけ?

レビューをインプットの場ではなく、フィードバックを与える場にすべきだと個人的には思っています。

QAによるフィードバックの例

とはいえ、「レビューの時やリファインメントの時にどういう風にフィードバックすれば良いの?」と疑問に思っている方もいるかもしれません。

そんな方に、参考になりそうな動画を見つけたので共有します。

youtu.be

この動画の4分6秒あたりから、スリーアミーゴスミーティング*2の例があります。

英語の動画ですが、比較的平易な英語なので、理解はしやすいかと思います。また現在、日本語字幕を選択できるようにしてもらう設定追加を動画の管理者にお願いしています。

より価値のあるミーティングにするためのポイント

ここでのポイントは2点あります。

  • 具体的な例を用いて議論する
    • 具体的な例で話さないと、「何となく良さそう」と錯覚してしまいます
  • 何を確認すれば、今回のfeatureがOKなのか意識する
    • 後の受け入れ基準になる可能性があります

特に、2つ目のポイントはQAが得意な分野(のはず)です。

スリーアミーゴスの参加者は、それぞれで注目ポイントが異なります。

  • PO…今回のfeatureで実現したいことに注目している
  • 開発者…今回のfeatureはどのようにすれば実現できるかに注目している
  • QA…今回のfeatureが「完成した」と判断するためには、何を確認すれば良いのかに注目している

これはあくまでも得意分野なだけであり、完全に担当を分けているわけではありません。例えば、開発者が「実現したいこと(POの得意分野)」について考えても良いですし、POが「何を確認すればOKなのか(QAの得意分野)」について考えても良いです。

しかし、QAがこの得意分野を活かしてフィードバックをすることで、会全体がより価値のあるものになると思います。

おわりに

今回は、開発工程の上流でQAがフィードバックをする方法について、動画も踏まえて紹介しました。これからの業務に役立ってもらえれば幸いです。

ちなみに、今回紹介した動画はCucumber Schoolというサイトの第1章をYoutube上に公開しているものになります。

cucumber.io

こちらのサイトでは、CucumberというBDDツールを使う以前に考えておくべきことを動画を使って紹介しているので、CucumberやBDDツールを使わない人や、QA、POなどにもオススメのサイトです!*3

こちらのサイト内の動画も、随時日本語翻訳できればと考えていますので、「まだ英語しかないから…」と思っている方も、日本語字幕がついた際にはぜひご活用ください!

*1:1日遅れましたが、24日目の記事です

*2:開発者、QA、POの代表者が参加する要件定義段階のミーティング

*3:以前の記事でもそうでしたが、BDDツールの前段の部分の重要性をCucumberというBDDツールのコミュニティが積極的に行っていることは非常に価値があると思っています! nihonbuson.hatenadiary.jp

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(後編)

はじめに

本記事は自動テスト・テスト自動化 Advent Calendar 2021の24日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述します。

後編である本記事では、自動テストに適用した場合の話を書きます。

前編はこちら。

nihonbuson.hatenadiary.jp

発表スライド&発表動画

speakerdeck.com

www.youtube.com

目次

  • はじめに
  • 発表スライド&発表動画
  • 目次
  • 今回のお題
  • 前編での成果物
  • PICTを使ってテスト総数を減らしてみる
    • 欠点1:網羅しているのはあくまでも二因子間だけである
    • 欠点2:有則な条件でPICTを使うと、見逃してしまうケースが出てくる可能性がある
    • 欠点3:テストに失敗した際、何が原因なのか分かりづらくなる
  • テスト設計の内容は自動テストの理解容易性にも影響する
    • このPICTの組み合わせをそのまま自動テストで表現する
    • デシジョンテーブルの例を活用して自動テストで表現する
  • おわりに
  • 参考文献

今回のお題

お題:座席順番待ちシステム

続きを読む

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(前編)

はじめに

本記事はソフトウェアテスト Advent Calendar 2021の22日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述したいと思います。

前編である本記事では、テスト実装までの話を書きます。

発表スライド&発表動画

speakerdeck.com

www.youtube.com

目次

  • はじめに
  • 発表スライド&発表動画
  • 目次
  • 今回のお題
  • 因子水準を考える
  • 因子水準表を元に全組み合わせを書く
  • 予約番号の印刷を任意にする
  • 名前に関する条件と人数に関する条件を別表に分ける
    • 名前と人数の条件を掛け合わせる必要もあるのでは?
  • 人数の同値クラスを考える
  • 合計人数という因子を追加する
  • ここまでのまとめ
  • テスト観点との関係性について考える
    • 初期のテスト観点
    • 無則な観点を削った場合
    • 人数の条件でまとめた場合
    • 合計人数の条件を含めた場合
  • 別のテスト技法を用いて考える
  • テスト設計の成果物を元に、テスト実装を行う
    • ポイント1:テスト設計番号と対応させている
    • ポイント2:テスト設計とテスト実装は1:1の関係ではない
    • ポイント3:テスト設計では省略している内容(実装実施時要検討事項)がテスト実装では現れる
  • まとめ
  • おわりに
  • 参考文献

今回のお題

お題:座席順番待ちシステム

続きを読む

【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

はじめに(翻訳記事の前提となる知識など)

本記事は自動テスト・テスト自動化Advent Calendar 2021の7日目の記事です。

最近、BDDなどでのテスト自動化を行うにあたり、Discovery(発見)*1→Formulation(定式化)→Automation(自動化)という流れが考えられるようになりました*2

記事「Behaviour-Driven Development」内の画像を引用し翻訳

この中の「定式化」では、後に自動化するテストシナリオの整理を考えます。*3

テストシナリオを作成する際に、ただ単にGherkin記法(Given/When/Thenなどを用いた記法)を利用するだけでは、保守性の低いテストシナリオが作られてしまいます。

そこで今回は、保守性の高い状態でテストシナリオを記述する際に役立つ原則「BRIEFの原則」について書かれた記事「BRIEFの原則を保った状態でシナリオを書いてください(原題:Keep your scenarios BRIEF)」を翻訳して紹介します。*4

cucumber.io

具体的なテストシナリオを使った解説は、書籍『Formulation』を読んでください*5

*1:以前に紹介した「実例マッピング」は発見フェーズの具体的なプラクティスの1つになります。 nihonbuson.hatenadiary.jp

*2:個人的には、この考え方はISTQB(JSTQB)の「テスト分析→テスト設計→テスト実装」というテストプロセスの考え方に近いかなと思っています。細かく考えると違いはあるのですが…。どちらにせよ、自動テストを考える前に自動テストの対象となるテストシナリオを整理することが重要だという考え方を主張しているのは良いことだと思います。しかも、「Cucumber」という、「BDDで自動化をどんどんしようぜ!」と言いそうなコミュニティがこういう主張をしていることは非常に価値があります。

*3:なお、仮に「自動化」を行わなかったとしても、「発見」「定式化」をすることは非常に価値があると、オリジナルの記事を書いたSebは自身の著書の中で述べています。私も同じ意見です。

*4:翻訳にあたり、著者本人の許可をもらいました。Thank you, Seb!

*5:現在は英語版しかありませんが、日本語翻訳版も検討しています

続きを読む

TDDサイクルは戻ることも大事

はじめに

本記事はテスト駆動開発 Advent Calendar 2021の1日目の記事です。このアドベントカレンダーはスカスカなので、テスト駆動開発経験談などをエントリーしてもらえると嬉しいです!

qiita.com

目次

  • はじめに
  • 目次
  • 本記事で伝えたいこと
  • 今回のお題
  • 新しいテストケースを考えて対応する
    • サイクル2周目の「3.そのテストを実行して失敗させる」
    • サイクル2周目の「5. 2で書いたテストを成功させる」
    • サイクル2周目の「6. テストが通るままでリファクタリングを行う」
      • 関数を呼び出す形に変更する
      • テストケースを1つ削除する
      • メソッドをインライン化する
  • おわりに

本記事で伝えたいこと

TDDをやっている皆さんは、下記のサイクルをご存知の方が多いと思います。

f:id:nihonbuson:20211201110545p:plain
見てわかるテスト駆動開発 / TDD Live and Workshop 2019 Spring - Speaker Deckより引用

この中の「4. 目的のコードを書く」がうまくいかない時に、「3.そのテストを実行して失敗させる」よりも前まで戻ることがよくあるよ、というお話です。

続きを読む