B-Testing.fm

今回のエピソードでは、2026年12月19日・20日に開催される若手向け宿泊型勉強会「WACATE2026 冬」で担当するセッション「プロパティベースドテスト」についてご紹介します。具体的なテストケースを手動で用意するのではなく、どんな状況でも成り立つ普遍的な性質（プロパティ）を定義してランダムなインプットで検証するこの手法。実装方法の解説はあっても、最も創造性が求められる「プロパティそのものをどう考え出すか」という分析プロセスに焦点を当てた情報は世の中にほとんどありません。そこで今回のワークショップでは、あえてコード実装ではなく「性質を考えること」に特化した、世界でも珍しい実践的なワークをお届けします！

📌 今回のエピソードのポイント

• プロパティベースドテストとは： 期待結果を個別に考えず、インプットをランダム生成して仕様の普遍的な性質（プロパティ）を満たすか確認するテスト手法。AIのガードレールとしての活用にも期待できます。
• 手法導入における最大の壁： プロパティをどうコードに落とし込むかの文献はあっても、最も創造性が必要な「プロパティそのものをどう考え出すか（テスト分析）」を解説する情報が非常に少ないのが現状です。
• WACATE2026 冬での新たな挑戦： プログラミングの実装ではなく、「どんな場合でも成り立つ性質とは何か」を考えることに特化した、これまでにない新鮮なワークショップを実施します。

📕 参考文献

• WACATE2026 冬〜テスト感のある者たちッ今だッ!!!〜
• プロパティベースドテスト（ISTQB用語集）

🕒 チャプター

• (00:00) オープニング
• (01:12) WACATE2026 冬で担当するセッションについて
• (01:56) プロパティベースドテストとは？通常のテストとの違い
• (03:45) AI開発との相性とガードレールとしての活用法
• (04:22) 最大の壁となる「プロパティ」を見つけ出す難しさ
• (05:55) 実装ではなく「考える」ことに特化したワークの狙い
• (07:24) エンディング

📢 あなたのご意見をお聞かせください

「プロパティベースドテストという言葉を初めて聞いた！」「WACATEのワークショップに参加してみたい！」といった感想はもちろん、テスト自動化に関するお悩みなどもぜひお寄せください。

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

テスト自動化を進めるなかで、「UIテストを作ったものの実行が遅い」「失敗時の原因調査に追われてメンテナンスが追いつかない」といった悩みに直面したことはありませんか？今回は「テスト自動化のピラミッド（Test Pyramid）」をテーマに、UI・サービス・ユニットテストそれぞれの特徴と、なぜピラミッドの形に保つ必要があるのかを現場目線で分かりやすく解説します。実行速度や失敗時の分析コストのリアルな具体例、さらに「テスト自動化の8原則」やGoogleの比率事例などを交えながら、費用対効果の高いテスト自動化戦略を掘り下げます。

📌 今回のエピソードのポイント

• テスト自動化ピラミッドの基本： UI・Service・Unitの3層構造と、図に描かれた「ウサギとカメ」「ドルとセント」が示す実行速度・コストの本質を解説。
• UIテストが増えると直面する罠： ログインやECサイトのカート操作を例に、実行時間の肥大化やテスト失敗時の原因特定（結果分析）にかかる重いコストをリアルに紐解きます。
• 費用対効果を高めるテスト戦略： 「テスト自動化の8原則」やGoogleの比率事例（7:2:1）を参考に、なぜユニットテストを厚くし、UIテストを絞るべきなのかを考えます。

📕 参考文献

• 帝京大学青舎祭
• Test Pyramid
• テスト自動化の8原則

🕒 チャプター

• (00:00) オープニング
• (01:50) テスト自動化のピラミッドと3つのテスト分類
• (04:24) なぜUIテストは遅くて高コストなのか？具体例で解説
• (10:15) テスト自動化の8原則と「結果分析」のコスト
• (11:01) 理想的なテスト比率とピラミッド型の重要性
• (12:35) エンディング

📢 あなたのご意見をお聞かせください

皆さんの現場では、ユニットテストやUIテストのバランスをどのように設計・運用していますか？「UIテストのメンテや結果分析に追われて大変だった」「ピラミッドを意識してこんな工夫をしている」など、日頃の悩みや体験談をぜひお聞かせください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、「テストを書きやすいコードはシンプルな設計になりやすい」というテーマで、実装における設計とテストコードの関係性について解説します。階乗を計算するプログラムの例題を用いて、for文を使ったシンプルな実装と、if文で全てのケースを分岐させた複雑な実装を比較。テストコードの書きやすさやバグ（計算間違い）の見つけやすさの違いについて分かりやすく紐解きます。テストコードを書くことを意識することが、いかにして手戻りを防ぎ、より良い設計を生み出すヒントになるのか、その本質に迫るエピソードです。

