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

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

自己紹介 • 大森裕介 ◦ 𝕏：@uutan1108 • バックエンドエンジニア • 勉強会主催や同人誌制作など
2

前提

チームの前提 • 振る舞い駆動開発 Behaviour-Driven Development (BDD) がすでにあるチームに入った、一人のエンジニア • すでに、チェックシートがあり、それをテストコードにしていく形だった
• BDD で E2E(UI から処理の終わりまで) テストを実装していった

私の前提 • BDD を導入した人ではない • バックエンドエンジニアで API の実装が多かった

BDD とは

BDD とはテスト駆動開発で記述されるテストケースは、作成したプログラムの動作が正しいかどうかを検証するために行う「テスト」である。テストであるという点は同一であるが、加えて、これから作成しようとするプログラムに期待される「振る舞い」や「制約条
件」、つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する。引用元：https://ja.wikipedia.org/wiki/ビヘイビア駆動開発

自然言語のテストコード Gherkin 記法

Feature: 預金 As a 銀行の顧客 I can 口座にお金を預金する so that
残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている自然言語のテストコード 9

Feature: 預金 Feature（機能）：テストする機能全体を定義 As a 銀行の顧客 I can 口座にお金を預金する so
that 残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている自然言語のテストコード

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 円になっている自然言語のテストコード

残高を増やして保管できる Scenario: 預金すると残高が増える Scenario（シナリオ）：具体的なテストケースを定義 Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている自然言語のテストコード

残高を増やして保管できる Scenario: 預金すると残高が増える Given (前提条件)：操作を実行する前の状態 Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then 残高が 1500.0 円になっている自然言語のテストコード

残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する When（実行アクション）：テスト対象となる具体的なアクション Then 残高が 1500.0 円になっている自然言語のテストコード

残高を増やして保管できる Scenario: 預金すると残高が増える Given 初期残高が 1000.0 円の口座がある When 500.0 円を預金する Then（期待結果）：期待される結果を検証 Then 残高が 1500.0 円になっている自然言語のテストコード

実装例 Javaのテストコード 16

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

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のテストコード

チームに入った直後「 BDD は、自然言語っぽく書くテスト」だと思っていた

QA エンジニアと私の繋がりを感じるまで

チーム構成

チーム構成 • QA エンジニアチーム、フロントエンドエンジニアチーム、バックエンドエンジニアチームが別れているが毎日よく会話している •
主に私とフロントエンドエンジニア、QA エンジニアの１名づつで BDD で E2E テストを書いていた ※ 便宜上、フロントエンドエンジニアチーム、バックエンドエンジニアチームを合わせて実装チームと書きます

どのように書いていったか • QA エンジニアが作成していたチェックシートがあった • チェックシートを参考にして、QA エンジニアと話つつ、実装チームで Gherkin 記法でシナリオを書き起こす
• QA エンジニアにもレビューしてもらう • 実装チームで E2E テストを実装していく

今まで経験したことがあるプロジェクト

今まで経験したことがあるプロジェクト • QA エンジニアチームとバックエンドエンジニアチームが別れていて、問題があったと連絡がある • QA
エンジニアチームがなく、バックエンドチームとフロントエンドチームが話しながら問題を調査する

今まで経験したことがあるプロジェクト • QA エンジニアチームとバックエンドエンジニアチームが別れていて、問題があったと連絡がある ◦ チームが別れていて会話しにくいと感じていた ... ◦ 実装後の指摘になり、
QAとの協働より「依頼と対応」の関係のように感じていた ... • QA エンジニアチームがなく、バックエンドチームとフロントエンドチームが話しながら問題を調査する ◦ 技術的な原因調査に偏り、ユーザーの利用シナリオを意識できていなかった ...

今までのプロジェクトと QA エンジニアと私の繋がりを感じたプロジェクト

以前今問題発生後実装前・実装中不具合期待する振る舞い関係報告と対応一緒に具体化する私の視点
技術的な原因ユーザーのシナリオ QA エンジニアと会話する時期 QA エンジニアとの会話の起点 QA エンジニアとの

BDD を経験して、プロダクトに興味が湧いてきた

BDD のチームに入った直後、 APIの仕様だけを知っていても、ユーザーのシナリオは書けなかった

バックエンドのテストだけを書いていた時

API が正しく動けば、機能としても正しく動いていると思っていた

バックエンドのテストだけを書いていた時 • ユーザーから API にリクエストが送られる • ユーザーに正しいレスポンスが返る • データベースが正しく更新される •
エラー時に適切なステータスコードを返す

ユーザーは APIを直接使うわけではない。私が確認していたのは、ユーザー体験の一部分だった

API が正しく動けば、機能としても正しく動いていると思っていた。しかし、ユーザーは APIを直接使わない

APIの成功は、ユーザーのゴールではない

APIの成功は、ユーザーのゴールではない例えば、「イベントへの参加申し込み」なら、 • 参加したいイベントを見つける • 参加条件や開催日時を確認する • 必要な情報を入力して申し込む • 申し込みが完了したことを画面で確認する

APIの成功は、ユーザーのゴールではない例えば、「イベントへの参加申し込み」なら、 • 参加したいイベントを見つける → イベント一覧を取得 • 参加条件や開催日時を確認する → 自分が参加可能か確認
• 必要な情報を入力して申し込む → 情報を入力してリクエスト • 申し込みが完了したことを画面で確認する

ユーザーの行動をシナリオとして整理し、自然言語でテストシナリオを書くためには、プロダクトを理解する必要があった

QA エンジニアやフロントエンドエンジニアと会話をしていった

QA エンジニアやフロントエンドエンジニアと会話をしていったバックエンドだけを実装するだけでは分からないことがある例えば、「イベントへの参加申し込み」 • どの画面から申し込みに進むのか • 完了後に何を表示するのか •
エラーをどのように伝えるのか • ユーザーはその後、どの操作を行うのか

私の関心も広がった気がする

以前今 API は正しく動くかユーザーは目的を達成できるか何を入力し、何を返すかなぜこの操作が必要なのかデータが保存されたか完了したことがユーザーに伝わるか技術的な原因は何か
ユーザーはどこで困ったのかバックエンドの責務プロダクト全体での役割

BDD に対しての認識の変化

BDD に対しての認識の変化テストシナリオを書く過程で、プロダクトの使われ方を学んでいった。そして、プロダクトに開発者としてだけではなく、いちユーザーとして関心を持つようになった。

BDD に対しての認識の変化最初は、Gherkin 記法でテストコードを書くことが、BDDだと思っていた。しかし、重要だったのは書き起こすまでの会話だと感じた。

BDD に対しての認識の変化「どのような状況で使われるのか」「ユーザーが操作すると何が起きるのか」「最終的にどうなることを期待しているのか」を、自然言語のシナリオ(今回はGherkin 記法)で
書き起こすまで話し、認識を揃えていく。その会話の過程が、BDD かもしれないと感じた。

BDD が繋いでくれたもの

BDD が繋いでくれたもの • QA エンジニアとバックエンドエンジニアの私 • API の振る舞いとユーザーの行動や目的

終わりに

BDD ではなくてもテストを書く時、ユーザーにどのように使われるのかを意識して、テストを書きたい。

BDD ではなくてもテストを書く時、ユーザーにどのように使われるのかを意識して、テストを書きたい。おわり

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

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

More Decks by uutan1108

Featured

Transcript