58 Episodes
5 Ratings
Weekly Cadence
2026 First episode About B-Testing.fm B-Testing.fmは、テストや品質の深淵を探求し、現場で役立つ思考のヒントを届ける番組です。「テストは何のために行うのか？」「品質の正体とは？」抽象的で捉えどころのないこれらの言葉をQAエンジニアの視点から紐解き、自分たちの言葉で「言語化」できるようになることを目指します。
【配信日時】 毎週月曜 朝8:00配信
🎙 ホストプロフィール：ブロッコリー
・Developers Summitでのベストスピーカー賞など多数の受賞歴を持つQAエンジニア。
・「Holistic Testing」日本唯一の公式トレーナー
・『Agile Testing Condensed』などの翻訳を通じて、知見を発信中。
開発者、QA、PdMなど、プロダクトを良くしたい全ての方へ。あなたの「テスト観」をアップデートする時間をお楽しみください。
📢 番組に参加する
リスナーの皆様からのお便りをお待ちしています！
・ハッシュタグ：#b_testing （ポストする (https://x.com/intent/post?text=%23b_testing)）
・投稿フォームはこちら (https://forms.gle/otndGhbtwZ2N4eH9A)
・公式サイト (https://b-testing.net/)
Publisher ブロッコリー
Category technology
Language ja
Explicit No
First episode 4 Jan 2026
Latest episode 8 Nov 2026 Latest episodes 58 episodes in the feed.
8 Nov 2026
#58 WACATE2026 冬直前！「プロパティベースドテスト」の中で最も創造的なプロセスに挑む 今回のエピソードでは、2026年12月19日・20日に開催される若手向け宿泊型勉強会「WACATE2026 冬」で担当するセッション「プロパティベースドテスト」についてご紹介します。具体的なテストケースを手動で用意するのではなく、どんな状況でも成り立つ普遍的な性質（プロパティ）を定義してランダムなインプットで検証するこの手法。実装方法の解説はあっても、最も創造性が求められる「プロパティそのものをどう考え出すか」という分析プロセスに焦点を当てた情報は世の中にほとんどありません。そこで今回のワークショップでは、あえてコード実装ではなく「性質を考えること」に特化した、世界でも珍しい実践的なワークをお届けします！
📌 今回のエピソードのポイント
プロパティベースドテストとは： 期待結果を個別に考えず、インプットをランダム生成して仕様の普遍的な性質（プロパティ）を満たすか確認するテスト手法。AIのガードレールとしての活用にも期待できます。
手法導入における最大の壁： プロパティをどうコードに落とし込むかの文献はあっても、最も創造性が必要な「プロパティそのものをどう考え出すか（テスト分析）」を解説する情報が非常に少ないのが現状です。
WACATE2026 冬での新たな挑戦： プログラミングの実装ではなく、「どんな場合でも成り立つ性質とは何か」を考えることに特化した、これまでにない新鮮なワークショップを実施します。
📕 参考文献
WACATE2026 冬〜テスト感のある者たちッ今だッ!!!〜 (https://wacate.jp/workshops/2026winter)
プロパティベースドテスト（ISTQB用語集） (https://glossary.istqb.org/ja_JP/term/-81)
🕒 チャプター
(00:00) オープニング
(01:12) WACATE2026 冬で担当するセッションについて
(01:56) プロパティベースドテストとは？通常のテストとの違い
(03:45) AI開発との相性とガードレールとしての活用法
(04:22) 最大の壁となる「プロパティ」を見つけ出す難しさ
(05:55) 実装ではなく「考える」ことに特化したワークの狙い
(07:24) エンディング
📢 あなたのご意見をお聞かせください
「プロパティベースドテストという言葉を初めて聞いた！」「WACATEのワークショップに参加してみたい！」といった感想はもちろん、テスト自動化に関するお悩みなどもぜひお寄せください。
X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。
お便りフォーム：こちらからお気軽にどうぞ。 (https://forms.gle/otndGhbtwZ2N4eH9A)
フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
1 Nov 2026
#57 【テスト自動化のピラミッド】UIテストを増やしすぎると失敗する？現場目線で考えるテスト戦略と理想の比率 テスト自動化を進めるなかで、「UIテストを作ったものの実行が遅い」「失敗時の原因調査に追われてメンテナンスが追いつかない」といった悩みに直面したことはありませんか？今回は「テスト自動化のピラミッド（Test Pyramid）」をテーマに、UI・サービス・ユニットテストそれぞれの特徴と、なぜピラミッドの形に保つ必要があるのかを現場目線で分かりやすく解説します。実行速度や失敗時の分析コストのリアルな具体例、さらに「テスト自動化の8原則」やGoogleの比率事例などを交えながら、費用対効果の高いテスト自動化戦略を掘り下げます。
📌 今回のエピソードのポイント
テスト自動化ピラミッドの基本： UI・Service・Unitの3層構造と、図に描かれた「ウサギとカメ」「ドルとセント」が示す実行速度・コストの本質を解説。
UIテストが増えると直面する罠： ログインやECサイトのカート操作を例に、実行時間の肥大化やテスト失敗時の原因特定（結果分析）にかかる重いコストをリアルに紐解きます。
費用対効果を高めるテスト戦略： 「テスト自動化の8原則」やGoogleの比率事例（7:2:1）を参考に、なぜユニットテストを厚くし、UIテストを絞るべきなのかを考えます。
📕 参考文献
帝京大学青舎祭 (https://teikyo-gakuyukai.sakura.ne.jp/seishasai/)
Test Pyramid (https://martinfowler.com/bliki/TestPyramid.html)
テスト自動化の8原則 (https://sites.google.com/site/testautomationresearch/test_automation_principle)
🕒 チャプター
(00:00) オープニング
(01:50) テスト自動化のピラミッドと3つのテスト分類
(04:24) なぜUIテストは遅くて高コストなのか？具体例で解説
(10:15) テスト自動化の8原則と「結果分析」のコスト
(11:01) 理想的なテスト比率とピラミッド型の重要性
(12:35) エンディング
📢 あなたのご意見をお聞かせください
皆さんの現場では、ユニットテストやUIテストのバランスをどのように設計・運用していますか？「UIテストのメンテや結果分析に追われて大変だった」「ピラミッドを意識してこんな工夫をしている」など、日頃の悩みや体験談をぜひお聞かせください！
X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。
お便りフォーム：こちらからお気軽にどうぞ。 (https://forms.gle/otndGhbtwZ2N4eH9A)
フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
25 Oct 2026
#56 テストを書きやすいコードはシンプルな設計になりやすい 今回は、「テストを書きやすいコードはシンプルな設計になりやすい」というテーマで、実装における設計とテストコードの関係性について解説します。階乗を計算するプログラムの例題を用いて、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 でのポストをお待ちしています。
お便りフォーム：こちらからお気軽にどうぞ。 (https://forms.gle/otndGhbtwZ2N4eH9A)
フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
Reach and audience Public platform figures. Ratings count people who left a rating, not total listeners.
Spotify 5.0 / 5 5 ratings Shows with a similar audience Research this show Explore Pod Engine's podcast research tools and transcript access.
See plans Is this your podcast? Claim your show to manage its details on Pod Engine.
Claim B-Testing.fm Where this data comes from Each source has its own observation date. These dates do not mean all data was checked at once.
RSS feed Last successful check: 11 Nov 2026 .
Apple Podcasts ratings (US) Snapshot recorded: 20 Oct 2026 .
Spotify ratings Snapshot recorded: 16 Oct 2026 . Host of B-Testing.fm? Claim your podcast to manage its listing and keep your show details accurate.
Claim this podcast Pod Engine is an independent podcast discovery and analytics service and is not affiliated with or endorsed by this podcast. Artwork and show content belong to their owners. Full legal notice .
Explore this showPodcast research with Pod Engine
See plans 