📌 今回のエピソードのポイント

• 階乗プログラムを用いた実装比較： for文によるループ実装とif文による全分岐実装を比較し、それぞれのコードの特徴を解説します。
• if文の落とし穴とテストの重要性： 全てのケースを分岐させた場合、一部の計算間違い（例：4の階乗が28になっているなど）を見つけるために全パターンのテストが必要になる点を指摘します。
• テストの書きやすさは設計のバロメーター： テストが書きづらい、あるいは複雑なテストが必要なコードは、そもそも実装の設計がシンプルではない可能性が高いという本質について語ります。

🕒 チャプター

• (00:00) オープニング
• (01:21) テーマ：テストを書きやすいコードはシンプルな設計になりやすい
• (01:40) 例題：階乗を計算するプログラム
• (02:29) 回答例1：for文を使ったシンプルな実装
• (03:54) 回答例2：if文で分岐させる実装とその落とし穴
• (05:19) テストが書きづらいコード＝シンプルではないコード
• (06:52) エンディングとお知らせ

📢 あなたのご意見をお聞かせください

皆さんは、テストコードを書く際に「なんだかテストが書きづらいな…」と感じて、そもそもの設計を見直した経験はありますか？あるいは、テストを書く前提で設計することでスムーズに開発が進んだ事例などがあれば、ぜひ教えてください！皆さんの現場での体験談や、今回のエピソードを聞いての感想をお待ちしております。

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

自動テストを導入したいけれど、どのタイミングで、どう書き始めればいいか悩んでいませんか？今回は、自動テストを書くべき「3つのきっかけ」について詳しく解説します。仕様に迷ったときのテストファーストなアプローチから、バグ修正時のテスト追加による再発防止、そして反復作業の自動化まで、日々の開発業務にすぐに活かせる実践的な視点でお話ししています。自動テストの第一歩を踏み出したい方や、より効果的なテスト運用を目指している方にぴったりのエピソードです！

📌 今回のエピソードのポイント

• 何を実装すべきか迷っている時：テストを先に書くことで仕様とゴールを明確にし、実装の方針を定めるアプローチについて解説します。
• 欠陥を修正する時：バグは特定の場所に偏りやすいという「欠陥の偏在」に基づき、修正と同時にテストを追加して再発を防ぐ重要性を語ります。
• 同じことを繰り返し実行したい時：すべてを自動化するのではなく、大量のデータ作成やガチャの排出確認など、効果的な部分を見極めて自動テストに任せるコツを紹介します。

📕 参考文献

• Developers Summit 2027
• 【デブサミ2027連動企画】コンテンツ委員会が明かす「選ばれるプロポーザル」の作り方
• #40 テストの7原則（前編）QAエンジニア以外も知っておきたい品質の基本

🕒 チャプター

• (00:00) オープニング
• (01:50) 自動テストを書く3つのきっかけ
• (02:34) きっかけ1：何を実装すべきか自分で迷っている時
• (03:38) きっかけ2：欠陥を修正する時
• (05:33) きっかけ3：同じことを繰り返し実行したい時
• (09:34) エンディング

📢 あなたのご意見をお聞かせください

皆さんは、日々の業務の中でどのようなきっかけで自動テストを書き始めましたか？「こんな作業を自動化して楽になった！」というエピソードや、逆に「自動化しようとして失敗した…」という経験があれば、ぜひ教えてください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、QAエンジニア同士で熱い議論を交わす勉強会「語る夕べ」シリーズについてご紹介します。「テスト設計を語る夕べ」や「ドメインテストを語る夕べ」など、過去に開催されたイベントの様子や、参加者のリアルな声を通して、その魅力をたっぷりとお届けします。

📌 今回のエピソードのポイント

• 「語る夕べ」シリーズのコンセプト： 登壇者だけでなく、参加者全員で深く議論し合う場を提供しています。
• 過去の開催テーマ： テスト設計、ドメインテストなど、多岐にわたるテーマで開催されてきました。
• 今後の開催予定： 次回はユースケーステストをテーマに開催予定です。ぜひご期待ください！

📕 参考文献

• ドメインテストを語る夕べ
• 2026年版 ドメイン分析をアップデートする
• ドメインテストにおけるONポイントとOFFポイントについて考える

🕒 チャプター

• (00:00) オープニング
• (01:26) 「テスト設計を語る夕べ」シリーズについて
• (05:07) コロナ禍前から続く「語る夕べ」の歴史
• (06:08) コロナ禍再開後の「語る夕べ」
• (08:24) 次回開催「ユースケーステストを語る夕べ」について
• (09:20) オフライン開催へのこだわり
• (10:07) エンディング

📢 あなたのご意見をお聞かせください

