テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put the intent of the test 2025

テストコードにはテストの意図を込めよう（2025年版）ブロッコリー @nihonbuson

自己紹介 • 風間裕也（ブロッコリー） • 株式会社10X 品質管理チーム • 副業：B-Testing（個人事業主）として ◦ 株式会社MonotaRO
（テストコンサルタント） ◦ グロース・アーキテクチャ&チームス株式会社（共同研究）他数社でお手伝い • 社外活動 ◦ JaSST Review（ソフトウェアレビューシンポジウム）実行委員長 ◦ WACATE（テストの合宿型ワークショップ形式勉強会）実行委員長 ◦ SReEE（ソフトウェアレビューをエンジニアリングっぽく捉える会）リーダー SNS上のアイコン

翻訳書籍今日のメイン

はじめに〜リーダブルなテストコードとは〜

こんなテストコードを書いていませんか？出典：第7回テストコードの認知負荷～テストの名前、構造、情報量を工夫する～ | gihyo.jp

リーダブルテストコードの効果リファクタリングはTDDの柱です。試験性（テスト容易性）はテストファーストが高めますが、修正性（変更容易性）はリファクタリングが高めます。出典：保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発、その全体像リーダブルなテストコードは修正性（変更容易性）を高める

理解容易性や説明容易性も重要なのでは？ • 理解容易性（Understandability） ◦ 対象の理解しやすい度合い ◦ 可読性（Readability）に影響を受ける • 説明容易性（説明可能性、Explainability） ◦
「今やっていることは何か」を説明できる度合い ◦ 読み手のコンテキストにも左右される ◦ 特にAI分野では「eXplainable AI(説明可能なAI)」として注目されている ◦ 可読性（Readability）に影響を受けるオリジナルの用語

保守性との関係保守性テスト容易性変更容易性説明容易性可読性が上がると、説明容易性や理解容易性が上がり、変更容易性やテスト容易性も上がり、保守性も上がる理解容易性可読性

Three Amigos という考えと QAの得意分野

3つの立場の人が集まり協調的に要件を確認する Three Amigos 画像出典：People vector created by stories - www.freepik.com
QA(Tester) 開発者 PO

Three Amigosの得意分野 Three Amigosは得意分野となる注目点が異なる • PO…今回のFeatureで実現したいことに注目 • 開発者…今回のFeatureはどのようにすれば　　　　実現できるかに注目 •
QA…今回のFeatureが「完成した」と　　判断するためには　　何を確認すれば良いのかに注目 ※あくまでも得意分野であり、　責任分担している訳ではない

4つの事例 • 本発表では、QAの得意分野である「何を確認すれば良いのか」に注目して行った会話を4つ紹介する ◦ 事例1:分かりやすいメソッド名を考える ◦ 事例2:テストの意図をテストメソッド名に反映する ◦
事例3＆4:会話を通じてテストの意図を見つけ出す ※本発表では「テストの意図」と表現していますが、この言葉は、　JSTQB（ISTQB）におけるテスト条件のことを指しています。　詳しくは、ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2018V3.1.J03 　を参照してください。

事例1 分かりやすいテストメソッド名を考える

お題その1 都道府県の項目についてのテスト

何を確認したいテスト？ @Test public void _青森県の場合{ } @Test public void _広島県の場合{
}

何を確認したいテスト？今回のテストって何を確認したいんですかね？ QA 開発者今回は選んだ都道府県によって送料が変わることを確認したいです！
@Test public void _青森県の場合{ } @Test public void _広島県の場合{ }

何を確認したいテスト？ @Test public void _青森県の場合送料が1000円{ } @Test public void _広島県の場合送料が510円{
}

何を確認したいテスト？これって 47都道府県全てでテストする？ QA 開発者地方ごとに送料が変わるのが
確認できれば OK！ @Test public void _青森県の場合送料が1000円{ } @Test public void _広島県の場合送料が510円{ }

意図が伝わるテストメソッド名の例 @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test
public void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); }

事例2 テストの意図をテストメソッド名に反映する

お題その2 以下の画像は座席順番待ちシステムの入力画面です。この店では、最大4名まで予約できます。氏名は10文字まで入力可能であり、入力必須です。この入力画面を用いて、順番待ちの登録ができるかどうかのテストを考えてください。

