今回から新しいテスト設計技法シリーズがスタートします。取り上げるのは「クラシフィケーションツリー技法」。テスト対象のデータ領域を樹形図で可視化するこの手法について、初心者の方でもすぐに実践できるよう、コーヒーショップのカスタマイズを例にステップ・バイ・ステップで詳しく解説します。

📌 今回のエピソードのポイント

• クラシフィケーションツリー技法の定義とメリット
• 基本用語「ルート」「クラシフィケーション」「クラス」の役割
• コーヒーショップの複雑な価格設定をツリーで整理する手順
• 「最下層は必ずクラスにする」など、作成時の重要なルール
• 感想紹介：テスト設計コンテスト（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アプリでのフォローをぜひお願いします！

E2E（エンド・ツー・エンド）の自動テストを作成する際、一つの長いシナリオにするか、細かく分割するか迷ったことはありませんか？今回は「テストの目的」に焦点を当て、ピザの注文システムを具体例に、状況に応じた最適なテストの組み方について深掘りします。テスト実行時間の短縮と、不具合の検出精度を両立させるためのヒントをお届けします。

📌 今回のエピソードのポイント

• E2Eテストの定義と前提条件（UI経由・実データ接続）
• 一連の業務遂行を確認したい時の「長めシナリオ」のメリット
• 不具合検出を優先したい時に「シナリオを分割」すべき理由
• 後続工程のバグを隠さないための、直接URLアクセスの活用術
• 質問コーナー：スプリント開発における「QAの待ち時間」の厳密な評価は必要か？

🕒 チャプター

• (00:00) オープニング
• (01:32) E2E自動テストの作り方は「目的」で変わる
• (03:27) シナリオを「長くする」か「分ける」かの判断基準
• (05:01) まとめ：最適なテスト設計のために
• (05:32) 質問コーナー：QAの待ち時間を厳密に評価する方法はある？
• (08:01) エンディング

📢 あなたのご意見をお聞かせください

自動テストのシナリオ設計で、あなたが「これだけは譲れない」というこだわりや、逆に失敗してしまった経験などはありますか？

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

前々回の「デシジョンテーブルの作り方」に続き、今回は作成したテーブルをどのように効率化していくか、その具体的なテクニックを深掘りします。テストケースをロジカルに、かつ「機械的に」削るための「簡略化」と「禁則」の考え方を解説。ただ削るだけでなく、あえて「削らない」という戦略的な判断基準についても触れています。

📌 今回のエピソードのポイント

• デシジョンテーブルにおける「簡略化」の定義と手順
• 「ハイフン（ー）」を用いたパターンの圧縮方法
• 期待結果が異なる場合に陥りがちな簡略化の罠
• 「禁則」を用いて物理的に不可能なパターンを削除する
• 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アプリでのフォローをぜひお願いします！

ゴールデンウィーク中に足を運んだ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アプリでのフォローをぜひお願いします！

「最新の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アプリでのフォローをぜひお願いします！

「ソフトウェアテストの勉強をしたいけれど、座学だけでは物足りない」「社外のエンジニアと深く交流したい」――そんな悩みを持つ若手エンジニアにぴったりのイベントを紹介します。

今回は、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アプリでのフォローをぜひお願いします！

前回の「境界値分析（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アプリでのフォローをぜひお願いします！

今回は、テスト設計の基本中の基本でありながら、実は奥が深い「境界値分析（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アプリでのフォローをぜひお願いします！

今回のエピソードでは、5月に予定されている3つの大きな登壇イベントについて詳しくご紹介します。

10Xでの実践を通じた「QA＝テスト」という呪縛を解くためのアプローチや、マイクロサービスにおけるQAの進め方についての質問にもお答えします。

📌 今回のエピソードのポイント

• 【Scrum Fest Niigata 2026】V字モデルの右側にしわ寄せがいかないチーム作り
• 【GENDA Tech Talk #04】少数精鋭のQA組織はどう戦うべきか？
• 【Flexy meetup】10x流「シフトレフト」な品質保証を1時間みっちり深掘り
• リスナー質問：複数のマイクロサービスが連動する変更、QAはどう進める？

📕参考文献

• ピタゴラスイッチ
• テキシコー
• Scrum Fest Niigata 2026
• GENDA 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アプリでのフォローをぜひお願いします！

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アプリでのフォローをぜひお願いします！