「語る夕べ」シリーズで取り上げてほしいテーマや、これまでの開催で印象に残っていることなど、ぜひご意見をお寄せください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、これまでのテスト設計の話題から少し離れ、「自動テスト」をテーマにお話しします。自動テストと聞くと、「テスト実行の工数削減」が真っ先に思い浮かぶかもしれませんが、実は得られる恩恵はそれだけではありません。「そもそもなぜ自動テストを書くのか？」という根本的な疑問について、ロボット掃除機や食洗機、サーカスの綱渡りといった身近な例えを交えながら、4つの視点でメリットを深掘りして解説しています。自動テストに興味がある方、これから導入を考えている方はぜひお聴きください！

📌 今回のエピソードのポイント

• テスト実行に必要な準備の明確化： ロボット掃除機を買うと床を片付けるようになるのと同様に、自動テストの導入はテストしやすい設計や環境作りを促進します。
• 安心してコードを変更できるセーフティネット： サーカスの落下防止網があるから大技に挑めるように、自動テストがあるからこそ安全にリファクタリングや仕様変更が行えます。
• 生きたドキュメントとしての機能： 自動テストは、常に仕様書と実装の乖離を防ぐ「動く説明書」としての役割を果たします。
• 工数削減とその注意点： テスト実行工数は削減できますが、テストを準備する工数やメンテナンスコストへの意識も重要です。

📕 参考文献

• テスト自動化のルンバ効果
• 開発者が適切なテストを行うために

🕒 チャプター

• (00:00) オープニング
• (01:46) なぜ自動テストを書くのか？
• (03:03) メリット1：テスト実行に必要な準備が明確化される
• (06:36) メリット2：安心して既存コードを変更できる
• (07:54) メリット3：実装内容の説明書代わりになる
• (09:13) メリット4：テスト実行の工数が削減できる
• (11:34) エンディング

📢 あなたのご意見をお聞かせください

自動テストの導入でつまずいたことや、逆に「導入してよかった！」と感じたエピソードはありますか？ぜひ皆さんの自動テストに関する体験談を教えてください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：こちらからお気軽にどうぞ。

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のエピソードでは、探索的テストに関する名著の日本語訳版『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』についてご紹介します！「探索的テスト＝仕様書がない時の場当たり的なテスト」というよくある誤解を解きほぐし、具体的なヒューリスティクスやアプローチ手法を体系的に学べる一冊です。テスト設計技術との高度な融合や、実際の開発プロセスへの組み込み方など、テストを専門とする方だけでなく、開発者やプロダクトマネージャーにも役立つ情報が満載。本書が持つ本当の価値と、現場で実践するためのヒントを語ります。

📌 今回のエピソードのポイント

• 「探索的テスト」への誤解を払拭：思いつきや場当たり的なテストというイメージを覆し、明確な意図を持ったテスト手法であることを解説します。
• 実践的なアプローチとテスト設計の融合：具体的な探索のヒューリスティクスと、従来の手法を組み合わせてテストを完了に導くプロセスが学べます。
• あらゆるプロダクト開発者におすすめ：QA担当者だけでなく、開発者やPdMなど、プロダクト開発に携わるすべての人に読んでほしい理由を語ります。

📕 参考文献

• Newbee Conference 2026
• Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド

🕒 チャプター

• (00:00) オープニング
• (02:30) 翻訳に携わった書籍『Explore It!』の紹介
• (04:00) 探索的テストに対するよくある誤解
• (05:45) 実践的なアプローチとテスト設計技術との融合
• (07:20) 探索的テストの本当の価値とおすすめの読者層
• (09:30) エンディング

📢 あなたのご意見をお聞かせください

今回紹介した『Explore It!』、皆さんはもうチェックされましたか？探索的テストについて普段現場で感じている疑問や、実際に試してみた感想などがあれば、ぜひ教えてください！また、「こんなテストの悩みを解説してほしい」といったリクエストもお待ちしています。

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回はユースケーステストについての3回目のエピソードとして、ユースケース図やユースケース記述をもとに、どのようにシナリオベースのテストに落とし込んでいくかについて語っています。DVDレンタルの例を用いて、基本フローから代替・例外フローへの寄り道パターンの考え方、そして業務全体の流れを通したテストだからこそ見つかる「リカバリー不全」の不具合など、実践的なポイントを解説しています。実際の業務で活用する際の注意点にも触れていますので、ぜひテスト設計の参考にしてみてください。

📌 今回のエピソードのポイント

• ユースケーステストとシナリオテスト： ユースケースの動作を実行するように設計する「シナリオテスト」との関係性と、その記載形式について整理します。
• DVDレンタルを例にしたテスト作成手順： 基本フローから寄り道する代替フロー・例外フローを含めた、具体的なシナリオの書き方を解説します。
• 業務フロー全体を通したテストのメリット： 画面単体のテストでは見逃されがちな、エラー操作後のリカバリー不全などの不具合を発見できる強みを語ります。