何かをテストしたい気持ちは分かるけど… @Test /*氏名：テスト太郎、人数：0名、予約番号：印刷する*/ public void _テストその1{ @Test /*氏名：テスト太郎、人数：1名、予約番号：印刷する*/ public void
_テストその2{ @Test /*氏名：テスト太郎、人数：2名、予約番号：印刷しない*/ public void _テストその3{

テストシナリオをさらに改善する今回のテストって、何を気にしてますかね？コメント行に書いてある情報量が多くて… えっと、自分も情報量が多いなと思ってたんですよ！実はですね、コードを書く前に内容を既に整理はしてまして… QA
開発者

実はテスト設計書を書いていた

特別な意図があったのは一部分だけだった @Test /*氏名：テスト太郎、人数：0名、予約番号：印刷する*/ public void _テストその1{ @Test /*氏名：テスト太郎、人数：1名、予約番号：印刷する*/ public void
_テストその2{ @Test /*氏名：テスト太郎、人数：2名、予約番号：印刷しない */ public void _テストその3{ 本当に確認したい入力値

特別な意図があったのは一部分だけだった @Test /*氏名：テスト太郎、人数：0名、予約番号：印刷する */ public void _テストその1{ @Test /*氏名：テスト太郎
、人数：1名、予約番号：印刷する */ public void _テストその2{ @Test /*氏名：テスト太郎、人数：2名、予約番号：印刷しない*/ public void _テストその3{ テストコードを実装するために必要になった入力値

テストの意図をテストメソッド名に込める @Test public void _人数が0名の場合予約できない{ @Test public void _人数が1名の場合予約できる{ @Test
public void _予約番号を印刷しない場合予約できる{

Nestedを用いてテストの意図を整理する @Nested class _予約できる人数は 1名以上4名以下 { @Test public void _人数が0名の場合予約できない{
@Test public void _人数が1名の場合予約できる{ } @Test public void _予約番号を印刷しない場合予約できる{

事例3 会話を通じてテストの意図を見つけ出す

お題その3 • 題材は自動販売機 • Cucumber + JUnit • 与えられた要求は下記の3つ ◦
100円硬貨を入れたら入金額が100円になってほしい ◦ 100円硬貨を入れた後に50円硬貨を入れたら入金額が150円になってほしい ◦ 1円硬貨は対応しないでほしい

お題を元に作成した結果(JUnitは割愛) Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:
入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている public class VendingMachine { int currentMoney = 0; public void insertCoin(int money) { if (money == 50 || money==100) { currentMoney += money; } } public int getCurrentMoney() { return currentMoney; } }

テストシナリオをさらに改善する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:
入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている

シナリオ名を変更する Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:
入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されているすべてシナリオ名が『入金額確認』になってますね。同じ名前はどうかと思うので変えたほうが良い気がしてます。なるほど。そしたらこんな感じですかね。（テストシナリオを編集する） QA 開発者

シナリオ名を変更するすべてシナリオ名が『入金額確認』になってますね。同じ名前はどうかと思うので変えたほうが良い気がしてます。なるほど。そしたらこんな感じですかね。（テストシナリオを編集する） Scenario: 1回投入時の入金額確認
Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている QA 開発者

テストの意図を明確にする Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:
2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されているなるほど。ちなみに、 2つ目のテストの意図ってなんですかね？コインを1回だけではなく、 2回投入した時にもちゃんと動くか確認したいという意図です。 QA 開発者

2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されているなるほどー。そしたら『2回投入時』と書いていますが、 3回目はどうなるのでしょうか？ 3回目は2回目と同じく、加算されていく仕組みなので、ロジック上は大丈夫です。 QA 開発者

2回投入時の入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されているということは、気にしているのは 2回投入の金額ではなく、複数回の投入時の加算なんですね。あー、確かにそうですね。（テストシナリオを編集する） QA 開発者

テストの意図を明確にするということは、気にしているのは 2回投入の金額ではなく、複数回の投入時の加算なんですね。あー、確かにそうですね。（テストシナリオを編集する） Scenario: 1回投入時の入金額確認 Given
自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている QA 開発者

数年後、テストの意図が分かるのはどっち？ Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario:
入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている Scenario: 1回投入時の入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回投入時の入金加算額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使用不可の硬貨投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている

事例4 会話を通じてテストの意図を見つけ出す②

お題と提示しているコードの注意点 • 10X（私が所属している会社）での在庫処理に関するテストケース • 10Xで扱っているプロダクトコードとテストコードに似たものをJavaの形で書き直したもの ◦ 実際のコードにはFlutterで記述している ◦
実際のコードはもっと設計がしっかりしています！ • 分かりやすさ・説明のしやすさ重視のため、実際のコードよりも処理を単純化して例示している

在庫処理のテストケース @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

会話からテストの意図を理解する @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc(), is(7) ); } これってどうして最終的な期待値が7なんですか？えっとそれは… QA 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } まず、商品Aのクラスを生成して… 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 元々の在庫数の10個を setBaseStockで設定して… 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 新たに入庫された6個を setReceivedStockで設定するので、合計の在庫は 10+6=16個で… 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 得られた在庫数は実店舗とネットスーパー上での共用となるので、全体の在庫の50%をネットスーパー用に確保するために、 setNsCoeﬃcientで設定するので、 16×0.5=8個となって… 開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } 最後に手動で設定する値 “setManualOverride”があれば、何があってもネットスーパーの在庫数として上書きされるので、今回の在庫は7個になります。開発者

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なるほどー！ありがとうございます。 QA

productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } QA 説明を聞いていると、「setManualOverrideがあれば、何があってもネットスーパーの在庫数として上書きされるので」という部分が今回のテストの意図のように聞こえましたああ、確かにそうかも開発者

テストの意図を記載して説明容易性を上げる @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なので、それをそのままテストメソッド名にしちゃいましょう！ QA

テストの意図を記載して説明容易性を上げる @Test public void 手動設定の値があれば必ず最終的な在庫数として上書き設定する { ProductStock productStock =
new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } なので、それをそのままテストメソッド名にしちゃいましょう！ QA

テストの意図をテストメソッド名に書くことの利点

利点1.特別な設定値がどれなのか分かる @Test public void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”);
productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); } テストの意図が書かれていないと、テストメソッド内にある、 “10”, “6”, “0.5”, “7” がそれぞれ特別な意味を持っているように見えてしまう

利点1.特別な設定値がどれなのか分かるテストの意図が書かれていると、重要な箇所が分かるその他の値は、テストするために設定した任意の値だと分かる @Test public
void 手動設定の値があれば必ず最終的な在庫数として上書き設定する{ ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

利点2.仕様変更時に対応しやすい　例① 例えば、「手動設定 setManualOverride は考えなくても良いことになった」という仕様変更が出てきたとき… @Test public
void 手動設定ありのパターン{ ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

利点2.仕様変更時に対応しやすい　例① プロダクトコードで setManualOverride() の処理を削除したとする連動して、このテストコードは通らなくなる @Test public

利点2.仕様変更時に対応しやすい　例① テストの意図が書かれていないと、このテストがどんなことをしたかったのか改めて読み込む必要がある @Test public

利点2.仕様変更時に対応しやすい　例① テストの意図が書かれていることで、今回はテストケースそのものを削除する対応で良いと即時に判断できる @Test public void
手動設定の値があれば必ず最終的な在庫数として上書き設定する { ProductStock productStock = new ProductStock(“商品A”); productStock.setBaseStock(10); productStock.setReceivedStock(6); productStock.setNsCoefficient(0.5); productStock.setManualOverride(7); assertThat( productStock.calc() , is(7)); }

利点2.仕様変更時に対応しやすい　例② @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test
public void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); }

利点2.仕様変更時に対応しやすい　例② @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public
void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケースローレベルテストケース

利点2.仕様変更時に対応しやすい　例② @Test public void _東北地方の場合送料が1000円{ assertThat(calcShipingCost(“青森県”), is(1000)); } @Test public
void _中国地方の場合送料が510円{ assertThat(calcShipingCost(“広島県”), is(510)); } ハイレベルテストケースローレベルテストケース将来万が一、青森県が統廃合などで存在しなくなった場合、東北地方の別の県を選べば良いことが分かる

テストの意図は Unknownを表面化させる

ラムズフェルド行列 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉が発端 Known knowns （知っていることを分かっている）どのような内容なのか分かっており、その自覚もある状態。 Known unknowns （知らないことを分かっている）
どのような内容なのか分かっていないが、「自分が分かっていない」という状況であるということは把握している状態。 Unknown knowns （知っていることを分かっていない）どのような内容なのか分かっているが、その状況は把握していない状態。無意識的な行動など。 Unknown unknowns （知らないことを分かっていない）どのような内容なのか分かっておらず、「現在分かっていない」という状況も把握していない状態。

テストコードはKnown knownsを書いている 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉が発端 Known knowns （知っていることを分かっている）どのような内容なのか分かっており、その自覚もある状態。 Known unknowns
（知らないことを分かっている）どのような内容なのか分かっていないが、「自分が分かっていない」という状況であるということは把握している状態。 Unknown knowns （知っていることを分かっていない）どのような内容なのか分かっているが、その状況は把握していない状態。無意識的な行動など。 Unknown unknowns （知らないことを分かっていない）どのような内容なのか分かっておらず、「現在分かっていない」という状況も把握していない状態。

テスト駆動開発は高速でcheckしている開発者自身が書く自動テストは、実際にはテストを行っているのではなく、自分が考えたとおりに動くかどうかを確かめている、つまり高速でcheckしているのだ By James Bach （翻訳:和田卓人）出典：Testing
vs. Checking 訳語出典：テスト駆動開発

具体例をテスト形式で書いているだけプログラマーは自分が単体テストを書いていると思っています。そうではありません。設計の指針となる簡単な具体例をテストコード形式で書いているに過ぎません。 By Daniel Terhorst-North(Dan North)
出典：We need to talk about testing 訳語出典：【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！

AIが得意なのもKnown knownsの領域 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉が発端 Known knowns （知っていることを分かっている）どのような内容なのか分かっており、その自覚もある状態。 Known unknowns
（知らないことを分かっている）どのような内容なのか分かっていないが、「自分が分かっていない」という状況であるということは把握している状態。 Unknown knowns （知っていることを分かっていない）どのような内容なのか分かっているが、その状況は把握していない状態。無意識的な行動など。 Unknown unknowns （知らないことを分かっていない）どのような内容なのか分かっておらず、「現在分かっていない」という状況も把握していない状態。

テストの意図はUnknownを表面化させる Known knowns （知っていることを分かっている）どのような内容なのか分かっており、その自覚もある状態。 Known unknowns （知らないことを分かっている）どのような内容なのか分かっていないが、
「自分が分かっていない」という状況であるということは把握している状態。 Unknown knowns （知っていることを分かっていない）どのような内容なのか分かっているが、その状況は把握していない状態。無意識的な行動など。 Unknown unknowns （知らないことを分かっていない）どのような内容なのか分かっておらず、「現在分かっていない」という状況も把握していない状態。 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉が発端

もっと早い段階でテストの意図を注入する

「もっと早い段階」とは？ • 今回の事例は実装後の改善だった • テストの意図を確認した結果、実装しているテストがそもそも良くない形になっている場合もあります。 ◦ その際はテストメソッド内のリファクタリングやテスト設計の作り直しをします。 •
今回は会話から改善する例をお伝えしましたが、初めからテストプロセスを意識してテストケースを作成することで、メンテナンス性を高めることができます。

テストプロセス（JSTQBより）テスト分析テスト設計テスト実装テスト実行 ISTQBテスト技術者資格制度
Foundation Level シラバス日本語版 Version 2023V4.0.J02 を参考に作成何をテストするかを決定するテストスクリプトやテスト手順を作成するテストスイートを実行するどのようにテストするかを決定する

テストプロセステスト分析テスト設計テスト実装テスト実行何をテスト
するかを決定するテストスクリプトやテスト手順を作成するテストスイートを実行するどのようにテストするかを決定するここを注力しがち ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2023V4.0.J02 を参考に作成

テストプロセステスト分析テスト設計テスト実装テスト実行何をテスト
するかを決定するテストスクリプトやテスト手順を作成するテストスイートを実行するどのようにテストするかを決定するここからテストの意図を込めましょう ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2023V4.0.J02 を参考に作成

t_wadaさん作のTDDのサイクルにもある出典：見てわかるテスト駆動開発

TDDの最初は期待動作のリストアップ TDDの最初のステップは、あるシステムに振る舞いの変更が望まれているとき、その新しい振る舞いにおいて期待される動作をリストアップすることだ。「TDDはいきなりコードを書き始める。いつ終わるのかも全然見通せない」という意見は、全くの見当外れだ。引用：【翻訳】テスト駆動開発の定義

テスト分析・設計を実装前に行う出典：レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー | JaSST Review’23

テスト分析をSprint前に行う出典：品質保証活動をアジャイルプロセスに溶け込ませるためのテスト活動の再構築と、それを支えるアジャイル・エンジニアリングの活用 | ソフトウェア品質シンポジウム2024

早い段階でのテストの意図の注入事例

テスト分析をSprint前に行う出典：品質保証活動をアジャイルプロセスに溶け込ませるためのテスト活動の再構築と、それを支えるアジャイル・エンジニアリングの活用 | ソフトウェア品質シンポジウム2024

今回の対象となる機能 • とあるtoCのプロダクト ◦ 会員登録をすることでサービスを利用できる • 今回新たに「管理者による強制退会機能」を開発することになった • ユーザー本人による退会機能は既存機能として存在

リファインメント中の会話 PO 今回新たに管理者による強制退会機能を作ってほしい

リファインメント中の会話「ユーザー本人の退会機能」のロジックを流用する形で、コストをかけずに実装できるのかなと想像してたんだけどどうだろ？ PO 開発者確かに開発コストは低いかも

リファインメント中の会話 QA ちょっと、今回の機能の背景を知りたいです！どうして強制退会機能を作ろうと思ったんでしたっけ？

リファインメント中の会話 QA ちょっと、今回の機能の背景を知りたいです！どうして強制退会機能を作ろうと思ったんでしたっけ？ PO 他人に迷惑をかけるユーザーがいるので、そのユーザーはサービスを利用できないようにしたいからです

リファインメント中の会話 QA そしたら、強制退会になったユーザーは再度の会員登録はできないようにしないと意味がないですかね？ああ、確かにそうですね。 PO

受け入れ基準の作成【タイトル】管理者による強制退会機能【受け入れ基準】 • 管理者がユーザーのアカウントを指定して退会させることができること • 退会させられたユーザーは同じメールアドレスで会員登録できないこと

リファインメント中の会話 QA じゃあ、開発が終わってテストする時は強制退会させられたユーザーが会員登録できないかもテストしますね！了解です！開発者

受け入れ基準作成時に関わることの効果 • 実装担当者が設計・実装を行う時に、「リファインメントでこんな会話をしたな…」と思いながら実装する ◦ その部分でのバグの作り込みを防ぐことができる • バグが発生しなければ色々な工数が削減できる ◦
実装内容を思い出すコスト ◦ 修正をするコスト ◦ もう一度テストするコスト ◦ 影響範囲のある箇所をテストするコスト ◦ バグチケットの操作をするコスト　　　　など

システムを飛び出して要求を考えるどうして強制退会機能を作ろうと？受入基準新たに管理者による強制退会機能を作って欲しいユーザー本人
の退会機能のロジックを流用する PO 開発コストは低くできそう！開発者 QA 迷惑をかけるユーザーはサービス利用できないように強制退会ユーザーは会員再登録できないように！ QA PO PO

顧客が本当に必要だった物に近づく一歩画像出典：http://ntd.way-nifty.com/blog/2005/05/post_80fd.html

まとめ

まとめ • 何を確認したいテストなのか考えることが大切 • 会話を通じてテストの意図を見つけ出すことが可能 • ハイレベルテストケースとローレベルテストケースを意識してテストメソッド名を考えよう • テストプロセスを活用することで、
初めからテストの意図を意識でき、メンテナンス性の高いテストを作成することが可能 • テストの意図を早い段階で行う

宣伝

WACATE 2025 夏 • ソフトウェアテストをテーマにしたグループワーク形式の合宿型勉強会 • 今回のテーマはテストプロセス • 日時：6/28（土）10:00
～ 6/29（日）17:30 • 参加費：30,000円 ◦ 宿泊費、4食の食事代含む ◦ 35歳以下は27,000円 • 場所：トーセイホテル＆セミナー幕張 ◦ JR京葉線　新習志野駅徒歩約2分 • 申し込みは公式ページから

Nihonbashi Test Talk #4 • 日本橋・馬喰町周辺でテストや品質周りの話をする会 • 日時：5/22（木）19:00〜21:30 • 場所：Autify,
Inc. イベントスペース ◦ 都営浅草線「東日本橋」駅徒歩8分 ◦ JR総武本線「馬喰町」駅徒歩9分 • 料金：無料 • 申し込みはconnpassページから

ご清聴ありがとうございました

参考：BDDのプロセス出典：The BDD Books - Discovery

参考：BRIEFの原則 • Business language（ビジネス言語） • Real data（実際のデータ） • Intention revealing
　（意図を明らかにする） • Essential（必須） • Focused（焦点を絞る） • Brief（簡潔である）出典：The BDD Books - Formulation

テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put t...

テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put the intent of the test 2025

More Decks by nihonbuson

Other Decks in Technology

Featured

Transcript