B-Testing.fm

ブロッコリー
  • 0.0 (0)
  • Technology
  • Updated Weekly

B-Testing.fmは、テストや品質の深淵を探求し、現場で役立つ思考のヒントを届ける番組です。「テストは何のために行うのか？」「品質の正体とは？」抽象的で捉えどころのないこれらの言葉をQAエンジニアの視点から紐解き、自分たちの言葉で「言語化」できるようになることを目指します。 【配信日時】 毎週月曜 朝8:00配信 🎙 ホストプロフィール：ブロッコリー ・Developers Summitでのベストスピーカー賞など多数の受賞歴を持つQAエンジニア。 ・「Holistic Testing」日本唯一の公式トレーナー ・『Agile Testing Condensed』などの翻訳を通じて、知見を発信中。 開発者、QA、PdMなど、プロダクトを良くしたい全ての方へ。あなたの「テスト観」をアップデートする時間をお楽しみください。 📢 番組に参加する リスナーの皆様からのお便りをお待ちしています！ ・ハッシュタグ：#b_testing （ポストする） ・投稿フォームはこちら ・公式サイト

  1. 2d ago

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

  2. Jul 12

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

  3. Jul 5

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

  4. Jun 28

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

  5. Jun 21

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

  6. Jun 17

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

  7. Jun 14

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

  8. Jun 7

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

See All (42)

About

B-Testing.fmは、テストや品質の深淵を探求し、現場で役立つ思考のヒントを届ける番組です。「テストは何のために行うのか？」「品質の正体とは？」抽象的で捉えどころのないこれらの言葉をQAエンジニアの視点から紐解き、自分たちの言葉で「言語化」できるようになることを目指します。 【配信日時】 毎週月曜 朝8:00配信 🎙 ホストプロフィール：ブロッコリー ・Developers Summitでのベストスピーカー賞など多数の受賞歴を持つQAエンジニア。 ・「Holistic Testing」日本唯一の公式トレーナー ・『Agile Testing Condensed』などの翻訳を通じて、知見を発信中。 開発者、QA、PdMなど、プロダクトを良くしたい全ての方へ。あなたの「テスト観」をアップデートする時間をお楽しみください。 📢 番組に参加する リスナーの皆様からのお便りをお待ちしています！ ・ハッシュタグ：#b_testing （ポストする） ・投稿フォームはこちら ・公式サイト

Information

  • Creator
    ブロッコリー
  • Years Active
    2026
  • Episodes
    42
  • Rating
    Clean
  • Copyright
    © ブロッコリー
  • Show Website
    B-Testing.fm

You Might Also Like