エンジニアとQAエンジニアを繋いでくれた振る舞い駆動開発(Behaviour-Driven Development)

Scrum Fest Mikawa 2026 - エンジニアとQAエンジニアを繋いでくれた振る舞い駆動開発(Behaviour-Driven Development) | ConfEngine - Conference Platform
https://confengine.com/conferences/scrum-fest-mikawa-2026/proposal/50460/qabehaviour-driven-development

Transcript

1. エンジニアと QAエンジニアを繋 いでくれた振る舞い駆動開発 (Behaviour-Driven Development) Scrum Fest Mikawa 2026 Yusuke Ohmori
2. 自己紹介 • 大森裕介 ◦ 𝕏：@uutan1108 • バックエンドエンジニア • 勉強会主催や同人誌制作 など 2
3. 前提
4. チームの前提 • 振る舞い駆動開発 Behaviour-Driven Development (BDD) がすでにあるチームに入った、一人のエンジニア • すでに、チェックシートがあり、それをテストコードにしていく 形だった • BDD で E2E(UI から処理の終わりまで) テストを実装していった
5. 私の前提 • BDD を導入した人ではない • バックエンドエンジニアで API の実装が多かった
6. BDD とは
7. BDD とは テスト駆動開発 で記述されるテストケースは、作成したプロ グラムの動作が正しいかどうかを検証するために行う「テス ト」である。 テストであるという点は同一であるが、加えて、これから作成 しようとするプログラムに期待される 「振る舞い」 や「制約条 件」、つまり 「要求仕様」 に近い形で、 自然言語 を併記しな がらテストコードを記述する。 引用元：https://ja.wikipedia.org/wiki/ビヘイビア駆動開発
8. 自然言語のテストコード Gherkin 記法
9. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている 自然言語の テストコード 9
10. Feature: 預金 Feature（機能）：テストする機能全体を定義 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている 自然言語の テストコード
11. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する As a / I can / so that（ユーザーストーリー） As a: 誰がこの機能を使うか（ユーザーの役割） I can: 何ができるか（実行可能なアクション） so that: なぜその機能が必要か（ビジネス価値・目的） so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている 自然言語の テストコード
12. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Scenario（シナリオ）：具体的なテストケースを定義 Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている 自然言語の テストコード
13. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given (前提条件)：操作を実行する前の状態 Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている 自然言語の テストコード
14. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する When（実行アクション）：テスト対象となる具体的なアクショ ン Then 残高が 1500.0 円になっている 自然言語の テストコード
15. Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then（期待結果）：期待される結果を検証 Then 残高が 1500.0 円になっている 自然言語の テストコード
16. 実装例 Javaのテストコード 16
17. public class BankAccountSteps { private BankAccount account; @Given("初期残高が {double} 円の口座がある") public void 初期残高がの口座がある(double initialBalance) { account = new BankAccount(initialBalance); package com.example.bdd; import io.cucumber.java.Before; import io.cucumber.java.en.Given; import io.cucumber.java.en.When; import io.cucumber.java.en.Then; import static org.junit.jupiter.api.Assertions.assertEqu } als; @When("{double} 円を預金する") public void 円を預金する(double amount) { account.deposit(amount); } @Then("残高が {double} 円になっている") public void 残高がになっている(double expectedBalance) { assertEquals(expectedBalance, account.getBalance()); 自然言語のテスト コードから呼ばれる Javaのテストコード } } 17
18. public class BankAccountSteps { private BankAccount account; @Given("初期残高が {double} 円の口座がある") public void 初期残高がの口座がある(double initialBalance) { account = new BankAccount(initialBalance); package com.example.bdd; import io.cucumber.java.Before; import io.cucumber.java.en.Given; import io.cucumber.java.en.When; import io.cucumber.java.en.Then; import static org.junit.jupiter.api.Assertions.assertEqu } als; @When("{double} 円を預金する") public void 円を預金する(double amount) { account.deposit(amount); } @Then("残高が {double} 円になっている") public void 残高がになっている(double expectedBalance) { assertEquals(expectedBalance, account.getBalance()); } } 自然言語のテスト コードから呼ばれる Javaのテストコード
19. チームに入った直後 「 BDD は、自然言語っぽく書くテスト」 だと思っていた
20. QA エンジニア と私の繋がりを感じるまで
21. チーム構成
22. チーム構成 • QA エンジニアチーム 、フロントエンドエンジニアチー ム、バックエンドエンジニアチーム が別れている が毎日 よく会話している • 主に私とフロントエンドエンジニア、QA エンジニアの１名 づつで BDD で E2E テストを書いていた ※ 便宜上、フロントエンドエンジニアチーム、バックエンドエン ジニアチームを合わせて実装チームと書きます
23. どのように書いていったか • QA エンジニアが作成していたチェックシートがあった • チェックシートを参考にして、QA エンジニアと話つつ、実装 チームで Gherkin 記法でシナリオを書き起こす • QA エンジニアにもレビューしてもらう • 実装チームで E2E テストを実装していく
24. 今まで経験したことがあるプロジェクト
25. 今まで経験したことがあるプロジェクト • QA エンジニアチーム とバックエンドエンジニアチーム が別 れていて 、問題があったと連絡がある • QA エンジニアチームがなく 、バックエンドチームとフロント エンドチームが話しながら問題を調査する
26. 今まで経験したことがあるプロジェクト • QA エンジニアチームとバックエンドエンジニアチームが別れていて、問題が あったと連絡がある ◦ チームが別れていて会話しにくいと感じていた ... ◦ 実装後の指摘になり、 QAとの協働より「依頼と対応」の関係のよ うに感じていた ... • QA エンジニアチームがなく、バックエンドチームとフロントエンドチームが話し ながら問題を調査する ◦ 技術的な原因調査に偏り、ユーザーの利用シナリオを意識でき ていなかった ...
27. 今までのプロジェクト と QA エンジニアと私の繋がりを感じたプロジェクト
28. 以前 今 問題発生後 実装前・実装中 不具合 期待する振る舞い 関係 報告と対応 一緒に具体化する 私の視点 技術的な原因 ユーザーのシナリオ QA エンジニアと 会話する時期 QA エンジニアとの 会話の起点 QA エンジニアとの
29. BDD を経験して、 プロダクトに興味が湧いてきた
30. BDD のチームに入った直後、 APIの仕様だけを知っていても、ユーザーのシ ナリオは書けなかった
31. バックエンドのテストだけを書いていた時
32. API が正しく動けば、 機能としても正しく動いていると思っていた
33. バックエンドのテストだけを書いていた時 • ユーザーから API にリクエストが送られる • ユーザーに正しいレスポンスが返る • データベースが正しく更新される • エラー時に適切なステータスコードを返す
34. ユーザーは APIを直接使うわけではない。 私が確認していたのは、 ユーザー体験の一部分だった
35. API が正しく動けば、 機能としても正しく動いていると思っていた。 しかし、ユーザーは APIを直接使わない
36. APIの成功は、ユーザーのゴールではない
37. APIの成功は、ユーザーのゴールではない 例えば、「イベントへの参加申し込み」なら、 • 参加したいイベントを見つける • 参加条件や開催日時を確認する • 必要な情報を入力して申し込む • 申し込みが完了したことを画面で確認する
38. APIの成功は、ユーザーのゴールではない 例えば、「イベントへの参加申し込み」なら、 • 参加したいイベントを見つける → イベント一覧を取得 • 参加条件や開催日時を確認する → 自分が参加可能か確認 • 必要な情報を入力して申し込む → 情報を入力してリクエスト • 申し込みが完了したことを画面で確認する
39. ユーザーの行動をシナリオとして整理し、 自然言語でテストシナリオを書くためには、 プロダクトを理解する必要があった
40. QA エンジニアやフロントエンドエンジニアと 会話をしていった
41. QA エンジニアやフロントエンドエンジニアと 会話をしていった バックエンドだけを実装するだけでは分からないことがある 例えば、「イベントへの参加申し込み」 • どの画面から申し込みに進むのか • 完了後に何を表示するのか • エラーをどのように伝えるのか • ユーザーはその後、どの操作を行うのか
42. 私の関心も広がった気がする
43. 以前 今 API は正しく動くか ユーザーは目的を達成できるか 何を入力し、何を返すか なぜこの操作が必要なのか データが保存されたか 完了したことがユーザーに伝わるか 技術的な原因は何か ユーザーはどこで困ったのか バックエンドの責務 プロダクト全体での役割
44. BDD に対しての認識の変化
45. BDD に対しての認識の変化 テストシナリオを書く過程で、 プロダクトの使われ方を学んでいった。 そして、プロダクトに開発者としてだけではなく、 いちユーザーとして関心 を持つようになった。
46. BDD に対しての認識の変化 最初は、Gherkin 記法でテストコードを書くこと が、BDDだと思っていた。 しかし、重要だったのは書き起こすまでの 会話だと感じた。
47. BDD に対しての認識の変化 「どのような状況で使われるの か」「ユーザーが 操作すると何が起きるのか 」「最終的にどうなるこ とを期待しているのか 」を、 自然言語のシナリオ(今回はGherkin 記法)で 書き起こすまで話し、認識を揃えていく。その会話 の過程が、BDD かもしれないと感じた。
48. BDD が繋いでくれたもの
49. BDD が繋いでくれたもの • QA エンジニア とバックエンドエンジニアの私 • API の振る舞い とユーザーの行動や目的
50. 終わりに
51. BDD ではなくてもテストを書く時、 ユーザーにどのように使われるのかを 意識して、テストを書きたい。
52. BDD ではなくてもテストを書く時、 ユーザーにどのように使われるのかを 意識して、テストを書きたい。 おわり