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アプリでのフォローをぜひお願いします！
#49 【ユースケーステスト】全体像とユースケース図の役割を徹底解説
今回のエピソードでは、ソフトウェアテストの手法の一つである「ユースケーステスト」について、その全体像から、ユースケース図の役割、そしてユースケース図を書くメリットまで、詳しく解説しています。特に、ユースケース図がどのようにシステム開発に関わる人々の認識を合わせる役割を果たすのか、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アプリでのフォローをぜひお願いします！
#48 『Writing Code vs. Shipping Code』AIコーディングツールは本当に開発の生産性を上げたのか？
AIコーディングツールの普及によって開発の現場はどう変わったのか？今回は、AIツールの進化と生産性・リリースへの影響を多角的に分析した海外論文『Writing Code vs. Shipping Code』をご紹介します。コード生成量が劇的に増える一方で最終的なリリース量にはどのようなギャップが生じているのか、またアプリストアで起きている「供給過多と使われないアプリの増加」というリアルな現実について、数値データを交えて詳しく解説します。📌 今回のエピソードのポイント AIコーディングツールの3つの世代分類： オートコンプリート型、対話型エージェント、自律型エージェントというAI開発ツールの進化過程とその特徴を整理します。 コード生成量とリリースの大きなギャップ： AI導入で変更行数が約8.5倍に急増しても、実際のリリース量は+20%程度にとどまる「コードの減衰傾向」を明かします。 アプリ供給過多と品質管理の重要性： ストアへのアプリ公開数が急増する一方で購入・利用されないアプリが増加しており、作成後の品質確認や運用がいかに重要かを提示します。📕 参考文献 Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools🕒 チャプター (00:00) オープニング (01:31) 海外論文『Writing Code vs. Shipping Code』の紹介とAIツールの世代分類 (05:04) AIによるコード大量生成とリリースまでの「減衰傾向」 (09:18) アプリ公開数の急増と「使われないアプリ」が増える現実 (15:49) エンディング📢 あなたのご意見をお聞かせください今回のエピソードで紹介した海外論文の調査結果を聞いて、ご自身の職場や開発現場での実感と比べていかがでしたでしょうか？「うちのチームでも似た傾向がある」「自分の感覚とは少し違う」など、ぜひ皆さんのご意見やご感想をお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#47 【状態遷移テスト】ラウンドトリップカバレッジ徹底解説！具体例・メリットからAI生成の落とし穴まで
今回のテーマは、状態遷移テストにおける「ラウンドトリップカバレッジ」です。ISTQBシラバスの定義をベースに、ストップウォッチの具体例を用いながらテストケースの導出方法や網羅条件をわかりやすく解説します。さらに、状態間を行き来する不具合の検知やチーム内での認識合わせといったメリットに加え、認知度の低さや生成AI（GeminiやChatGPT）に丸投げした際の精度・ケース欠損の注意点についても深掘りします。📌 今回のエピソードのポイント 定義と具体例でのケース導出： ISTQBシラバスに基づく定義と、ストップウォッチの遷移図を用いた7つのテストケース導出プロセスを解説。 導入メリットと認識合わせの容易さ： 状態間を行き来する複雑な不具合の検出に強く、図をなぞりながらチームで網羅性を共有できる利点を紹介。 認知度の低さと生成AIの限界： 資料が少なくAIに任せるとテストケースが欠損する実態を踏まえ、人間が自ら設計する重要性を考察。📕 参考文献 コードを書くことだけが技術力じゃないーー10X風間氏が語る、"品質を設計する"エンジニアの仕事 - アンドエンジニア 状態遷移テスト（state transition testing） - ISTQB Glossary ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03🕒 チャプター (00:00) オープニング (01:38) 状態遷移テストとカバレッジのおさらい (02:52) ラウンドトリップカバレッジとは (04:12) ストップウォッチ例で見るテストケース導出 (06:17) ラウンドトリップカバレッジの対象外となるケース (07:48) ラウンドトリップカバレッジのメリット (08:55) 認知度の低さと生成AI活用の注意点 (10:30) まとめ・現場での活用に向けて (11:05) エンディング📢 あなたのご意見をお聞かせください皆さんは状態遷移テストでラウンドトリップカバレッジを活用したことがありますか？また、テスト設計で生成AIを使った際の精度や工夫などもぜひお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#46 【状態遷移テスト】Nスイッチカバレッジ（0・1・2スイッチ）の考え方とテストケース作成
状態遷移テストにおける「Nスイッチカバレッジ」について、具体的な図解やお題を交えながらわかりやすく解説します。0スイッチカバレッジ（遷移カバレッジ）と1スイッチカバレッジ・2スイッチカバレッジの違いや、それぞれのテストケースの考え方、実務でどのような不具合発見に役立つのかについて探っていきます。📌 今回のエピソードのポイント Nスイッチカバレッジの定義： スイッチの数（遷移の切り替えポイント）をもとにテストの網羅率を計測する仕組みについて解説します。 0・1・2スイッチの違いとテストケース数： 状態遷移の切り替えポイントを考慮することで、テストケース数やカバーできる範囲がどのように変化するのかを整理します。 不具合検出と実務での活用： 0スイッチでは見落としがちな状態遷移に伴う欠陥を見つけるために、どのような場面で高いスイッチ数を検討すべきかを伝えます。📕 参考文献 状態遷移テスト（state transition testing） - ISTQB Glossary ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03🕒 チャプター (00:00) オープニング (01:28) 状態遷移テストとカバレッジのおさらい (02:51) Nスイッチカバレッジとは (04:09) 0スイッチカバレッジ (05:11) 1スイッチカバレッジ (07:52) 2スイッチカバレッジ (09:40) Nスイッチカバレッジのまとめ (10:31) エンディング📢 あなたのご意見をお聞かせください業務で1スイッチカバレッジや2スイッチカバレッジを活用した経験はありますか？「実は業務で使っている」「今回はじめて概念を知った」など、みなさんのご意見やご感想をぜひお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#45 【状態遷移テスト】遷移カバレッジ（0スイッチカバレッジ）とは？ストップウォッチの例題で分かりやすく解説！
状態遷移テストにおける代表的な網羅基準である「遷移カバレッジ（0スイッチカバレッジ）」について解説します。ストップウォッチの具体例を用いて、状態遷移図からどのようにテストケースを組み立て、カバレッジ100%を目指すのかを分かりやすく紐解きます。状態カバレッジとの違いや、実務で他の人と認識を合わせやすいメリットについても触れています。📌 今回のエピソードのポイント 遷移カバレッジ（0スイッチカバレッジ）の基本： すべての状態に滞在し、すべての遷移（矢印）を通ることを保証する網羅基準を解説します。 ストップウォッチの例題で理解： 状態遷移図をベースに、2つのテストケースで遷移カバレッジ100%を達成するステップを紹介します。 状態カバレッジとの違いとメリット： 単に状態を通るだけでなく、遷移まで網羅することでテストの抜け漏れを防ぎ、認識を合わせやすくなる理由を語ります。📕 参考文献 ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03🕒 チャプター (00:00) オープニング (01:19) 遷移カバレッジとは (07:56) エンディング📢 あなたのご意見をお聞かせください「遷移カバレッジ」という言葉は知らなくても、普段の業務で自然と実践されていた方も多いのではないでしょうか？「うちの現場ではこんなカバレッジ基準を使っている」「実務でこう工夫している」など、みなさんの体験談やご感想をぜひお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#44 【状態遷移テスト】状態遷移図の漏れを防ぐ「状態表」の作り方とテストケースへの展開
今回は、状態遷移テストにおける「状態表の作成」について詳しく解説します。状態遷移図だけでは気づきにくい動作の抜け漏れや、「自己遷移」「非活性（N/A）」を洗い出す状態表の組み立て方から、実際のテストケースへどう落とし込んでいくかまで、ストップウォッチの具体例を用いてわかりやすく紐解きます。📌 今回のエピソードのポイント 状態表で遷移の漏れを防ぐ： 状態遷移図をマトリクス形式の状態表に変換することで、図だけでは見落としがちな未定義の動作や潜在的な漏れを効率よく発見できます。 「自己遷移」と「非活性（N/A）」の整理： 操作しても状態が変わらない動作（ハイフン表記）と、仕様上起こり得ない動作（N/A表記）を明確に区別して整理するコツを解説します。 テストケースへの具現化： 状態表をもとにテスト実装段階のテストケースを作成する際、期待結果をより詳細に記述するメリットと注意点をまとめています。📕 参考文献 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 4.2.4 状態遷移テスト🕒 チャプター (00:00) オープニング (01:50) 状態表の定義と役割 (02:51) 例題（ストップウォッチ）と状態遷移図の復習 (03:34) 状態表の作成プロセス (05:43) 空白セルから気づく「自己遷移」と「非活性（N/A）」 (09:25) 状態表からテストケース例への落とし込み (12:01) まとめと次回への展望 (12:51) エンディング📢 あなたのご意見をお聞かせください普段のテスト設計で「状態表」を活用していますか？「これまで状態遷移図しか使っていなかったけれど試してみたい」「現場でこう使っている」など、皆様のご意見やエピソードをぜひお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#43 【状態遷移テスト】ストップウォッチで学ぶ「状態遷移図」の書き方と活用パターン
テスト設計技法のひとつである「状態遷移テスト」の基本となる「状態遷移図」の作成方法について解説します。ストップウォッチの動作を例に、状態・イベント・遷移といった構成要素や「開始疑似状態」の役割を紐解きます。さらに、テスト設計で状態遷移図を積極的に活用すべき2つの重要なパターンについても詳しく紹介します。📌 今回のエピソードのポイント 状態遷移図の構成要素： 状態、イベント、遷移、そして「開始疑似状態」など、システムの振る舞いをモデル化するための基本用語と役割を整理します。 ストップウォッチを例にした作成手順： 「待機中」「計測中」「一時停止中」といった状態が、ボタン押下というイベントによってどう変化するかを順を追って図解します。 積極的に作成すべき2つのパターン： 「同じイベントでも前状態によって遷移先が変わる場合」と「同じ状態でもイベントによって遷移先が変わる場合」の活用ポイントを解説します。📕 参考文献 状態遷移テスト（state transition testing） - ISTQB Glossary ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 4.2.4 状態遷移テスト🕒 チャプター (00:00) オープニング (01:40) 状態遷移テスト・状態遷移図とは何か (03:24) 例題：ストップウォッチのテスト (04:05) 状態遷移図の作成手順 (07:17) 積極的に作成すべきパターン①（前状態による違い） (08:33) 積極的に作成すべきパターン②（イベントによる違い） (08:55) まとめと次回予告 (09:34) エンディング📢 あなたのご意見をお聞かせくださいみなさんは普段のテスト設計で「状態遷移図」を活用していますか？「開始疑似状態」の表記など、知っていたことや新しい発見があれば、ぜひご意見やご感想をお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#42 WACATE2026夏＆JaSST関西の舞台裏！炊飯器問題のこだわりとUI生成AI「Stitch」活用法
今回は、先日開催された2つの大きなテストコミュニティイベント「WACATE 2026 夏」と「JaSST'26 Kansai」の振り返りと舞台裏をお届けします。前半は、実行委員長を務めたWACATE2026夏「テスト千本ノック！」での問題作成のこだわりや、状態遷移テストへの想い、そしてGoogleのUI生成AIツール「Stitch」を活用した画面イメージ作成の裏話を公開。後半は、大阪で開催されたJaSST'26 Kansaiにて、スポンサーセッションとワークショップ合わせて3時間弱に及ぶ怒涛の登壇を果たしたエピソードや、関西におけるコミュニティの認知度について語ります。📌 今回のエピソードのポイント WACATE 2026 夏の炊飯器問題： 今回のテーマ「テスト千本ノック！」において、状態遷移テストの魅力を伝えるために組み込み系の「炊飯器」を題材に選んだこだわりを明かします。 UI生成AI「Stitch」の活用： デザインが苦手な人でも、仕様をインプットするだけでそれっぽい画面イメージを効率的に作成できたGoogleの生成AIツールの活用法を紹介します。 JaSST関西での怒涛の3時間登壇： スポンサーセッションとワークショップの再演で誰よりも長く登壇した振り返りと、関西での「WACATE」の意外な認知度について語ります。📕 参考文献 WACATE 2026 夏 〜テスト千本ノック！ Stitch - Design with AI JaSST'26 Kansai JaSST'26 Kansaiの投影資料 B-Testing.fm #26 意外と奥が結婚深い「境界値分析」〜100%のカバレッジでもバグが出る理由〜🕒 チャプター (00:00) オープニング (01:30) WACATE 2026 夏「テスト千本ノック！」の舞台裏とAI活用 (10:18) JaSST'26 Kansaiでの怒涛の登壇振り返り📢 あなたのご意見をお聞かせくださいWACATE 2026 夏やJaSST'26 Kansaiに参加されたみなさまからの感想をお待ちしています！また、普段のテスト設計で生成AIツールを使っている事例や、組み込み系・状態遷移テストでの工夫などもぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#41 テストの7原則（後編）〜殺虫剤のパラドックスから「欠陥ゼロ」の落とし穴まで〜
今回は、前回に引き続き「テストの7原則」の後編をお届けします。ソフトウェアテストの基礎となるISTQB（JSTQB）シラバスに記載されている7つの原則のうち、残りの3つ（テストの弱化、コンテキスト次第、欠陥ゼロの落とし穴）について、具体例を交えながら分かりやすく解説します。さらに質問コーナーでは、現場のリアルな悩みである「テスト待ちの解消」についての体験談とアプローチもシェア。テストに関わるエンジニアはもちろん、開発者やマネージャーの方々にもぜひ知っておいていただきたい内容です！📌 今回のエピソードのポイント テストの弱化（殺虫剤のパラドックス）： 同じテストを繰り返しても新しい欠陥は見つからなくなるため、テストも常にアップデートが必要であるというお話。 テストはコンテキスト次第： 人命に関わる医療システムとスマートフォンゲームとでは、テストにかけるべきコストや求める品質が全く異なるというお話。 「欠陥ゼロ」の落とし穴： バグが全くなくても「起動に5時間かかるシステム」は使えないように、欠陥がないことと素晴らしい製品であることは必ずしもイコールではないというお話。📕 参考文献 10X.fm Tech Talk ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02🕒 チャプター (00:00) オープニング (01:37) テストの7原則（後編） (02:21) 5. テストの弱化 (05:16) 6. テストはコンテキスト次第 (07:26) 7. 「欠陥ゼロ」の落とし穴 (10:18) 質問コーナー：テスト待ちを解消したなと思った瞬間はどんな時ですか？ (12:48) お知らせ・エンディング📢 あなたのご意見をお聞かせください今回ご紹介した「テストの7原則」の中で、皆さんの日々の業務において一番ハッとさせられた原則はどれでしたか？また、現場でのテストにまつわる「あるある」や「お悩み」などがあれば、ぜひお気軽にお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#40 テストの7原則（前編）QAエンジニア以外も知っておきたい品質の基本
今回のテーマは、ソフトウェア開発に関わるすべての人に知っておいてほしい「テストの7原則」の前編です。JSTQBシラバスにも記載されているこの原則は、QAやテストエンジニアだけでなく、開発者、マネージャー、経営層など、あらゆるロールの方に役立つ共通のガイドラインとなります。今回は7つのうち、前半の4つの原則について、具体的な例（名前入力欄のテストパターン数など）を交えながら分かりやすく解説します。📌 今回のエピソードのポイント バグゼロの証明は不可能： テストによって欠陥を見つけることはできても、「絶対にバグがない」と証明することはできず、全数テストも現実的には不可能です。 早期テストの重要性： テストを後回しにせず、いかに早く欠陥に気づけるかが、結果的にプロジェクトの時間とコストの大幅な節約に繋がります。 欠陥は偏在する： バグはシステム全体に満遍なく存在するのではなく、特定の箇所や境界値などに局所的に集中して発生する傾向があります。📕 参考文献 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02🕒 チャプター (00:00) オープニング (01:38) テストの7原則とは？ (03:08) 1. テストは欠陥があることは示せるが、欠陥がないことは示せない (04:27) 2. 全数テストは不可能 (06:58) 3. 早期テストで時間とコストを節約 (07:38) 4. 欠陥の偏在 (09:37) 質問コーナー：スケジュール上「QA開始」なのに実装が終わっていない時は？ (12:07) お知らせ・エンディング📢 あなたのご意見をお聞かせください「テストの7原則」の中で、あなたが特に重要だと感じたポイントはどれですか？また、日々の業務で直面しているテストや品質に関するお悩み、番組へのご質問があれば、ぜひお気軽にお寄せください！ 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アプリでのフォローをぜひお願いします！
こちらもおすすめ
jkondoの朝の散歩
ポッドキャストプラットフォーム「LISTEN」や、GPSトラッキングサービス「IBUKI」、物件メディア「物件ファン」、京都の宿とコワーキング施設「UNKNOWN KYOTO」を運営する近藤淳也（jkondo）が、朝の散歩をしたりしながら、日々の出来事や考えたことを語ります。
歴史を面白く学ぶコテンラジオ （COTEN RADIO）
歴史を愛し、歴史を知りすぎてしまった歴史GEEK2人と圧倒的歴史弱者がお届けする歴史インターネットラジオです。 歴史というレンズを通して「人間とは何か」「私たち現代人の抱える悩み」「世の中の流れ」を痛快に読み解いていく！？ 笑いあり、涙ありの新感覚・歴史キュレーションプログラム！ ☆Apple & Spotify Podcast 部門別ランキング１位獲得！ ☆ジャパンポッドキャストアワード2019 大賞&Spotify賞 ダブル受賞！ ※正式名称は「古典ラジオ」ではなく「コテンラジオ」です ーーー COTEN RADIO is an entertainment radio talk program for history , published by the crazy history geeks group "COTEN" in Japan. ☆Apple & Spotify Podcast in Japan category ranking No.1 ! ☆Japan Podcast Awards 2019 Grand prize and Spotify prize !
近藤淳也のアンノウンラジオ
株式会社はてな創業者であり現在もITの第一線で働く近藤淳也が、京都の宿UNKNOWN KYOTOにやって来る「好きなことを仕事にしている人」を深堀りすることで、世の中の多様な仕事やキャリア、生き方・働き方を「リアルな実例」として紐解いていきます。 . 【ホスト：近藤淳也】 株式会社OND代表取締役社長、株式会社はてな取締役、UNKNOWN KYOTO支配人、NPO法人滋賀一周トレイル代表理事、トレイルランナー。 2001年に「はてなブログ」「はてなブックマーク」などを運営する株式会社はてなを創業、2011年にマザーズにて上場。その後2017年に株式会社ONDを設立し、現在もITの第一線で働く。 株式会社OND: https://ond-inc.com/ . 【UNKNOWN KYOTO】 築100年を超える元遊郭建築を改装し、仕事もできて暮らせる宿に。コワーキングやオフィスを併設することで、宿泊として来られる方と京都を拠点に働く方が交わる場所になっています。 1泊の観光目的の利用だけではなく、中長期滞在される方にも好評いただいています。 web: https://unknown.kyoto/ . こちらから本文を読んだりコメントが書けます！ https://listen.style/p/unknownradio
私より先に丁寧に暮らすな
東京の歌人・上坂あゆ美と、京都の僧侶・鵜飼ヨシキによる雑談配信。人生の呪いからファミレスの好きなメニューの話まで幅広くお届け。 【初めての方におすすめ回】 #30 お菓子が人間だったら誰と付き合いたいか真剣に考える https://open.spotify.com/episode/751EzuNXjpgP2i53P7OtX7?si=XxN2eddURsas_JWE6KFu-A #163 恋愛ってマーージでクソだと思っている人の話 https://open.spotify.com/episode/1WgeglhRT5GQfqzkBO2bNF?si=1l0b2OBlTJq 📩おたより宛先 https://forms.gle/E6oFMLDcrJhUH2g57 番組公式SNS https://x.com/yori_suna （インスタもある） 🚗🚥番組公式コミュニティ https://rooom.listen.style/p/ 📨その他、番組へのお問い合わせはコチラまで yorisuna24@gmail.com
LISTEN NEWS
LISTENは、AI文字起こしとコミュニティで、ポッドキャストを「聴く・配信する・つながる」ためのプラットフォームです。 公式番組「LISTEN NEWS」では、開発の裏話や近況も交えつつ、最新情報をお届けします。 LISTENはこちら→ https://listen.style/
IBUKI STATION
ここはアウトドア向けGPSトラッキング「IBUKI」にまつわる人々が集まる場所。 トレイルラン、登山、冒険、ランニング、自転車、ロゲイニング、、 スタイルは数あれど、共通しているのは自然を楽しみ、そして人とのつながりも楽しむ姿勢。 自然を目一杯楽しみ、苦しみながら、人と接する喜びにも気付く。 アウトドアを満喫するみなさんが、ほっとできるIBUKI STATIONです。 IBUKI https://ibuki.run/ 近藤淳也 IBUKIを提供する株式会社OND代表。ポッドキャストプラットフォーム「LISTEN」も展開 桑原佑輔 OND所属。IBUKI事業担当営業・テクニカルディレクター 中川和美 OND所属。IBUKI担当。トレイルランナー