B-Testing.fm

今回は、テスト技法の中でも数学的な裏付けを持つ「直交表」について解説します！直交表の定義や歴史（タグチメソッド）から、コーヒーショップのカスタマイズを例にした具体的なテストケースの作り方までを分かりやすく紹介。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アプリでのフォローをぜひお願いします！

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

テストケースを効率的に削減するために「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アプリでのフォローをぜひお願いします！

前回までの「クラシフィケーションツリー技法」の基本編に続き、今回は作成したテストケースをどのように絞り込み（剪定し）、効率化していくかについて深掘りします。「網羅基準」という言葉は知っていても、実務でどう使い分けるべきか迷っている方も多いのではないでしょうか。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アプリでのフォローをぜひお願いします！

前回の「クラシフィケーションツリー」の作成解説に続き、今回はテスト編です。「ツリーは書けたけれど、そこからどうやってテストケースに落とし込めばいいの？」という疑問を解消します。

実は、このテストケースの具体的な導き出し方について詳しく書かれた文献は、日本語ではほとんど存在しません。今回は、独自に言語化した「機械的にテストケースを作成するステップ」を、コーヒーショップのカスタマイズという身近なお題を使って徹底解説します。

ディシジョンテーブル（決定表）にも通ずる、漏れのない組み合わせの作り方をぜひマスターしてください。

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

• 文献には載っていない？テストケース作成の具体的な手順
• 「最下層のクラスから直線を引く」という最初の一歩
• 漏れを防ぐための鉄則：「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アプリでのフォローをぜひお願いします！

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

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

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