📕 参考文献

• #17 【水曜日のダウンタウン】ザ・スベリドリームマッチ
• ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03
• ASTERセミナー標準テキスト[Ver3.1.1]
• 第98回： ユースケーステスト（後編） - Kouichi Akiyama - note

🕒 チャプター

• (00:00) オープニング
• (02:35) ユースケーステストとは・シナリオテストとの関係
• (05:45) ユースケーステストの作り方
• (07:07) ユースケーステストの作成手順（実装するフローを考える）
• (10:46) ユースケーステストを作成するメリット
• (14:13) まとめ
• (15:43) 実際の業務で活用する際のポイント
• (17:28) エンディング・お知らせ

📢 あなたのご意見をお聞かせください

「ユースケーステストって実際こういう感じなんだ」「実際の業務で使ってみたらうまくいったよ！」といった、実践してみた感想や体験談があればぜひ教えてください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

ユースケーステストの続編として、今回は「ユースケース記述」の基本から書き方のコツまで詳しく解説します。ユースケース図だけでは表現しきれない詳細なやり取りや例外処理をどのようにテキスト化するのか、DVD貸し出しシステムを例に挙げながら具体的に紐解きます。アクターとシステムの対話を意識した正しい粒度の揃え方や、仕様の曖昧さ・不備を防ぐ記述のメリットを学んでいきましょう！

📌 今回のエピソードのポイント

• 図では見えない詳細の視覚化： ユースケース図のシンプルさでは表現しきれない、会員証の有効期限確認などの具体的な工程や例外フローを明確化できるメリットを解説します。
• アクターとシステムの交互の対話： 基本フローを書く際は、アクターの入力とシステムのフィードバックが交互に展開する構造を意識するのが重要なポイントです。
• 適切なトランザクションの粒度： ボタンを押すレベルの細かすぎる操作ではなく、「会員証情報を入力する」といった分けることのできない一連の情報処理の粒度で書くコツを紹介します。

📕 参考文献

• 『有田脳』シーズン3.5『有田脳人』Ep.5 ゲスト・藤井智久（テレビ朝日「くりぃむナントカ」プロデューサー）
• ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
• 第97回： ユースケーステスト（前編） - Kouichi Akiyama - note

🕒 チャプター

• (00:00) オープニング
• (02:12) ユースケース記述とは
• (03:09) ユースケース記述の例（DVD貸し出しシステム）
• (05:52) ポイント：アクターとシステムが交互に登場する
• (06:23) ユースケース記述を書くメリット
• (07:44) ユースケース記述を書くコツ（適切な粒度とは）
• (09:25) まとめ・エンディング

📢 あなたのご意見をお聞かせください

皆さんの現場では、ユースケース記述をどのように活用していますか？「仕様の抜け漏れを見つけた経験」や「記述の粒度に悩んだこと」など、ぜひご意見やご感想をお寄せください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のエピソードでは、ソフトウェアテストの手法の一つである「ユースケーステスト」について、その全体像から、ユースケース図の役割、そしてユースケース図を書くメリットまで、詳しく解説しています。特に、ユースケース図がどのようにシステム開発に関わる人々の認識を合わせる役割を果たすのか、DVDレンタルシステムの具体例を交えながらわかりやすく説明しています。これからユースケーステストを学びたい方や、テスト設計の幅を広げたい方におすすめの内容です。

📌 今回のエピソードのポイント

• ユースケーステストとは： システムやサブシステムが提供する一貫した機能単位をテストする手法。
• ユースケース図の目的： 開発者やユーザーなど、関係者間でシステムの全体像に対する「ざっくりとした認識」を合わせること。
• ユースケース図のメリット： 個々人が想像しているシステムを具現化し、比較することで、認識のズレを防ぐことができる点。

📕 参考文献

• 2026.07.19 BSW AFTER GAME PARTY｜BLACK SUMMER WEEK 2026
• ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03
• 第97回： ユースケーステスト（前編） - Kouichi Akiyama - note
• JIS X 4170：2009

🕒 チャプター

• (00:00) オープニング
• (02:20) ユースケーステストとは
• (03:24) JSTQB FLシラバスから削除された手法
• (04:11) ユースケーステストの全体像と目的
• (04:45) ユースケース図とは
• (05:39) 例題：DVDレンタルのシステム
• (07:07) ユースケース図を書くメリット
• (08:55) エンディング

📢 あなたのご意見をお聞かせください

ユースケーステストについて、あなたはどのような場面で活用していますか？また、ユースケース図を書く際に工夫していることはありますか？ぜひ、あなたの経験や考えを教えてください。

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！