B-Testing.fm
B-Testing.fmは、テストや品質の深淵を探求し、現場で役立つ思考のヒントを届ける番組です。「テストは何のために行うのか？」「品質の正体とは？」抽象的で捉えどころのないこれらの言葉をQAエンジニアの視点から紐解き、自分たちの言葉で「言語化」できるようになることを目指します。 【配信日時】 毎週月曜 朝8:00配信 🎙 ホストプロフィール：ブロッコリー ・Developers Summitでのベストスピーカー賞など多数の受賞歴を持つQAエンジニア。 ・「Holistic Testing」日本唯一の公式トレーナー ・『Agile Testing Condensed』などの翻訳を通じて、知見を発信中。 開発者、QA、PdMなど、プロダクトを良くしたい全ての方へ。あなたの「テスト観」をアップデートする時間をお楽しみください。 📢 番組に参加する リスナーの皆様からのお便りをお待ちしています！ ・ハッシュタグ：#b_testing （ポストする） ・投稿フォームはこちら ・公式サイト
エピソード
#53 自動テストって何のために書くの？ 4つのメリットを分かりやすく解説！
・13:04
今回は、これまでのテスト設計の話題から少し離れ、「自動テスト」をテーマにお話しします。自動テストと聞くと、「テスト実行の工数削減」が真っ先に思い浮かぶかもしれませんが、実は得られる恩恵はそれだけではありません。「そもそもなぜ自動テストを書くのか？」という根本的な疑問について、ロボット掃除機や食洗機、サーカスの綱渡りといった身近な例えを交えながら、4つの視点でメリットを深掘りして解説しています。自動テストに興味がある方、これから導入を考えている方はぜひお聴きください！ 📌 今回のエピソードのポイント テスト実行に必要な準備の明確化： ロボット掃除機を買うと床を片付けるようになるのと同様に、自…
#52 探索的テストの誤解を解く！書籍『Explore It!』の魅力と実践へのガイド
・11:17
今回のエピソードでは、探索的テストに関する名著の日本語訳版『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』についてご紹介します！「探索的テスト＝仕様書がない時の場当たり的なテスト」というよくある誤解を解きほぐし、具体的なヒューリスティクスやアプローチ手法を体系的に学べる一冊です。テスト設計技術との高度な融合や、実際の開発プロセスへの組み込み方など、テストを専門とする方だけでなく、開発者やプロダクトマネージャーにも役立つ情報が満載。本書が持つ本当の価値と、現場で実践するためのヒントを語ります。 📌 今回のエピソードのポイント 「探索的テスト」への誤解を払拭：思…
#51 【ユースケーステスト】ユースケース記述からシナリオテストを作る方法と、そのメリット
・18:58
今回はユースケーステストについての3回目のエピソードとして、ユースケース図やユースケース記述をもとに、どのようにシナリオベースのテストに落とし込んでいくかについて語っています。DVDレンタルの例を用いて、基本フローから代替・例外フローへの寄り道パターンの考え方、そして業務全体の流れを通したテストだからこそ見つかる「リカバリー不全」の不具合など、実践的なポイントを解説しています。実際の業務で活用する際の注意点にも触れていますので、ぜひテスト設計の参考にしてみてください。 📌 今回のエピソードのポイント ユースケーステストとシナリオテスト： ユースケースの動作を実行するように設計する「シナリオ…
#50 【ユースケーステスト】ユースケース記述の書き方のコツとメリット！図では表現できない仕様の曖昧さをなくすポイント
・11:01
ユースケーステストの続編として、今回は「ユースケース記述」の基本から書き方のコツまで詳しく解説します。ユースケース図だけでは表現しきれない詳細なやり取りや例外処理をどのようにテキスト化するのか、DVD貸し出しシステムを例に挙げながら具体的に紐解きます。アクターとシステムの対話を意識した正しい粒度の揃え方や、仕様の曖昧さ・不備を防ぐ記述のメリットを学んでいきましょう！ 📌 今回のエピソードのポイント 図では見えない詳細の視覚化： ユースケース図のシンプルさでは表現しきれない、会員証の有効期限確認などの具体的な工程や例外フローを明確化できるメリットを解説します。 アクターとシステムの交互の対話…
#49 【ユースケーステスト】全体像とユースケース図の役割を徹底解説
・10:42
今回のエピソードでは、ソフトウェアテストの手法の一つである「ユースケーステスト」について、その全体像から、ユースケース図の役割、そしてユースケース図を書くメリットまで、詳しく解説しています。特に、ユースケース図がどのようにシステム開発に関わる人々の認識を合わせる役割を果たすのか、DVDレンタルシステムの具体例を交えながらわかりやすく説明しています。これからユースケーステストを学びたい方や、テスト設計の幅を広げたい方におすすめの内容です。 📌 今回のエピソードのポイント ユースケーステストとは： システムやサブシステムが提供する一貫した機能単位をテストする手法。 ユースケース図の目的： 開発…
#48 『Writing Code vs. Shipping Code』AIコーディングツールは本当に開発の生産性を上げたのか？
・17:18
AIコーディングツールの普及によって開発の現場はどう変わったのか？今回は、AIツールの進化と生産性・リリースへの影響を多角的に分析した海外論文『Writing Code vs. Shipping Code』をご紹介します。コード生成量が劇的に増える一方で最終的なリリース量にはどのようなギャップが生じているのか、またアプリストアで起きている「供給過多と使われないアプリの増加」というリアルな現実について、数値データを交えて詳しく解説します。 📌 今回のエピソードのポイント AIコーディングツールの3つの世代分類： オートコンプリート型、対話型エージェント、自律型エージェントというAI開発ツール…
#47 【状態遷移テスト】ラウンドトリップカバレッジ徹底解説！具体例・メリットからAI生成の落とし穴まで
・12:42
今回のテーマは、状態遷移テストにおける「ラウンドトリップカバレッジ」です。ISTQBシラバスの定義をベースに、ストップウォッチの具体例を用いながらテストケースの導出方法や網羅条件をわかりやすく解説します。さらに、状態間を行き来する不具合の検知やチーム内での認識合わせといったメリットに加え、認知度の低さや生成AI（GeminiやChatGPT）に丸投げした際の精度・ケース欠損の注意点についても深掘りします。 📌 今回のエピソードのポイント 定義と具体例でのケース導出： ISTQBシラバスに基づく定義と、ストップウォッチの遷移図を用いた7つのテストケース導出プロセスを解説。 導入メリットと認識…
#46 【状態遷移テスト】Nスイッチカバレッジ（0・1・2スイッチ）の考え方とテストケース作成
・12:08
状態遷移テストにおける「Nスイッチカバレッジ」について、具体的な図解やお題を交えながらわかりやすく解説します。0スイッチカバレッジ（遷移カバレッジ）と1スイッチカバレッジ・2スイッチカバレッジの違いや、それぞれのテストケースの考え方、実務でどのような不具合発見に役立つのかについて探っていきます。 📌 今回のエピソードのポイント Nスイッチカバレッジの定義： スイッチの数（遷移の切り替えポイント）をもとにテストの網羅率を計測する仕組みについて解説します。 0・1・2スイッチの違いとテストケース数： 状態遷移の切り替えポイントを考慮することで、テストケース数やカバーできる範囲がどのように変化す…
#45 【状態遷移テスト】遷移カバレッジ（0スイッチカバレッジ）とは？ストップウォッチの例題で分かりやすく解説！
・9:38
状態遷移テストにおける代表的な網羅基準である「遷移カバレッジ（0スイッチカバレッジ）」について解説します。ストップウォッチの具体例を用いて、状態遷移図からどのようにテストケースを組み立て、カバレッジ100%を目指すのかを分かりやすく紐解きます。状態カバレッジとの違いや、実務で他の人と認識を合わせやすいメリットについても触れています。 📌 今回のエピソードのポイント 遷移カバレッジ（0スイッチカバレッジ）の基本： すべての状態に滞在し、すべての遷移（矢印）を通ることを保証する網羅基準を解説します。 ストップウォッチの例題で理解： 状態遷移図をベースに、2つのテストケースで遷移カバレッジ100…
#44 【状態遷移テスト】状態遷移図の漏れを防ぐ「状態表」の作り方とテストケースへの展開
・14:25
今回は、状態遷移テストにおける「状態表の作成」について詳しく解説します。状態遷移図だけでは気づきにくい動作の抜け漏れや、「自己遷移」「非活性（N/A）」を洗い出す状態表の組み立て方から、実際のテストケースへどう落とし込んでいくかまで、ストップウォッチの具体例を用いてわかりやすく紐解きます。 📌 今回のエピソードのポイント 状態表で遷移の漏れを防ぐ： 状態遷移図をマトリクス形式の状態表に変換することで、図だけでは見落としがちな未定義の動作や潜在的な漏れを効率よく発見できます。 「自己遷移」と「非活性（N/A）」の整理： 操作しても状態が変わらない動作（ハイフン表記）と、仕様上起こり得ない動作…
#43 【状態遷移テスト】ストップウォッチで学ぶ「状態遷移図」の書き方と活用パターン
・11:11
テスト設計技法のひとつである「状態遷移テスト」の基本となる「状態遷移図」の作成方法について解説します。ストップウォッチの動作を例に、状態・イベント・遷移といった構成要素や「開始疑似状態」の役割を紐解きます。さらに、テスト設計で状態遷移図を積極的に活用すべき2つの重要なパターンについても詳しく紹介します。 📌 今回のエピソードのポイント 状態遷移図の構成要素： 状態、イベント、遷移、そして「開始疑似状態」など、システムの振る舞いをモデル化するための基本用語と役割を整理します。 ストップウォッチを例にした作成手順： 「待機中」「計測中」「一時停止中」といった状態が、ボタン押下というイベントによ…
#42 WACATE2026夏＆JaSST関西の舞台裏！炊飯器問題のこだわりとUI生成AI「Stitch」活用法
・17:29
今回は、先日開催された2つの大きなテストコミュニティイベント「WACATE 2026 夏」と「JaSST'26 Kansai」の振り返りと舞台裏をお届けします。前半は、実行委員長を務めたWACATE2026夏「テスト千本ノック！」での問題作成のこだわりや、状態遷移テストへの想い、そしてGoogleのUI生成AIツール「Stitch」を活用した画面イメージ作成の裏話を公開。後半は、大阪で開催されたJaSST'26 Kansaiにて、スポンサーセッションとワークショップ合わせて3時間弱に及ぶ怒涛の登壇を果たしたエピソードや、関西におけるコミュニティの認知度について語ります。 📌 今回のエピソー…
#41 テストの7原則（後編）〜殺虫剤のパラドックスから「欠陥ゼロ」の落とし穴まで〜
・14:24
今回は、前回に引き続き「テストの7原則」の後編をお届けします。ソフトウェアテストの基礎となるISTQB（JSTQB）シラバスに記載されている7つの原則のうち、残りの3つ（テストの弱化、コンテキスト次第、欠陥ゼロの落とし穴）について、具体例を交えながら分かりやすく解説します。さらに質問コーナーでは、現場のリアルな悩みである「テスト待ちの解消」についての体験談とアプローチもシェア。テストに関わるエンジニアはもちろん、開発者やマネージャーの方々にもぜひ知っておいていただきたい内容です！ 📌 今回のエピソードのポイント テストの弱化（殺虫剤のパラドックス）： 同じテストを繰り返しても新しい欠陥は見…
#40 テストの7原則（前編）QAエンジニア以外も知っておきたい品質の基本
・13:34
今回のテーマは、ソフトウェア開発に関わるすべての人に知っておいてほしい「テストの7原則」の前編です。JSTQBシラバスにも記載されているこの原則は、QAやテストエンジニアだけでなく、開発者、マネージャー、経営層など、あらゆるロールの方に役立つ共通のガイドラインとなります。今回は7つのうち、前半の4つの原則について、具体的な例（名前入力欄のテストパターン数など）を交えながら分かりやすく解説します。 📌 今回のエピソードのポイント バグゼロの証明は不可能： テストによって欠陥を見つけることはできても、「絶対にバグがない」と証明することはできず、全数テストも現実的には不可能です。 早期テストの重…
#39 水準数が異なる直交表の応用的な使い方 ＆ テストスキルと生成AI（LLM）の相性
・17:26
ソフトウェアテストの設計手法の一つである「直交表」について、因子間で水準数が異なる場合の応用的な使い方を深掘りします。よくある2水準の直交表に、3水準の因子をどうやって組み込むのか、身近なコーヒーショップのカスタマイズを例に具体的手順を解説します。また、後半の質問コーナーでは「テストスキルと生成AI（LLM）の相性」について議論します。LLMに直交表の作成を任せた際の具体的な失敗例を交え、AIが苦手とする「交互作用」の概念や、テスト設計における人間の専門性の重要性に迫る必聴のエピソードです。 📌 今回のエピソードのポイント 水準数が異なる直交表の作り方： 2水準の直交表（L8）を拡張し、3…
#38 ソフトウェアテストで使える「直交表」の基本と使い方 ☕️コーヒーショップの例でテスト作成を解説！
・16:13
今回は、テスト技法の中でも数学的な裏付けを持つ「直交表」について解説します！直交表の定義や歴史（タグチメソッド）から、コーヒーショップのカスタマイズを例にした具体的なテストケースの作り方までを分かりやすく紹介。Pair-wise（2因子間網羅）との違いや、直交表を使う際の注意点など、テスト設計に役立つ実践的な知識が詰まったエピソードです。 📌 今回のエピソードのポイント 直交表とは何か： すでに定義されている数学的に裏付けられた表であり、変数をテスト対象となるアイテムに置き換えることで、カバレッジ度合いを達成する組み合わせを生成できます。 直交表の具体的な使い方： コーヒーのカスタマイズ（…
#37 「1人目QAの自己投影」から考える、組織全体で自律的な品質保証活動を育むアプローチ
・16:39
今回は、ブログ記事「1人目QAの自己投影」をテーマに、1人目QAエンジニアが組織に与える影響や陥りがちな課題について掘り下げます。テスト技術の軽視やコスト調整のみに頼る危険性を指摘しつつ、QAエンジニアの増員や組織拡大だけが正解ではない理由を解説。開発者やプロダクトマネージャーをも巻き込み、組織全体が自律して品質保証活動について考えられる状態を作るための理想的なアプローチについて、イベントで寄せられた質問への回答を交えながら語ります。 📌 今回のエピソードのポイント 「1人目QAの自己投影」の危うさ： 品質保証のあり方をQA組織のやり方に固執させてしまうリスクや、1人目QAという強いソース…
#36 無則・有則を知る：テストケース削減の落とし穴と技法の使い分け
・17:01
テストケースを効率的に削減するために「Pair-wise（オールペア法）」や「直交表」をなんとなく使っていませんか？実は、条件の組み合わせ方によっては、絶対に削ってはいけない重要なケースを漏らしてしまう危険があります。 今回は、クラシフィケーションツリー法の続編として、テスト設計において極めて重要な概念である「無則（むそく）」と「有則（ゆうそく）」の違いを解説します。コーヒーショップの割引条件を例に、なぜその技法を選んだのか、その根拠をロジカルに説明できるようになるための知識をお届けします。 📌 今回のエピソードのポイント 「無則」と「有則」の定義と、テスト設計に与える影響 Pair-wi…
#35 網羅基準を用いてテストを剪定する：クラシフィケーションツリー技法の応用
・13:41
前回までの「クラシフィケーションツリー技法」の基本編に続き、今回は作成したテストケースをどのように絞り込み（剪定し）、効率化していくかについて深掘りします。「網羅基準」という言葉は知っていても、実務でどう使い分けるべきか迷っている方も多いのではないでしょうか。Each ChoiceからPair-Wise、そして重要度に応じた「網羅基準の組み合わせ」まで、具体的なコーヒーのカスタマイズ例を用いて分かりやすく解説します。 📌 今回のエピソードのポイント クラシフィケーションツリーにおける4つの主な網羅基準 ケース数と網羅率のトレードオフ：Each ChoiceとPair-Wiseの違い 「Al…
#34 クラシフィケーションツリーのテストケースを「機械的」に導き出す極意
・13:37
前回の「クラシフィケーションツリー」の作成解説に続き、今回はテスト編です。「ツリーは書けたけれど、そこからどうやってテストケースに落とし込めばいいの？」という疑問を解消します。 実は、このテストケースの具体的な導き出し方について詳しく書かれた文献は、日本語ではほとんど存在しません。今回は、独自に言語化した「機械的にテストケースを作成するステップ」を、コーヒーショップのカスタマイズという身近なお題を使って徹底解説します。 ディシジョンテーブル（決定表）にも通ずる、漏れのない組み合わせの作り方をぜひマスターしてください。 📌 今回のエピソードのポイント 文献には載っていない？テストケース作成の…
#33 Step by Stepで学ぶ「クラシフィケーションツリー」の作り方
・12:55
今回から新しいテスト設計技法シリーズがスタートします。取り上げるのは「クラシフィケーションツリー技法」。テスト対象のデータ領域を樹形図で可視化するこの手法について、初心者の方でもすぐに実践できるよう、コーヒーショップのカスタマイズを例にステップ・バイ・ステップで詳しく解説します。 📌 今回のエピソードのポイント クラシフィケーションツリー技法の定義とメリット 基本用語「ルート」「クラシフィケーション」「クラス」の役割 コーヒーショップの複雑な価格設定をツリーで整理する手順 「最下層は必ずクラスにする」など、作成時の重要なルール 感想紹介：テスト設計コンテスト（ASTER）の魅力について …
#32 E2Eの自動テスト、どう作る？目的で使い分けるシナリオ設計術
・12:36
E2E（エンド・ツー・エンド）の自動テストを作成する際、一つの長いシナリオにするか、細かく分割するか迷ったことはありませんか？今回は「テストの目的」に焦点を当て、ピザの注文システムを具体例に、状況に応じた最適なテストの組み方について深掘りします。テスト実行時間の短縮と、不具合の検出精度を両立させるためのヒントをお届けします。 📌 今回のエピソードのポイント E2Eテストの定義と前提条件（UI経由・実データ接続） 一連の業務遂行を確認したい時の「長めシナリオ」のメリット 不具合検出を優先したい時に「シナリオを分割」すべき理由 後続工程のバグを隠さないための、直接URLアクセスの活用術 質問コ…
#31 デシジョンテーブルの「圧縮」術：効率と品質を両立させるパターン削減の極意
・16:56
前々回の「デシジョンテーブルの作り方」に続き、今回は作成したテーブルをどのように効率化していくか、その具体的なテクニックを深掘りします。テストケースをロジカルに、かつ「機械的に」削るための「簡略化」と「禁則」の考え方を解説。ただ削るだけでなく、あえて「削らない」という戦略的な判断基準についても触れています。 📌 今回のエピソードのポイント デシジョンテーブルにおける「簡略化」の定義と手順 「ハイフン（ー）」を用いたパターンの圧縮方法 期待結果が異なる場合に陥りがちな簡略化の罠 「禁則」を用いて物理的に不可能なパターンを削除する 100件を超える膨大なテストケースへの向き合い方 JIS規格と…
#30 GWの振り返り：Podcast EXPOとScrum Fest Niigata 2026で見つけたコミュニティの熱量
・8:45
ゴールデンウィーク中に足を運んだ2つの大きなイベント、Podcast EXPOとScrum Fest Niigata 2026の模様をお届けします。Podcastコミュニティの熱量を感じた展示から、QA・テストの比率が高い新潟でのカンファレンス体験まで、現場で感じたリアルな刺激と発見を共有します。 📌 今回のエピソードのポイント Podcast EXPO 2026の熱気： 旧校舎を活用したノスタルジックな会場で感じた、Podcastコミュニティの多様性と「即売会」のような活気ある雰囲気について語ります。 注目のPodcast番組と活動： 公共訴訟を扱う「CALL4」や、問いをテーマにした冊…
#29 デシジョンテーブルを機械的に作る：掛け算・割り算・引き算で漏れをなくす方法
・18:20
「最新のAIテスト」も、紐解いてみればその根底にあるのは古くから大切にされているテスト設計技法だったりします。今回は、そんな基本でありながら奥が深い「デシジョンテーブル（決定表）」がテーマです。 なんとなく思いついた順に条件を書き出していませんか？それでは考慮漏れを防ぐことはできません。本エピソードでは、パズルを解くように「機械的」にデシジョンテーブルを作成し、仕様の曖昧さまでをも炙り出すプロのテクニックを徹底解説します。 📌 今回のエピソードのポイント 「足し算」の罠：思いついた組み合わせを足していく作り方が、なぜ危険なのか 3つのステップ：掛け算で全パターンを出し、割り算で割り当て、引き…
#28 テスト漬けの2日間！1泊2日の合宿型ワークショップ「WACATE」のススメ
・20:36
「ソフトウェアテストの勉強をしたいけれど、座学だけでは物足りない」「社外のエンジニアと深く交流したい」――そんな悩みを持つ若手エンジニアにぴったりのイベントを紹介します。 今回は、20年近い歴史を持つ合宿型ワークショップ「WACATE（ワカテ）」を特集。実行委員長を務める視点から、イベントの魅力やユニークなコンセプト、さらには次回開催（2026年夏）の詳細までたっぷりとお届けします。 Spotifyでご視聴の方は、会場の様子や参加者データなどのスライドを映像付きでご覧いただけます。 📌 今回のエピソードのポイント 「手を動かす」がメイン： 登壇者の話を聞くだけでなく、グループワークで徹底的…
#27 自然言語に境界値分析を適用する：仕様の曖昧さをあぶり出す技術
・11:31
前回の「境界値分析（BVA）」の基本に続き、今回は一歩踏み込んで「数値ではないデータ」や「自然言語（日本語）」にこの技法をどう適用するかを深掘りします。 「〜まで」「〜から」といった日常的な言葉に潜む曖昧さが、いかにして不具合の種になるのか。テスト技法を単なる「確認作業」としてではなく、仕様の不備を見つける「議論のツール」として活用するための考え方をお届けします。 📌 今回のエピソードのポイント 数値でなくても「順序付け」ができれば境界値分析は活用できる 「8:00から22:00まで」の「22:00ちょうど」は稼働時間か、休止時間か？ 同じ「新横浜駅まで」でも、文脈によって意味が変わる日本…
#26 意外と奥が深い「境界値分析」〜100%のカバレッジでもバグが出る理由〜
・16:30
今回は、テスト設計の基本中の基本でありながら、実は奥が深い「境界値分析（BVA）」を深掘りします。 なぜ「パスワードの文字数チェック」のような単純な仕様でも、テストケースが膨大になってしまうのか、そしてどうすれば効率的に、かつ確実にバグを見つけられるのかを解説します。 「不等号ひとつ」のミスが命取りになる開発現場で、明日から使える実践的な思考プロセスをお届けします。 📌 今回のエピソードのポイント なぜ「全数テストは不可能」なのか？テストの7原則から考える 境界値分析を正しく行うための4つの実践ステップ コードカバレッジが100%でもバグを見逃してしまう落とし穴 仕様書には書かれていない「…
#25 【5月は登壇ラッシュ！】スクフェス新潟、GENDA、Flexy…QAエンジニアが語る「シフトレフト」の発表をしていきます！
・15:10
今回のエピソードでは、5月に予定されている3つの大きな登壇イベントについて詳しくご紹介します。 10Xでの実践を通じた「QA＝テスト」という呪縛を解くためのアプローチや、マイクロサービスにおけるQAの進め方についての質問にもお答えします。 📌 今回のエピソードのポイント 【Scrum Fest Niigata 2026】V字モデルの右側にしわ寄せがいかないチーム作り 【GENDA Tech Talk #04】少数精鋭のQA組織はどう戦うべきか？ 【Flexy meetup】10x流「シフトレフト」な品質保証を1時間みっちり深掘り リスナー質問：複数のマイクロサービスが連動する変更、QAはど…
#24 AIコーディング時代のQA：加速する開発の裏で「理解の負債」にどう立ち向かうか？
・22:02
AIコーディングツールの普及により、コードを生成するスピードは飛躍的に向上しました。しかし、その一方で私たちは「何か」を失いつつあるのかもしれません。 今回は、JetBrains社のQA責任者が提唱した「AI時代のQA」に関する考察を紐解きます。コードを書くコストが下がる代わりに増大する「理解の負債」や「意図の負債」、そして変化するバグ修正のコスト曲線など、AIと共に歩むこれからの品質保証活動について、理論と実感の両面から掘り下げていきます。 📌 今回のエピソードのポイント AIコーディングツールがもたらす「理解の負債」と「意図の負債」とは？ コード量ではなく「1行あたりの理解度」が減ると…
#23 ソフトウェアレビューも「プロセス」で考えよう：属人化の解消とAI活用のコツ
・15:28
日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューをJSTQBの定義する「静的テスト」として捉え直し、あえてプロセスに分解することで見えてくるメリットについて深掘りしました。属人化を防ぐための「レビュー・アーキテクチャ」の考え方や、AIに精度の高いレビューをさせるためのプロンプトのヒントなど、現場で役立つ視点をお届けします。 📌 今回のエピソードのポイント レビューは立派な「テスト（静的テスト）」であるという認識 JSTQBのレビュープロセスにおける「個々人のレビュー」をどう言語化するか テストプロセス（分析・設計・実装・実…
#22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説
・13:43
今回は、テスト設計技法の代表格である「同値分割法」をテーマにお届けします。 「なんとなく」でテスト値を選んでいませんか？「なぜその値を選んだのか」を論理的に説明できることは、QAエンジニアにとって非常に重要なスキルです。47都道府県のプルダウンを例に、目的やリスクに応じた5つのアプローチを紹介しながら、現場で役立つ思考プロセスを整理していきます。 📌 今回のエピソードのポイント 同値分割法の定義とメリット 都道府県のテストで「沖縄県」や「神奈川県」を選ぶそれぞれの理由 テストケース作成時に欠かせない「理由を言語化する」ことの大切さ 5つの回答例（スクロール、印刷反映、文字数、地域、コードの…
#21 テスト設計技法は「楽をするため」にある？省思考でクリエイティブな仕事に向き合う方法
・15:26
今回は「テスト設計とテスト設計技法」の基本について深掘りします。「なぜわざわざ設計が必要なのか？」という根本的な問いから、技法を習得することで得られる意外なメリット、そして数ある技法の効果的な学習順序まで、QAの現場で役立つエッセンスを凝縮してお届けします。 📌 今回のエピソードのポイント 「全数テストは不可能」だからこその設計： 時間制約の中で、効果的・効率的に不具合を見つけるための戦略。 「効果」と「効率」の違いを意識する： 多くのバグを出すことと、かけた時間に対してバグを出すことのバランス。 技法による「省思考（しょうしこう）」のススメ： 信号機の色の順番を考えなくていいように、標準…
#20 まだテストエンジニアの価値を知らないチームに入り込むための方法
・13:45
「QAエンジニアって本当に必要？」「開発者がテストすればいいんじゃない？」そんな声が聞こえてきそうな現場に、最初のQAとして飛び込むのは勇気がいるものです。今回は、テストの価値がまだ浸透していないチームにおいて、どのように信頼を勝ち取り、スムーズにテストプロセスを導入していくべきか、具体的な戦略とコミュニケーションのコツを深掘りします。 📌 今回のエピソードのポイント 不具合分析から始めるプロセス導入：いきなり理想を語るのではなく、目の前の痛み（障害）を入り口にする戦略 「なぜやらなかったの？」は禁句：相手を責める「評論家」ではなく、共に悩む「当事者」として振る舞うヒアリング術 主語を「私…
#19 テストでの「思考」もプロセスで表現してみよう
・14:02
「テストを実行する」という言葉の裏側には、実は多くの思考プロセスが隠れています。今回は、多くの方が無意識に通り過ぎてしまいがちな「テスト分析」や「テスト設計」の重要性について、JSTQBの定義を交えながら掘り下げます。 📌 今回のエピソードのポイント 「テスト準備」を一括りにせず、プロセスを細分化するメリット JSTQBが定義する「テスト分析」「テスト設計」「テスト実装」「テスト実行」の違い 無意識に行っている「何を・どうテストするか」を言語化・議論する大切さ 【質問コーナー】QAからユニットテストを提案する際の「前提」とチーム文化 📕参考文献 ISTQBテスト技術者資格制度 Foun…
#18 思考を「プロセス」で表現するメリット：計算問題から学ぶレビューの極意
・12:34
私たちは普段、仕事の成果（結果）にばかり目を向けがちですが、その裏側にある「思考のプロセス」を可視化することには、実は大きなメリットがあります。 今回は、簡単な計算問題を例に、思考をプロセスとして切り出すことの重要性を解説します。なぜプロセスを細かく分けると「レビュー」がしやすくなるのか？そのトレードオフとは？ 📌 今回のエピソードのポイント 「プロセス」の定義：手続きに着目し、対象を別のものへ変換する活動 プチワーク：8×7-32÷4の解き方から見る、思考の多様性 なぜ思考のプロセスを共有すると、ミスやバグの修正が容易になるのか プロセスを細分化することによる「工数」と「品質」のバランス…
#17 言語化しない状態の大切さ — 「わからない」がチームの課題をあぶり出す
・17:06
「言語化は大事」とよく言われますが、実は言葉にした瞬間にこぼれ落ちてしまう大切なニュアンスがあるのではないでしょうか？ 今回は、あえて「言語化しきれていない状態」を肯定し、特にソフトウェア開発の現場で「わからない」と表明することがいかに品質向上やチームビルディングに寄与するかを深掘りします。4月からの新生活や新しいプロジェクトを控えた方には、ぜひ聴いていただきたい内容です。 📌 今回のエピソードのポイント 言語化することで「失われてしまうもの」の正体 QAエンジニアが設計レビューで「わからない」を連発する理由 個人の「わからない」を、一瞬で「チームの課題」に変換する魔法 開発マネージャーか…
#16 コードを1文字も書かずに「テスト」を始める方法
・18:04
「何をテストすべきか？」――この問いに対する答えは、実はプログラムを書き始めるずっと前に隠されています。今回は、具体的なパスワードの仕様を例に、設計段階で「テストの視点」を持つことがいかに開発コストを削減し、不具合を未然に防ぐのかを深掘りします。 📌 今回のエピソードのポイント 「実装前のテスト」が最強のコスト削減になる理由： バグを早期に発見することで、修正にかかる総コストを劇的に下げるメカニズムを解説。 パスワード仕様から紐解く「テストの考え方」： 4〜12文字、英数字のみ……。シンプルな仕様の中に潜む「曖昧さ」をどう見つけ出すか。 開発現場の「認識の齟齬」を未然に防ぐ： 「Aさんはエ…
#15 エンジニアのキャリア戦略と「実績」の言語化について（デブサミ2026登壇振り返り）
・22:11
今回は、2026年2月中旬に開催された「Developers Summit 2026（デブサミ2026）」での登壇を振り返ります。 「副業・独立・キャリアチェンジ」という異なる選択をした3名のエンジニアによるパネルディスカッション。当日はモデレーターとして話しきれなかった「自分の実力をどう表現すべきか」「ロールモデル不在をどう捉えるか」といった、キャリア構築のヒントをさらに詳しくお届けします。 📌 今回のエピソードのポイント デブサミ2026登壇の舞台裏と、副業・独立・キャリアチェンジの三者三様の視点 「リプレイス対応」の一言で片付けない、職務経歴書での「自分の工夫」の出し方 ロールモデル…
#14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方
・12:47
今回は、MAXさんによるブログ記事「失敗の許容度を設計に組み込む」をテーマに、変化の速い現代の開発における「品質」の定義を掘り下げます。 「失敗しないこと」を目指すのではなく、「失敗をいかに早く検知し、訂正できるか」という視点。このマインドセットの転換が、AIを活用したテスト設計や、継続的なプロダクト運用においてどのような意味を持つのか、自身の共感ポイントを交えて語ります。 📌 今回のエピソードのポイント 品質とは「失敗を防ぐこと」ではなく「最速で検知・修正できる仕組み」である テストの網羅性や正確性以上に追求すべき「プロセスの健牢さ（復元力）」 プロダクト開発と運用は、本質的に「訂正し続…
#13 JaSST'26 Tokyoでクラシフィケーションツリー技法のワークショップを開催します！
・10:32
今回は、2026年3月20日に開催される「JaSST'26 Tokyo」でのワークショップ登壇についてお届けします。テーマは、複雑なテスト条件を整理するのに強力な武器となる「クラシフィケーションツリー技法」。JSTQBのアドバンスドレベルでも扱われるこの技法を、なぜ今ワークショップで学ぶべきなのか？その理由と、翌日に予定している恒例（？）の「テスト花見」についてもお話しします。 📌 今回のエピソードのポイント コミュニティ活動としてのPodcast： 自身の活動の軸足である「WACATE」や「ASTER」への想い クラシフィケーションツリー技法とは： 複数の条件を組み合わせるテスト設計にお…
#12 ソフトウェアテストの「縁の下の力持ち」ASTER。多岐にわたる活動とは？
・10:00
「ASTER」という名前、テストエンジニアなら一度は聞いたことがあるはず。でも、具体的にどんな活動をしている組織なのか、詳しく説明できる人は意外と少ないのではないでしょうか？今回は、日本のソフトウェアテスト技術を支えるNPO法人「ASTER」の裏側に迫ります。 📌 今回のエピソードのポイント ASTERの正体は、非営利で技術振興を行うNPO法人 実はここが運営！JSTQBの資格認定とシラバス翻訳の裏側 20年以上続くテストの祭典「JaSST」の規模感 パワポ形式で無料配布中！？驚きの教育支援と、セミナー参加者を支える「一時保育」制度 📕 参考文献 NPO法人ソフトウェアテスト技術振興協…
#11 リリース直前の混乱を防ぐ！高速道路の出口標識に学ぶ「スムーズなテスト活動」の極意
・8:34
リリース直前になってバグが多発し、開発現場がパニックになる……そんな経験はありませんか？ 今回は、以前「Findy Engineer Lab」に寄稿した記事をもとに、開発スピードを落とさず、安全にリリース（出口）へとたどり着くための「テストの予告」という考え方について深掘りします。 📌 今回のエピソードのポイント 高速道路の「予告標識」が、ドライバーの安全とスムーズな走行をどう支えているのか もしも予告標識がなかったら？開発現場で起こる「急な車線変更（仕様変更）」や「事故（バグ）」の正体 開発速度を維持したまま「テストを予告する」ことで得られるチームへのメリット リリース直前の「渋滞（コミ…
#10 プロポーザル添削Gemを作成しました——AIを「壁打ち相手」にして採択率を上げる
・11:17
「テックカンファレンスに応募したいけれど、プロポーザルがこれでいいのか自信がない……」 そんな悩みを持つ人のために、GoogleのGeminiで活用できる「プロポーザル添削Gem」を自作しました。今回は、自身のDevelopers Summit（デブサミ）コンテンツ委員としての経験をAIに落とし込み、いかにして「採択されるプロポーザル」を磨き上げるか、その活用法を徹底解説します。 AIに頼り切るのではなく、自分の「思考」と「言語化」をブーストさせるための新しい試みについてお話しします。 📌 今回のエピソードのポイント デブサミ・コンテンツ委員の視点：約400件の審査経験から導き出された…
#9 テストを早めに行うことの大切さ
・12:39
「テストは早めにやったほうがいい」 開発現場でよく耳にするこの言葉、具体的に「いつ」から始めるのが理想なのでしょうか？今回は「シフトレフト」をキーワードに、テストを前倒しすることの真のメリットと、多くの人が陥りがちな勘違いについて深掘りします。 単にスケジュールを早めるだけではない、QAエンジニアとしての立ち振る舞いや、プロセスへの関わり方についてお話しします。 📌 今回のエピソードのポイント 「テストを早めに」の本当の意味：何をもって「テストを開始した」と言えるのか。 シフトレフトの誤解：ただ単にテスト工程を左（前）にずらすだけでは不十分な理由。 実装前からのテスト：コードが書かれる前、…
#8 Dan Northが考える「テストとは何か」——信頼を築くための証拠と対話
・10:32
「テストの目的はバグを見つけること」という固定観念を、さらに一歩押し進めてみませんか？ 今回のエピソードでは、振る舞い駆動開発（BDD）の考案者として知られるDan North氏のブログ記事「We need to talk about testing」を紐解きます。彼が提唱する「テストの目的」とは、単なる不具合の発見ではなく、「証拠を通じて、利害関係者の信頼を高めること」。 第5回で紹介した「納得」というキーワードとも深く共鳴する、Dan North流のテスト観。QAエンジニアが単なる作業者で終わらず、チームの信頼の要となるためのヒントが詰まっています。 📌 今回のエピソードのポイント…
#7 自分が働きやすい場所で働くためには？「言語化」が切り拓くエンジニアの自由
・10:51
「もし明日、今の会社がなくなったら、あなたはどうしますか？」 ショッキングな問いかけですが、終身雇用という考え方が薄れつつある現代において、これは全てのエンジニアが向き合うべきリアルな課題です。今回のエピソードでは、前回のAI時代の生存戦略から一歩進んで、自分が望む環境（働きやすい場所）を自ら手に入れるためのキャリア論を展開します。 会社に依存しすぎず、自分のスキルを正当に評価してもらうための「言語化」の技術と、転職市場における会社とのマッチングの極意についてお話しします。 📌 今回のエピソードのポイント 会社依存からの脱却：リスクヘッジとしての「自立したキャリア観」を持つ大切さ。 自…
#6 QAエンジニアの仕事は今後AIでどうなる？技術を磨き、自分を「言語化」する生存戦略
・12:41
「AIがテストを自動で作るようになったら、QAエンジニアの仕事はなくなるの？」 急速に進化する生成AI（LLM）を前に、多くのエンジニアが抱くこの不安。今回のエピソードでは、QAエンジニアとしてのキャリアとAIの共生について、本質的な視点から切り込みます。 AIがテスト設計で見せる「新人〜中堅レベル」の実力とその限界、そして私たちがAIに代替されないために今磨くべきスキルとは何か。これからの時代を生き抜くための「自分自身の言語化」についてお話しします。 📌 今回のエピソードのポイント AI時代のキャリア形成：特定の技術に固執せず、リスクヘッジの観点から「仕事の本質」を考える。 LLM（…
#5 テストは「納得してもらうこと」である——テストの価値を再定義する3つのスタンス
・13:05
「テストをたくさんやれば、品質は上がるのか？」 QAエンジニアなら一度は直面するこの問いに、ひとつの答えを提示します。今回は、日本のテスト界の第一人者である「にしさん」の2013年の講演から、テストの本質を突く3つのスタンスをご紹介します。 テストを単なる「作業」や「エビデンス」に留めず、チーム全体の「信頼」に変えるための思考法を、一緒に紐解いていきましょう。 📌 今回のエピソードのポイント にしさんが唱える「テストの3つのスタンス」：行動・説明、そして「納得」へ スタンス1：テストとは行動である——「何件やったか」という量への注力とその限界 スタンス2：テストとは説明である——「仕様…
#4 「脱・テスト待ち」への挑戦——2/3(火)開催イベントの告知と登壇者への想い
・8:05
今回のB-Testing.fmは特別編として、2026年2月3日(火)に開催されるオフラインイベントの告知をお届けします。 テーマは、『脱・テスト待ち』 〜"速さ"と"品質"を両立させる、組織とプロセスの再設計〜。 QAエンジニアとして、また本業の10X社での活動を通して日々向き合っている「テスト待ち」という課題。これをいかにして解消し、開発のスピードを落とさずに品質を担保していくのか。イベントの見どころや、共に登壇するメンバーとの「縁」についても深く語ります。 📌 今回のエピソードのポイント イベント概要の紹介：QA目線で語る「リリース頻度向上」のリアルな悩みと乗り越え方。 「脱・テスト…
#3 テストは何のために行うのか？「バグ探し」のその先へ
・10:31
「テストってバグを見つけるためにやってるんですよね？」 もしあなたがそう聞かれたら、どう答えますか？実は、テストの目的はバグ探しだけではありません。今回は、世界的なテスト技術者資格「JSTQB」のシラバスを参考に、テストが果たすべき4つの重要な役割について深掘りします。 ソフトウェアの品質を支える「テスト」の真の意味を知ることで、明日からの開発や評価の視点が変わるはずです。 📌 今回のエピソードのポイント バグを見つけるだけじゃない？ テストが持つ「多角的な目的」とは JSTQBシラバスの変遷：2011年版と最新版で何が変わったのか 「意思決定」の材料としてのテスト：ステークホルダーを…
#2 品質とは何か？——「当たり前」を疑うことから始める品質管理
・10:04
「品質を上げろ！」とよく言われますが、そもそも「品質」の正体とは何でしょうか？ 実は、私たちが普段使っているこの言葉には、時代や文脈によってさまざまな定義があります。書籍『現代品質管理総論』や『ワインバーグのシステム思考法』などを引用しながら、ソフトウェア開発における「品質」の真の意味を解き明かします。 「品質＝バグがないこと」だけではない、多角的な視点を持つことで、あなたのチームの品質への取り組み方が変わるかもしれません。 📌 今回のエピソードのポイント 「品質」の語源を知る：「品（しな）」ではなく「品（ひん）」が良いとは？ JIS規格による定義：対象に備わっている特性が、要求事項をど…
#1 自己紹介
・11:48
ついに始まりました、テストと品質の深淵を探求するポッドキャスト「B-Testing.fm」。 記念すべき第1回は、本番組のホストであるブロッコリーの自己紹介回です。なぜ今、ポッドキャストという形で「品質」や「テスト」の考え方を発信するのか。これまで培ってきた豊富なキャリアや専門的な実績を交え、今後の番組の展望についてお話しします。 テストの自動化やプロセス改善に悩む方はもちろん、アジャイルな開発組織を目指す全ての方に向けた「品質の学び場」の第一歩を、ぜひお聞きください。 📌 今回のエピソードのポイント ブロッコリーって何者？：社内ツールの開発からQA、そして「B-Testing」としての独…