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" rel="nofollow noopener noreferrer">ポストする）
・https://forms.gle/otndGhbtwZ2N4eH9A" rel="nofollow noopener noreferrer">投稿フォームはこちら
・https://b-testing.net/" rel="nofollow noopener noreferrer">公式サイト
番組の魅力・推薦
#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アプリでのフォローをぜひお願いします！
#58 WACATE2026 冬直前！「プロパティベースドテスト」の中で最も創造的なプロセスに挑む
今回のエピソードでは、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アプリでのフォローをぜひお願いします！
#57 【テスト自動化のピラミッド】UIテストを増やしすぎると失敗する？現場目線で考えるテスト戦略と理想の比率
テスト自動化を進めるなかで、「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アプリでのフォローをぜひお願いします！
#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 でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#55 自動テストを書くべき3つのきっかけ
自動テストを導入したいけれど、どのタイミングで、どう書き始めればいいか悩んでいませんか？今回は、自動テストを書くべき「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アプリでのフォローをぜひお願いします！
#54 「語る夕べ」シリーズ大解剖！QAエンジニアたちの熱き議論の場とは？
今回は、QAエンジニア同士で熱い議論を交わす勉強会「語る夕べ」シリーズについてご紹介します。「テスト設計を語る夕べ」や「ドメインテストを語る夕べ」など、過去に開催されたイベントの様子や、参加者のリアルな声を通して、その魅力をたっぷりとお届けします。📌 今回のエピソードのポイント 「語る夕べ」シリーズのコンセプト： 登壇者だけでなく、参加者全員で深く議論し合う場を提供しています。 過去の開催テーマ： テスト設計、ドメインテストなど、多岐にわたるテーマで開催されてきました。 今後の開催予定： 次回はユースケーステストをテーマに開催予定です。ぜひご期待ください！📕 参考文献 ドメインテストを語る夕べ 2026年版 ドメイン分析をアップデートする ドメインテストにおけるONポイントとOFFポイントについて考える🕒 チャプター (00:00) オープニング (01:26) 「テスト設計を語る夕べ」シリーズについて (05:07) コロナ禍前から続く「語る夕べ」の歴史 (06:08) コロナ禍再開後の「語る夕べ」 (08:24) 次回開催「ユースケーステストを語る夕べ」について (09:20) オフライン開催へのこだわり (10:07) エンディング📢 あなたのご意見をお聞かせください「語る夕べ」シリーズで取り上げてほしいテーマや、これまでの開催で印象に残っていることなど、ぜひご意見をお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#53 自動テストって何のために書くの？ 4つのメリットを分かりやすく解説！
今回は、これまでのテスト設計の話題から少し離れ、「自動テスト」をテーマにお話しします。自動テストと聞くと、「テスト実行の工数削減」が真っ先に思い浮かぶかもしれませんが、実は得られる恩恵はそれだけではありません。「そもそもなぜ自動テストを書くのか？」という根本的な疑問について、ロボット掃除機や食洗機、サーカスの綱渡りといった身近な例えを交えながら、4つの視点でメリットを深掘りして解説しています。自動テストに興味がある方、これから導入を考えている方はぜひお聴きください！📌 今回のエピソードのポイント テスト実行に必要な準備の明確化： ロボット掃除機を買うと床を片付けるようになるのと同様に、自動テストの導入はテストしやすい設計や環境作りを促進します。 安心してコードを変更できるセーフティネット： サーカスの落下防止網があるから大技に挑めるように、自動テストがあるからこそ安全にリファクタリングや仕様変更が行えます。 生きたドキュメントとしての機能： 自動テストは、常に仕様書と実装の乖離を防ぐ「動く説明書」としての役割を果たします。 工数削減とその注意点： テスト実行工数は削減できますが、テストを準備する工数やメンテナンスコストへの意識も重要です。📕 参考文献 テスト自動化のルンバ効果 開発者が適切なテストを行うために🕒 チャプター (00:00) オープニング (01:46) なぜ自動テストを書くのか？ (03:03) メリット1：テスト実行に必要な準備が明確化される (06:36) メリット2：安心して既存コードを変更できる (07:54) メリット3：実装内容の説明書代わりになる (09:13) メリット4：テスト実行の工数が削減できる (11:34) エンディング📢 あなたのご意見をお聞かせください自動テストの導入でつまずいたことや、逆に「導入してよかった！」と感じたエピソードはありますか？ぜひ皆さんの自動テストに関する体験談を教えてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！
#52 探索的テストの誤解を解く！書籍『Explore It!』の魅力と実践へのガイド
今回のエピソードでは、探索的テストに関する名著の日本語訳版『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アプリでのフォローをぜひお願いします！
#51 【ユースケーステスト】ユースケース記述からシナリオテストを作る方法と、そのメリット
今回はユースケーステストについての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アプリでのフォローをぜひお願いします！
#50 【ユースケーステスト】ユースケース記述の書き方のコツとメリット！図では表現できない仕様の曖昧さをなくすポイント
ユースケーステストの続編として、今回は「ユースケース記述」の基本から書き方のコツまで詳しく解説します。ユースケース図だけでは表現しきれない詳細なやり取りや例外処理をどのようにテキスト化するのか、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アプリでのフォローをぜひお願いします！
#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アプリでのフォローをぜひお願いします！
こちらもおすすめ
ゲイで茶を沸かす
この番組は、お茶の間の皆さまへMCシュンと週替わりで登場する3人のゲイ“茶ガマ”が、身の上話や妄想話をわ茶わ茶と繰り広げる、おしゃべり人情バラエティです。 毎週月曜配信。週の初めのお耳に一服したい時などにどうぞ🍵 第7回JAPAN PODCAST AWARDS企画賞受賞。 🎧 はじめての方におすすめのエピソード 💌【お便り回】 ep120 カミングアウトしてこない同僚との付き合い方と後輩指導で心がけていること ▶ 茶ガマたちのリアルで優しいアンサーをどうぞ 🐈🐈🐈🐕【全員集合回】 ep31 カミングアウト体験談と新作BL朗読 ▶ 勢ぞろいでカミングアウトのあれこれと、爆笑必須？BL朗読 📮おたより募集中！ 💌フォーム：https://forms.gle/jMsPwJcgNNDf19SZ9 📧メール：gaydechawowakasu@gmail.com 🌐SNSや通販サイト：https://lit.link/gaydechawowakasu 📰メディア：https://wabisabi-cha.com 🎥YouTube：https://www.youtube.com/@gaydechawowakasu 🎙姉妹番組もぜひチェック！ https://lit.link/gaytomoradio https://lit.link/mackypodcast
私より先に丁寧に暮らすな
東京の歌人・上坂あゆ美と、京都の僧侶・鵜飼ヨシキによる雑談配信。人生の呪いからファミレスの好きなメニューの話まで幅広くお届け。 【初めての方におすすめ回】 #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
桃山商事
コミュニケーション、男性性、恋愛、人間関係、ジェンダー、ケア、孤独、性欲、会社、友情、老い……メンバーがその時々で気になったテーマを１つ設定して、モヤモヤを言語化していくNEOな座談Podcastです。2011〜2016年「二軍ラジオ」(ApplePodcast)、2017〜2024年「恋愛よももやまばなし」(ニコ生→Podcast)を配信していました。清田隆之(文筆業)、森田(会社員)、ワッコ(会社員)、さとう(会社員)の４人でお届けします。
近藤淳也のアンノウンラジオ
株式会社はてな創業者であり現在も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
jkondoの朝の散歩
ポッドキャストプラットフォーム「LISTEN」や、GPSトラッキングサービス「IBUKI」、物件メディア「物件ファン」、京都の宿とコワーキング施設「UNKNOWN KYOTO」を運営する近藤淳也（jkondo）が、朝の散歩をしたりしながら、日々の出来事や考えたことを語ります。
劇団雌猫の悪友ミッドナイト
平成元年（1989年）生まれのオタク友達4人組が、好きなエンタメや日々の生活のことなどをワイワイお話する番組です。 明日から特に役に立たない、別にSNSでバズらない、ふつ〜〜のおしゃべりをお届けします💬 毎週金曜日の朝更新。 同人誌「悪友」シリーズ、『浪費図鑑』『だから私はメイクする』『世界が広がる 推し活英語』などを手掛けるサークル・劇団雌猫がお送りします🐾 お手紙はこちらから💌 https://forms.gle/M2VJpKzcrSXHWpXG6 ◎劇団雌猫のSNS https://twitter.com/aku__you https://www.instagram.com/gekidan_mesuneco/ ◎劇団雌猫のLISTEN https://listen.style/p/gekidan-mesuneco?7SdOHTYF music: Scandinavianz - Purple SkyCreative Commons - Attribution 3.0 Unported (CC BY 3.0) Free Download: hypeddit.com/scandinavianz/purplesky