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/">公式サイト
番組の魅力・推薦
#24 AIコーディング時代のQA：加速する開発の裏で「理解の負債」にどう立ち向かうか？
AIコーディングツールの普及により、コードを生成するスピードは飛躍的に向上しました。しかし、その一方で私たちは「何か」を失いつつあるのかもしれません。今回は、JetBrains社のQA責任者が提唱した「AI時代のQA」に関する考察を紐解きます。コードを書くコストが下がる代わりに増大する「理解の負債」や「意図の負債」、そして変化するバグ修正のコスト曲線など、AIと共に歩むこれからの品質保証活動について、理論と実感の両面から掘り下げていきます。📌 今回のエピソードのポイントAIコーディングツールがもたらす「理解の負債」と「意図の負債」とは？コード量ではなく「1行あたりの理解度」が減るという質的な変化修正コストの要因が「手戻りの量」から「理解のギャップ」へシフトするプロアクティブ（予防型）なQAがAI時代にますます重要になる理由人間とAIツールの「調整コスト」をどう抑えるか📕参考文献QA in the Age of AI-Accelerated Development翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」#9 テストを早めに行うことの大切さ（B-Testing.fmの過去エピソード）#22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説🕒 チャプター(00:00) オープニング(01:31) 翻訳記事の紹介(03:11) コードを書くコストと引き換えに失われる2つの知見(06:34) 「コードが増えた」のではなく「理解が減った」という質的変化(07:33) 修正コスト曲線の変化：理解の負債がコストを押し上げる(11:42) 積極的（プロアクティブ）な品質保証と反応的な品質管理(14:03) コスト関数で考える「人間とAI」の調整コスト(18:55) 感想コーナー：第22回「同値分割法」へのフィードバック(20:25) エンディング📢 あなたのご意見をお聞かせください開発現場でAIコーディングツールを使っていますか？AIが書いたコードの「意図」を読み解くのに苦労した経験や、AI時代のテスト・品質保証について感じていることをぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#39 水準数が異なる直交表の応用的な使い方 ＆ テストスキルと生成AI（LLM）の相性
ソフトウェアテストの設計手法の一つである「直交表」について、因子間で水準数が異なる場合の応用的な使い方を深掘りします。よくある2水準の直交表に、3水準の因子をどうやって組み込むのか、身近なコーヒーショップのカスタマイズを例に具体的手順を解説します。また、後半の質問コーナーでは「テストスキルと生成AI（LLM）の相性」について議論します。LLMに直交表の作成を任せた際の具体的な失敗例を交え、AIが苦手とする「交互作用」の概念や、テスト設計における人間の専門性の重要性に迫る必聴のエピソードです。📌 今回のエピソードのポイント 水準数が異なる直交表の作り方： 2水準の直交表（L8）を拡張し、3水準の因子を組み込む具体的なテクニックを解説します。 直交表の性質とペアワイズ（2因子間網羅）： 拡張した直交表における出現回数の偏りと、それでもペアワイズが満たされる理由について紐解きます。 テストスキルと生成AIの意外な相性： 生成AIに直交表のテストケース作成を依頼するとどうなるか？AIが「交互作用」を理解できずに失敗するメカニズムを鋭く分析します。📕 参考文献 ISTQBテスト技術者資格制度Advanced Level シラバス 日本語版 テストアナリスト Version2012.J01🕒 チャプター (00:00) オープニング (01:27) 水準数が異なる直交表の使い方 (03:00) 説明に使うお題（コーヒーショップのカスタマイズ） (04:09) 直交表の拡張と具体的な当てはめ方 (06:14) 実際に利用する際の注意点（出現回数とペアワイズ） (08:20) L9直交表を用いた別のアプローチ (09:44) 質問コーナー：QAスキルとLLM活用の相性はよかったりしますか？ (12:01) なぜLLMは直交表の作成に失敗するのか？（交互作用の理解） (15:49) エンディング・お知らせ📢 あなたのご意見をお聞かせください生成AI（LLM）をソフトウェアテストの設計に使ってみて、期待通りにいかなかった経験はありますか？また、直交表のような高度なテスト技法を実務でどのように工夫して活用しているか、ぜひ皆さんの知見やエピソードをシェアしてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#38 ソフトウェアテストで使える「直交表」の基本と使い方 ☕️コーヒーショップの例でテスト作成を解説！
今回は、テスト技法の中でも数学的な裏付けを持つ「直交表」について解説します！直交表の定義や歴史（タグチメソッド）から、コーヒーショップのカスタマイズを例にした具体的なテストケースの作り方までを分かりやすく紹介。Pair-wise（2因子間網羅）との違いや、直交表を使う際の注意点など、テスト設計に役立つ実践的な知識が詰まったエピソードです。📌 今回のエピソードのポイント 直交表とは何か： すでに定義されている数学的に裏付けられた表であり、変数をテスト対象となるアイテムに置き換えることで、カバレッジ度合いを達成する組み合わせを生成できます。 直交表の具体的な使い方： コーヒーのカスタマイズ（量、処理、シロップ、トッピング）を例に、因子と水準の整理からテストケースへの割り当てまでをステップバイステップで解説します。 Pair-wiseとの違いと注意点： 直交表は2種類の因子の組み合わせが必ず「同じ回数」登場するためPair-wiseよりケース数が多くなる特徴があります。また、禁則がない「無則」の条件でのみ適用すべきという注意点も紹介します。📕 参考文献 ISTQBテスト技術者資格制度Advanced Level シラバス 日本語版 テストアナリスト Version2012.J01🕒 チャプター (00:00) オープニング (01:23) 直交表とは何か・JSTQBシラバスでの扱い (04:09) 主な直交表の種類（因子と水準） (05:20) 【具体例】コーヒーショップのカスタマイズで直交表を使ってみる (08:59) 直交表の特徴とPair-wise（2因子間網羅）との違い (11:50) 注意点：直交表は無則の時にのみ適用する (12:38) 感想コーナー（ネガティヴ・ケイパビリティについて） (14:28) お知らせ・エンディング📢 あなたのご意見をお聞かせください直交表を使ったテスト設計について、皆さんの現場での活用例や「ここが難しい！」といったお悩みがあればぜひ教えてください！感想コーナーへのコメントも大歓迎です。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#37 「1人目QAの自己投影」から考える、組織全体で自律的な品質保証活動を育むアプローチ
今回は、ブログ記事「1人目QAの自己投影」をテーマに、1人目QAエンジニアが組織に与える影響や陥りがちな課題について掘り下げます。テスト技術の軽視やコスト調整のみに頼る危険性を指摘しつつ、QAエンジニアの増員や組織拡大だけが正解ではない理由を解説。開発者やプロダクトマネージャーをも巻き込み、組織全体が自律して品質保証活動について考えられる状態を作るための理想的なアプローチについて、イベントで寄せられた質問への回答を交えながら語ります。📌 今回のエピソードのポイント 「1人目QAの自己投影」の危うさ： 品質保証のあり方をQA組織のやり方に固執させてしまうリスクや、1人目QAという強いソースが抜けた後に組織が直面する課題について考察します。 組織が自律する品質保証活動： QAエンジニアの存在感を高めることだけを目指すのではなく、他職種も含めた組織全体が自律して品質に向き合える状態を作る重要性を説きます。 QA文化をじわりじわりと根付かせる方法： トップダウンでの押し付けを避け、共感してくれるチームと共に成功体験を作り、それを言語化して広げていく具体的なステップを解説します。📕 参考文献 1人目QAの自己投影-誰かの”品質保証”が独立したソースへ変容してしまうとき ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求するプロダクトマネジメントを実現するぞ 少数精鋭QAのリアル：プロダクトが増え続ける組織で、QAはどう戦うか（GENDA Tech Talk #4）🕒 チャプター (00:00) オープニング (01:31) 記事「1人目QAの自己投影」の紹介と共感 (05:44) プロダクトマネジメントの事例から学ぶ1人目の罠 (08:19) 1人目QAが陥りがちな課題（私見） (12:22) 質問コーナー：QA文化を開発チーム全体に根付かせるには？ (15:08) エンディング📢 あなたのご意見をお聞かせください今回は1人目QAの役割や、組織全体で品質に向き合う文化の作り方についてお話ししました。あなたが考える「理想的な品質保証活動のあり方」や、チームに品質文化を根付かせるための工夫などがあれば、ぜひご意見をお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#36 無則・有則を知る：テストケース削減の落とし穴と技法の使い分け
テストケースを効率的に削減するために「Pair-wise（オールペア法）」や「直交表」をなんとなく使っていませんか？実は、条件の組み合わせ方によっては、絶対に削ってはいけない重要なケースを漏らしてしまう危険があります。今回は、クラシフィケーションツリー法の続編として、テスト設計において極めて重要な概念である「無則（むそく）」と「有則（ゆうそく）」の違いを解説します。コーヒーショップの割引条件を例に、なぜその技法を選んだのか、その根拠をロジカルに説明できるようになるための知識をお届けします。📌 今回のエピソードのポイント「無則」と「有則」の定義と、テスト設計に与える影響Pair-wise法で「期待結果のバグ」を見逃してしまうメカニズム条件が独立している場合と、掛け合わせで結果が変わる場合の技法の適正ベテランでも陥りがちな「テスト削減」の盲点質問コーナー：小規模案件でもテスト技法を検討すべき理由🕒 チャプター(00:00) オープニング(01:31) コーヒーショップの例題：複雑な割引条件を整理する(04:06) Pair-wise法でテストを剪定してみる(05:37) 期待結果の検証：削減によって失われた「450円」のケース(06:23) 「無則」な関係：各条件に影響がない場合の削減手法(08:27) 「有則」な関係：組み合わせが重要な場合の削減手法(10:21) 無則・有則と各手法の適性まとめ(12:31) 質問コーナー：テスト技法を使うかどうかの判断に迷うときは？(15:18) エンディング📢 あなたのご意見をお聞かせください皆さんはテストケースを削減した結果、大事な組み合わせを漏らしてしまった経験はありますか？また、「ここは技法を使うまでもない」と判断する基準は何でしょうか？ぜひ感想を聞かせてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#35 網羅基準を用いてテストを剪定する：クラシフィケーションツリー技法の応用
前回までの「クラシフィケーションツリー技法」の基本編に続き、今回は作成したテストケースをどのように絞り込み（剪定し）、効率化していくかについて深掘りします。「網羅基準」という言葉は知っていても、実務でどう使い分けるべきか迷っている方も多いのではないでしょうか。Each ChoiceからPair-Wise、そして重要度に応じた「網羅基準の組み合わせ」まで、具体的なコーヒーのカスタマイズ例を用いて分かりやすく解説します。📌 今回のエピソードのポイントクラシフィケーションツリーにおける4つの主な網羅基準ケース数と網羅率のトレードオフ：Each ChoiceとPair-Wiseの違い「All Combinations」をすべて実行すべきかどうかの判断新機能は手厚く、既存機能は効率的に。網羅基準を「組み合わせる」応用術感想コーナー：エピソード17「言語化しない状態の大切さ」に寄せられた「わからない」を大事にする現場の話📕 参考文献#17 言語化しない状態の大切さ（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:38) クラシフィケーションツリーにおける主な網羅基準(02:51) 「Each Choice」：最低1回はすべての値を使用する(04:45) 「Pair-Wise」：2因子間の組み合わせを網羅する(08:02) 「All Combinations」：すべての値を組み合わせる全網羅(08:38) 網羅基準の応用：重要度に応じたテストケース数の調整(10:50) 感想コーナー：言語化しない状態の大切さ(12:02) エンディング📢 あなたのご意見をお聞かせくださいみなさんの現場では、テストケースを絞り込む際にどのような判断基準を使っていますか？「とりあえずPair-Wise」になっていませんか？また、新機能リリースの際に「ここだけは手厚く網羅した」というエピソードがあれば、ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#34 クラシフィケーションツリーのテストケースを「機械的」に導き出す極意
前回の「クラシフィケーションツリー」の作成解説に続き、今回はテスト編です。「ツリーは書けたけれど、そこからどうやってテストケースに落とし込めばいいの？」という疑問を解消します。実は、このテストケースの具体的な導き出し方について詳しく書かれた文献は、日本語ではほとんど存在しません。今回は、独自に言語化した「機械的にテストケースを作成するステップ」を、コーヒーショップのカスタマイズという身近なお題を使って徹底解説します。ディシジョンテーブル（決定表）にも通ずる、漏れのない組み合わせの作り方をぜひマスターしてください。📌 今回のエピソードのポイント文献には載っていない？テストケース作成の具体的な手順「最下層のクラスから直線を引く」という最初の一歩漏れを防ぐための鉄則：「1つのケースで同じ線は一度しか通らない」効率的な組み合わせの探し方：1つ上の階層に戻って別の道を進むディシジョンテーブルとの共通点と、クラシフィケーションツリー技法ならではの視覚的メリットリスナーからの感想紹介：Geminiを活用した「プロポーザル添削Gem」の反響📕参考文献#10 プロポーザル添削Gemを作成しました（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:38) 本編：クラシフィケーションツリーのテストケースを機械的に作る(01:51) 説明に使うお題（コーヒーショップのカスタマイズ）(03:18) ステップ1：最下層のクラスの下に直線を引く(03:43) ステップ2：取りうる組み合わせに点を打って表現する(10:36) 感想コーナー：第10回「プロポーザル添削Gem」へのフィードバック(12:01) エンディング📢 あなたのご意見をお聞かせください皆さんは、テストの組み合わせを考えるとき、クラシフィケーションツリーとディシジョンテーブルのどちらをよく使いますか？今回の「機械的な作り方」を聴いてみての感想や、実際に試してみた結果をぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#33 Step by Stepで学ぶ「クラシフィケーションツリー」の作り方
今回から新しいテスト設計技法シリーズがスタートします。取り上げるのは「クラシフィケーションツリー技法」。テスト対象のデータ領域を樹形図で可視化するこの手法について、初心者の方でもすぐに実践できるよう、コーヒーショップのカスタマイズを例にステップ・バイ・ステップで詳しく解説します。📌 今回のエピソードのポイントクラシフィケーションツリー技法の定義とメリット基本用語「ルート」「クラシフィケーション」「クラス」の役割コーヒーショップの複雑な価格設定をツリーで整理する手順「最下層は必ずクラスにする」など、作成時の重要なルール感想紹介：テスト設計コンテスト（ASTER）の魅力について📕参考文献JSTQB用語集🕒 チャプター(00:00) オープニング(02:06) クラシフィケーションツリー技法とは何か(03:08) 完成イメージと用語（ルート・クラス等）の解説(03:46) 実践！コーヒーの価格テストを題材にしたツリー作成(05:02) ステップ1：確認したいこと（ルート）を一番上に書く(05:28) ステップ2：テストに使う条件（クラシフィケーション）を抽出する(06:47) ステップ3：条件に対応する要素（クラス）を書き出す(08:54) 最下層の「クラス」がテストで使う値になる(09:55) 感想コーナー：テスト設計コンテストへの興味(11:24) エンディング📢 あなたのご意見をお聞かせください「テストデータの整理に図解を使っていますか？また、皆さんのこだわりのコーヒーカスタマイズがあればぜひ教えてください！」X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#32 E2Eの自動テスト、どう作る？目的で使い分けるシナリオ設計術
E2E（エンド・ツー・エンド）の自動テストを作成する際、一つの長いシナリオにするか、細かく分割するか迷ったことはありませんか？今回は「テストの目的」に焦点を当て、ピザの注文システムを具体例に、状況に応じた最適なテストの組み方について深掘りします。テスト実行時間の短縮と、不具合の検出精度を両立させるためのヒントをお届けします。📌 今回のエピソードのポイントE2Eテストの定義と前提条件（UI経由・実データ接続）一連の業務遂行を確認したい時の「長めシナリオ」のメリット不具合検出を優先したい時に「シナリオを分割」すべき理由後続工程のバグを隠さないための、直接URLアクセスの活用術質問コーナー：スプリント開発における「QAの待ち時間」の厳密な評価は必要か？🕒 チャプター(00:00) オープニング(01:32) E2E自動テストの作り方は「目的」で変わる(03:27) シナリオを「長くする」か「分ける」かの判断基準(05:01) まとめ：最適なテスト設計のために(05:32) 質問コーナー：QAの待ち時間を厳密に評価する方法はある？(08:01) エンディング📢 あなたのご意見をお聞かせください自動テストのシナリオ設計で、あなたが「これだけは譲れない」というこだわりや、逆に失敗してしまった経験などはありますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#31 デシジョンテーブルの「圧縮」術：効率と品質を両立させるパターン削減の極意
前々回の「デシジョンテーブルの作り方」に続き、今回は作成したテーブルをどのように効率化していくか、その具体的なテクニックを深掘りします。テストケースをロジカルに、かつ「機械的に」削るための「簡略化」と「禁則」の考え方を解説。ただ削るだけでなく、あえて「削らない」という戦略的な判断基準についても触れています。📌 今回のエピソードのポイントデシジョンテーブルにおける「簡略化」の定義と手順「ハイフン（ー）」を用いたパターンの圧縮方法期待結果が異なる場合に陥りがちな簡略化の罠「禁則」を用いて物理的に不可能なパターンを削除する100件を超える膨大なテストケースへの向き合い方JIS規格と実務的な「見やすさ」を両立する記法比較🕒 チャプター(00:00) オープニング(01:43) 本編：デシジョンテーブルのパターンを機械的に削る(01:59) 「簡略化」によるパターン削減の考え方(04:36) 実践！ハイフンを使った列の圧縮プロセス(07:26) 「禁則」による不要な列の削除(09:21) あえて圧縮しない？戦略的な判断とTips(11:14) デシジョンテーブルの様々な表記方法（JIS規格 vs オススメ）(12:36) 質問コーナー：テストケースが100件を超えた時の対処法(15:11) エンディング📢 あなたのご意見をお聞かせくださいあなたの現場では、デシジョンテーブルの記法はどうされていますか？JIS規格に則った「Y/N/X」派ですか？それとも、今回オススメしたような「◯/空欄」のような見やすさ重視派ですか？ぜひあなたのこだわりを教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#30 GWの振り返り：Podcast EXPOとScrum Fest Niigata 2026で見つけたコミュニティの熱量
ゴールデンウィーク中に足を運んだ2つの大きなイベント、Podcast EXPOとScrum Fest Niigata 2026の模様をお届けします。Podcastコミュニティの熱量を感じた展示から、QA・テストの比率が高い新潟でのカンファレンス体験まで、現場で感じたリアルな刺激と発見を共有します。📌 今回のエピソードのポイント Podcast EXPO 2026の熱気： 旧校舎を活用したノスタルジックな会場で感じた、Podcastコミュニティの多様性と「即売会」のような活気ある雰囲気について語ります。 注目のPodcast番組と活動： 公共訴訟を扱う「CALL4」や、問いをテーマにした冊子が印象的な「ほんのれんラジオ」など、ブースで出会った魅力的な番組を紹介します。 Scrum Fest Niigataの魅力： 実行委員兼登壇者として参加した新潟でのカンファレンス。地元のお寿司や日本酒、オリジナルビールといった最高のホスピタリティと、QA・品質への関心の高さを振り返ります。📕 参考文献 PODCAST EXPO #306 Podcast EXPOでブース出すよ&久々のモヤッと話(りっちゃ・りょかちのやいやいラジオ) 公共訴訟ラジオ｜社会を動かす裁判の話 ほんのれんラジオ Scrum Fest Niigata 2026🕒 チャプター (00:00) オープニング (00:54) PODCAST EXPO 2026：コミュニティ主導の熱気と出会い (04:09) Scrum Fest Niigata 2026：品質と新潟の食を愉しむカンファレンス (07:23) エンディング📢 あなたのご意見をお聞かせください今回のGW、皆さんはどのように過ごされましたか？Podcast EXPOに行かれた方の感想や、Scrum Fest Niigataでの発表を聴いてくださった方のフィードバックなど、ぜひお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#29 デシジョンテーブルを機械的に作る：掛け算・割り算・引き算で漏れをなくす方法
「最新のAIテスト」も、紐解いてみればその根底にあるのは古くから大切にされているテスト設計技法だったりします。今回は、そんな基本でありながら奥が深い「デシジョンテーブル（決定表）」がテーマです。なんとなく思いついた順に条件を書き出していませんか？それでは考慮漏れを防ぐことはできません。本エピソードでは、パズルを解くように「機械的」にデシジョンテーブルを作成し、仕様の曖昧さまでをも炙り出すプロのテクニックを徹底解説します。📌 今回のエピソードのポイント「足し算」の罠：思いついた組み合わせを足していく作り方が、なぜ危険なのか3つのステップ：掛け算で全パターンを出し、割り算で割り当て、引き算で削る作成方針禁則と仕様の穴：ありえない組み合わせ（N/A）や、期待結果が不明な箇所を見つける重要性モデリングの効果：境界値分析やデシジョンテーブルを「図式化」することで関係者と認識を合わせるコツ🕒 チャプター(00:00) オープニング(00:25) JaSST'26 Tokyoに参加して感じた「テスト技法」の大切さ(01:39) デシジョンテーブル（決定表）の基本(03:51) 多くの人が陥る「間違った作成手順」(05:37) 正しい作成方針：掛け算・割り算・引き算(06:19) 実践！全パターンを機械的に書き出すステップ(09:12) 期待結果の記入と「禁則（ありえないパターン）」の扱い(11:42) 作成過程で見つかる「仕様の曖昧さ」(14:18) 質問コーナー：境界値の考慮漏れを防ぐには？(16:56) エンディング📢 あなたのご意見をお聞かせください皆さんはデシジョンテーブルを作る際、最初から全パターンを書き出していますか？それとも、重要そうなところから埋めていますか？皆さんの「マイルール」をぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#28 テスト漬けの2日間！1泊2日の合宿型ワークショップ「WACATE」のススメ
「ソフトウェアテストの勉強をしたいけれど、座学だけでは物足りない」「社外のエンジニアと深く交流したい」――そんな悩みを持つ若手エンジニアにぴったりのイベントを紹介します。今回は、20年近い歴史を持つ合宿型ワークショップ「WACATE（ワカテ）」を特集。実行委員長を務める視点から、イベントの魅力やユニークなコンセプト、さらには次回開催（2026年夏）の詳細までたっぷりとお届けします。Spotifyでご視聴の方は、会場の様子や参加者データなどのスライドを映像付きでご覧いただけます。📌 今回のエピソードのポイント「手を動かす」がメイン： 登壇者の話を聞くだけでなく、グループワークで徹底的に考え抜くスタイル夏と冬で異なるテーマ： 「狭く深く」掘り下げる夏と、「広く浅く」発見を得る冬データで見るWACATE： 初参加者が約半数！全国から多様な業種のエンジニアが集まる理由破格の参加費： 宿泊・4食付きで3万円前後という、コミュニティ運営ならではのコストパフォーマンス次回予告： 2026年6月27日(土)・28日(日) 幕張で開催決定！📕参考文献WACATE公式サイトWACATE 2026 夏 〜テスト千本ノック！〜 開催概要ページ#14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:50) 合宿型ワークショップ「WACATE」を開催します！(05:06) WACATEというコミュニティの概要と「はじまり」(08:20) コンセプトと夏・冬のスタイルの違い(09:47) データ公開：参加者の属性やリピート率、居住地域(12:52) 怒涛の2日間スケジュールと、宿泊型ならではの交流(13:27) 次回（WACATE 2026 夏）の開催概要と参加費について(17:34) 感想コーナー：第14回「失敗の許容度」への反響(18:43) エンディング📢 あなたのご意見をお聞かせください今回の放送を聞いて、WACATEに興味を持っていただけましたか？「合宿形式の勉強会に参加したことがないから不安」「こんなテーマを扱ってほしい」など、あなたの本音をお待ちしています！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#27 自然言語に境界値分析を適用する：仕様の曖昧さをあぶり出す技術
前回の「境界値分析（BVA）」の基本に続き、今回は一歩踏み込んで「数値ではないデータ」や「自然言語（日本語）」にこの技法をどう適用するかを深掘りします。「〜まで」「〜から」といった日常的な言葉に潜む曖昧さが、いかにして不具合の種になるのか。テスト技法を単なる「確認作業」としてではなく、仕様の不備を見つける「議論のツール」として活用するための考え方をお届けします。📌 今回のエピソードのポイント数値でなくても「順序付け」ができれば境界値分析は活用できる「8:00から22:00まで」の「22:00ちょうど」は稼働時間か、休止時間か？同じ「新横浜駅まで」でも、文脈によって意味が変わる日本語の怖さと面白さテスト設計技法を使って、開発の早い段階で仕様の曖昧さを指摘するメリット【質問コーナー】開発者がテストを行う際に、絶対に落としてはいけない「テストの意図」📕 参考文献ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03🕒 チャプター(00:00) オープニング(01:30) 境界値分析（BVA）の定義を再確認する(02:12) 自然言語（数値以外）への適用例：背の順で並ぶクラス(03:11) 「以上・以下」「から・まで」に潜む境界の曖昧さ(03:54) 東海道新幹線の例で考える、文脈による境界値の変化(06:16) テスト技法を「仕様の曖昧さを指摘する」ために使う(08:05) 質問コーナー：開発者がテストの一部を担う際に気をつけること(10:11) エンディング📢 あなたのご意見をお聞かせください皆さんは、仕様書の「〜まで」という表現に悩まされた経験はありませんか？あるいは、数値以外の項目にテスト技法を当てはめてみた事例などがあれば、ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#26 意外と奥が深い「境界値分析」〜100%のカバレッジでもバグが出る理由〜
今回は、テスト設計の基本中の基本でありながら、実は奥が深い「境界値分析（BVA）」を深掘りします。なぜ「パスワードの文字数チェック」のような単純な仕様でも、テストケースが膨大になってしまうのか、そしてどうすれば効率的に、かつ確実にバグを見つけられるのかを解説します。「不等号ひとつ」のミスが命取りになる開発現場で、明日から使える実践的な思考プロセスをお届けします。📌 今回のエピソードのポイントなぜ「全数テストは不可能」なのか？テストの7原則から考える境界値分析を正しく行うための4つの実践ステップコードカバレッジが100%でもバグを見逃してしまう落とし穴仕様書には書かれていない「システム上の境界」と「精度の問題」開発者とQAエンジニア、それぞれのテストの使い分けと理想的な関係性📕 参考文献ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03🕒 チャプター(00:00) オープニング(01:44) 境界値分析とは何か？(04:22) 境界値分析の具体的な実践ステップ(06:14) なぜ境界値をテストする必要があるのか：不等号のミスを防ぐ(07:44) カバレッジ100%の罠：テスト設計の重要性(09:56) システム上の境界値と「有効桁数」の落とし穴(13:17) 質問コーナー：エンジニアとQAのテストの使い分け(15:09) エンディング📢 あなたのご意見をお聞かせください皆さんの現場では、境界値のテストはどこまで厳密に行っていますか？「カバレッジは取れているのにバグが出た」という苦い経験や、開発者とQAの役割分担について思うことなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#25 【5月は登壇ラッシュ！】スクフェス新潟、GENDA、Flexy…QAエンジニアが語る「シフトレフト」の発表をしていきます！
今回のエピソードでは、5月に予定されている3つの大きな登壇イベントについて詳しくご紹介します。10Xでの実践を通じた「QA＝テスト」という呪縛を解くためのアプローチや、マイクロサービスにおけるQAの進め方についての質問にもお答えします。📌 今回のエピソードのポイント【Scrum Fest Niigata 2026】V字モデルの右側にしわ寄せがいかないチーム作り【GENDA Tech Talk #04】少数精鋭のQA組織はどう戦うべきか？【Flexy meetup】10x流「シフトレフト」な品質保証を1時間みっちり深掘りリスナー質問：複数のマイクロサービスが連動する変更、QAはどう進める？📕参考文献ピタゴラスイッチテキシコーScrum Fest Niigata 2026GENDA Tech Talk #4「少数精鋭QAのリアル：プロダクトが増え続ける組織で、QAはどう戦うか」Flexy meetup「10X流・QAと開発者がシームレスに連携するシフトレフトな品質保証アプローチとは」🕒 チャプター(00:00) オープニング(01:59) 登壇告知その1：Scrum Fest Niigata 2026(05:30) 登壇告知その2：GENDA Tech Talk #04(07:30) 登壇告知その3：Flexy meetup(09:24) 質問コーナー：マイクロサービス連動時のQA戦略(13:25) エンディング📢 あなたのご意見をお聞かせください「テストが最後に詰まってリリースが遅れる……」そんな「右側のしわ寄せ」に悩んだ経験はありませんか？今回の登壇内容への期待や、あなたのチームでのQAの悩みなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#23 ソフトウェアレビューも「プロセス」で考えよう：属人化の解消とAI活用のコツ
日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューをJSTQBの定義する「静的テスト」として捉え直し、あえてプロセスに分解することで見えてくるメリットについて深掘りしました。属人化を防ぐための「レビュー・アーキテクチャ」の考え方や、AIに精度の高いレビューをさせるためのプロンプトのヒントなど、現場で役立つ視点をお届けします。📌 今回のエピソードのポイントレビューは立派な「テスト（静的テスト）」であるという認識JSTQBのレビュープロセスにおける「個々人のレビュー」をどう言語化するかテストプロセス（分析・設計・実装・実行）をレビューに応用するメリットレビューの「目的」と「観点」を分けることで属人化を防ぐAIにレビューを依頼する際、丸投げよりも「観点」指定が重要な理由📕 参考文献ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02レビューでは何を確認するといいのかな？さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！(JaSST Review'22発表資料)🕒 チャプター(00:00) オープニング(01:31) ソフトウェアレビューにおけるプロセスの重要性(02:01) レビューは「静的テスト」の1つである(03:22) JSTQBのレビュープロセスと残る疑問(04:39) テストプロセスを参考にレビューを分解してみる(06:15) レビューアプローチの全体像と属人化の課題(10:52) AIのレビュー精度を飛躍的に高めるヒント(12:51) 質問コーナー：ステークホルダー間での形式化はできている？(14:02) エンディング📢 あなたのご意見をお聞かせくださいみなさんの現場では、レビューの「観点」や「手順」は明文化されていますか？それとも「経験豊富なベテランの勘」に頼っている部分が大きいでしょうか？レビューにおける工夫や悩みなど、ぜひ教えてください！X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説
今回は、テスト設計技法の代表格である「同値分割法」をテーマにお届けします。「なんとなく」でテスト値を選んでいませんか？「なぜその値を選んだのか」を論理的に説明できることは、QAエンジニアにとって非常に重要なスキルです。47都道府県のプルダウンを例に、目的やリスクに応じた5つのアプローチを紹介しながら、現場で役立つ思考プロセスを整理していきます。📌 今回のエピソードのポイント同値分割法の定義とメリット都道府県のテストで「沖縄県」や「神奈川県」を選ぶそれぞれの理由テストケース作成時に欠かせない「理由を言語化する」ことの大切さ5つの回答例（スクロール、印刷反映、文字数、地域、コードの構造）リスナーからの感想紹介：QAとAIが共創する「建設的相互作用」の可能性📕 参考文献#14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回）🕒 チャプター(00:00) オープニング(01:24) 同値分割法とは何か？(02:45) 例題：都道府県の項目、何個テストする？(03:25) 同値分割の手順と「理由」の重要性(04:30) 5つの回答例：スクロールや配列エラー、出力結果、文字数、地域、全件テストの使い分け(10:20) 感想ポスト紹介：QAとAIのシナジーと仮説検証(12:26) エンディング📢 あなたのご意見をお聞かせください皆さんは「都道府県」の項目をテストするとき、いつもどのような狙いで値を選んでいますか？「自分ならこう分ける！」というこだわりや、今回紹介した手法への感想など、ぜひお聞かせください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#21 テスト設計技法は「楽をするため」にある？省思考でクリエイティブな仕事に向き合う方法
今回は「テスト設計とテスト設計技法」の基本について深掘りします。「なぜわざわざ設計が必要なのか？」という根本的な問いから、技法を習得することで得られる意外なメリット、そして数ある技法の効果的な学習順序まで、QAの現場で役立つエッセンスを凝縮してお届けします。📌 今回のエピソードのポイント「全数テストは不可能」だからこその設計： 時間制約の中で、効果的・効率的に不具合を見つけるための戦略。「効果」と「効率」の違いを意識する： 多くのバグを出すことと、かけた時間に対してバグを出すことのバランス。技法による「省思考（しょうしこう）」のススメ： 信号機の色の順番を考えなくていいように、標準化によって脳のメモリを解放し、より独創的な仕事へ集中する。技法の学習ロードマップ： 同値分割・境界値分析といった「基本」から始めるべき理由。質問コーナー： 開発経験はQAに必須？テスト観点を養い、技法を使い分けるための「数学の公式」のような考え方。📕 参考文献Newbeeさんの動画「AI時代の品質保証最前線 決定論→確率論時代に変わるQAの在り方」スライド「テスト設計技法をチョット俯瞰してみよう」書籍『現代品質管理総論』書籍『ソフトウェアテスト技法練習帳～知識を経験に変える40問～』🕒 チャプター(00:00) オープニング(01:53) 今回のテーマ：テスト設計とテスト設計技法(02:04) テスト設計はなぜ必要なのか？(03:08) テストにおける「効果」と「効率」の定義(04:41) 技法を用いることで「省思考」を実現する(07:42) テスト設計技法を学ぶべき順番(09:40) 質問コーナー：技法を使い分けられるようになるまでの道のり(13:47) エンディング📢 あなたのご意見をお聞かせください皆さんがテスト設計技法を学んでいて「これは目から鱗だった！」というエピソードや、逆に「使い分けが難しい……」と感じている部分はありますか？ぜひ教えてください。X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#20 まだテストエンジニアの価値を知らないチームに入り込むための方法
「QAエンジニアって本当に必要？」「開発者がテストすればいいんじゃない？」そんな声が聞こえてきそうな現場に、最初のQAとして飛び込むのは勇気がいるものです。今回は、テストの価値がまだ浸透していないチームにおいて、どのように信頼を勝ち取り、スムーズにテストプロセスを導入していくべきか、具体的な戦略とコミュニケーションのコツを深掘りします。📌 今回のエピソードのポイント不具合分析から始めるプロセス導入：いきなり理想を語るのではなく、目の前の痛み（障害）を入り口にする戦略「なぜやらなかったの？」は禁句：相手を責める「評論家」ではなく、共に悩む「当事者」として振る舞うヒアリング術主語を「私」にする意思表明：テスト設計ができないことへの「困りごと」を伝えることで、周囲の協力を引き出すボトムアップ改善の鉄則：大規模組織で提案を通すなら、まずは「勝手にやって実績を作る」のが近道？📕 参考文献書籍『FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48のパターン』🕒 チャプター(00:00) オープニング(01:37) テストエンジニアの価値をチームに伝えるには(02:39) テストプロセス導入の第一歩は「不具合・障害分析」から(04:17) チームに受け入れられるコミュニケーションのコツ(09:00) 質問コーナー：大規模組織でのボトムアップな改善提案(10:26) 参考文献『Fearless Change』に見る改善のパターン(12:26) エンディング📢 あなたのご意見をお聞かせください新しくチームに加わった時や、新しいプロセスを導入しようとした時、あなたが意識している「入り込み方」の工夫はありますか？X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：こちらからお気軽にどうぞ。フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
こちらもおすすめ
シットとシッポ
Dos Monosの荘子itと哲学者の福尾匠によるPodcast 毎週月曜更新。 📍番組のフォローをお願いします ・ Spotify ・Apple Podcasts 📣疎の街 コチラからお越しください 📍X シットとシッポ @shitshippo 荘子it @ZoZhit 福尾匠 @tweetingtakumi
LISTEN NEWS
LISTENは、AI文字起こしとコミュニティで、ポッドキャストを「聴く・配信する・つながる」ためのプラットフォームです。 公式番組「LISTEN NEWS」では、開発の裏話や近況も交えつつ、最新情報をお届けします。 LISTENはこちら→ https://listen.style/
私より先に丁寧に暮らすな
東京の歌人・上坂あゆ美と、京都の僧侶・鵜飼ヨシキによる雑談配信。人生の呪いからファミレスの好きなメニューの話まで幅広くお届け。 【初めての方におすすめ回】 #30 お菓子が人間だったら誰と付き合いたいか真剣に考える https://open.spotify.com/episode/751EzuNXjpgP2i53P7OtX7?si=XxN2eddURsas_JWE6KFu-A #163 恋愛ってマーージでクソだと思っている人の話 https://open.spotify.com/episode/1WgeglhRT5GQfqzkBO2bNF?si=1l0b2OBlTJq ▼ご意見ご感想は #よりすな ▼お悩みや質問はコチラまで https://forms.gle/1bqryhYcDWt334jZ7 ▼番組公式SNS https://x.com/yori_suna ▼番組へのお問い合わせはコチラまで yorisuna24@gmail.com ▼ポッドキャストの書き起こしサービス「LISTEN」はこちら https://listen.style/p/yorisuna?Egq5AoBB
深井・けんすうのまぼろし会議
深井龍之介とけんすうによる、1週間で消えるポッドキャストです。その時々で2人が話したいことを喋ります。 # 利用規約はこちら https://coten.co.jp/blog/news/2638/ #視聴金額 66万円（税込） # Podcastに出ている人 深井龍之介：株式会社COTEN（https://coten.co.jp/）代表取締役。 けんすう：起業家・エンジェル投資家・ アル株式会社（https://alu.co.jp/）代表取締役。 https://listen.style/p/maboroshi_kaigi?1WKenxzH
桃山商事
コミュニケーション、男性性、恋愛、人間関係、ジェンダー、ケア、孤独、性欲、会社、友情、老い……メンバーがその時々で気になったテーマを１つ設定して、モヤモヤを言語化していくNEOな座談Podcastです。2011〜2016年「二軍ラジオ」(ApplePodcast)、2017〜2024年「恋愛よももやまばなし」(ニコ生→Podcast)を配信していました。清田隆之(文筆業)、森田(会社員)、ワッコ(会社員)、さとう(会社員)の４人でお届けします。
IBUKI STATION
ここはアウトドア向けGPSトラッキング「IBUKI」にまつわる人々が集まる場所。 トレイルラン、登山、冒険、ランニング、自転車、ロゲイニング、、 スタイルは数あれど、共通しているのは自然を楽しみ、そして人とのつながりも楽しむ姿勢。 自然を目一杯楽しみ、苦しみながら、人と接する喜びにも気付く。 アウトドアを満喫するみなさんが、ほっとできるIBUKI STATIONです。 IBUKI https://ibuki.run/ 近藤淳也 IBUKIを提供する株式会社OND代表。ポッドキャストプラットフォーム「LISTEN」も展開 桑原佑輔 OND所属。IBUKI事業担当営業・テクニカルディレクター 中川和美 OND所属。IBUKI担当。トレイルランナー