B-Testing.fm

ブロッコリー

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

  1. 3日前

    #18 思考を「プロセス」で表現するメリット：計算問題から学ぶレビューの極意

    私たちは普段、仕事の成果（結果）にばかり目を向けがちですが、その裏側にある「思考のプロセス」を可視化することには、実は大きなメリットがあります。 今回は、簡単な計算問題を例に、思考をプロセスとして切り出すことの重要性を解説します。なぜプロセスを細かく分けると「レビュー」がしやすくなるのか？そのトレードオフとは？ 📌 今回のエピソードのポイント 「プロセス」の定義：手続きに着目し、対象を別のものへ変換する活動プチワーク：8×7-32÷4の解き方から見る、思考の多様性なぜ思考のプロセスを共有すると、ミスやバグの修正が容易になるのかプロセスを細分化することによる「工数」と「品質」のバランス【質問コーナー】開発側の品質保証知識はどの程度？現場で本当に必要なこと 🕒 チャプター (00:00) オープニング(01:44) 思考を「プロセス」という形で表現してみよう(02:47) プチワーク：計算問題から見る「思考の道筋」(03:26) 解答へのアプローチは人によってこれだけ違う(05:33) 細かいプロセスを示すとレビューしやすくなる理由(07:34) 質問コーナー：開発側の品質保証知識はどれくらい？(11:01) エンディング 📢 あなたのご意見をお聞かせください 皆さんは仕事において、結論だけでなく「考えたプロセス」をチームに共有していますか？また、今回の計算問題、あなたならどんなステップで解きましたか？ぜひ感想をお寄せください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    13分

  2. 3月18日

    #17 言語化しない状態の大切さ — 「わからない」がチームの課題をあぶり出す

    「言語化は大事」とよく言われますが、実は言葉にした瞬間にこぼれ落ちてしまう大切なニュアンスがあるのではないでしょうか？ 今回は、あえて「言語化しきれていない状態」を肯定し、特にソフトウェア開発の現場で「わからない」と表明することがいかに品質向上やチームビルディングに寄与するかを深掘りします。4月からの新生活や新しいプロジェクトを控えた方には、ぜひ聴いていただきたい内容です。 📌 今回のエピソードのポイント 言語化することで「失われてしまうもの」の正体QAエンジニアが設計レビューで「わからない」を連発する理由個人の「わからない」を、一瞬で「チームの課題」に変換する魔法開発マネージャーから教わった、実装の「背景」を共有する重要性新入社員や現場に加わったばかりの人が持つべき「最高の武器」 📕 参考文献 「言語化」ってみんな言うけれど #あらたまいくお「テストは単純作業ではなく創造的な活動だ」という意識を浸透させた物語『フレーズ』で体験する、あのチーム 🕒 チャプター (00:00) オープニング(02:02) 言語化の背景と、言葉にした瞬間に失われるもの(04:39) 設計レビューで「わからない」と言うことの効能(07:51) 実装方針の裏にある「背景」を引き出す技術(11:06) 魔法のフレーズ「わからない」でチームを動かす(15:20) エンディング 📢 あなたのご意見をお聞かせください 仕事の中で「これ、言語化できていないけど何か違和感があるな」と感じたことはありませんか？また、あなたが勇気を出して「わからない」と言ったことで、状況が好転したエピソードがあればぜひ教えてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    17分

  3. 3月15日

    #16 コードを1文字も書かずに「テスト」を始める方法

    「何をテストすべきか？」――この問いに対する答えは、実はプログラムを書き始めるずっと前に隠されています。今回は、具体的なパスワードの仕様を例に、設計段階で「テストの視点」を持つことがいかに開発コストを削減し、不具合を未然に防ぐのかを深掘りします。 📌 今回のエピソードのポイント 「実装前のテスト」が最強のコスト削減になる理由： バグを早期に発見することで、修正にかかる総コストを劇的に下げるメカニズムを解説。パスワード仕様から紐解く「テストの考え方」： 4〜12文字、英数字のみ……。シンプルな仕様の中に潜む「曖昧さ」をどう見つけ出すか。開発現場の「認識の齟齬」を未然に防ぐ： 「Aさんはエラー画面を作るだろう」「Bさんはボタン制御でやるだろう」という思い込みが招く悲劇。コードを書かないテストの実践： 「許容する」という言葉ひとつを定義するだけで、不具合の芽を摘み取れる具体例。 📕 参考文献 概説 テスト分析（例題の文章の引用元） 🕒 チャプター (00:00) オープニング(01:58) 復習：なぜ実装前にテスト・レビューをするのか(03:01) 例題：パスワードの仕様からテスト内容を考える(03:53) 回答例(05:56) 仕様の行間を読む(09:24) 設計・開発時点での「思い込み」と追加コストの正体(11:37) 伝えたいこと(14:13) お便り紹介：AI時代のQAと「相性」の話(16:19) エンディング 📢 あなたのご意見をお聞かせください 皆さんの現場では、仕様書を読んだ時点で「これ、どう動くの？」と疑問をぶつける文化はありますか？「実装前に助かった！」というエピソードがあれば、ぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    18分

  4. 3月11日

    #15 エンジニアのキャリア戦略と「実績」の言語化について（デブサミ2026登壇振り返り）

    今回は、2026年2月中旬に開催された「Developers Summit 2026（デブサミ2026）」での登壇を振り返ります。 「副業・独立・キャリアチェンジ」という異なる選択をした3名のエンジニアによるパネルディスカッション。当日はモデレーターとして話しきれなかった「自分の実力をどう表現すべきか」「ロールモデル不在をどう捉えるか」といった、キャリア構築のヒントをさらに詳しくお届けします。 📌 今回のエピソードのポイント デブサミ2026登壇の舞台裏と、副業・独立・キャリアチェンジの三者三様の視点「リプレイス対応」の一言で片付けない、職務経歴書での「自分の工夫」の出し方ロールモデルは探すもの？それとも競合？ビジネス視点でのキャリア戦略1on1で見つけた「輝く言葉」をそのまま経歴書に書き写すべき理由 📕参考文献 副業？ 独立？ キャリアチェンジ？ それぞれの視点から語る、エンジニア人生「キャリアの磨き方」（登壇したセッション）キャリアにロールモデルを求めることは、自ら過当競争に飛び込む戦略上愚かな行為 🕒 チャプター (00:00) オープニング(01:42) デブサミ2026登壇の振り返り(05:40) 私のキャリア戦略と「貢献」のモチベーション(08:42) よくある質問①：自分の実力をどう表現すればいいか(11:56) よくある質問②：周りにロールモデルがいない時の考え方(15:18) よくある質問③：年収の「天井」とそこへの到達路(16:03) カジュアル面談や1on1をキャリアに活かすスタンス(19:24) お便り紹介(20:54) エンディング 📢 あなたのご意見をお聞かせください あなたは自分の「実績」を語る時、どんな工夫をしていますか？また、身近にロールモデルはいますか？キャリアに関するお悩みや、今回の感想をぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム：⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    22分

  5. 3月8日

    #14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方

    今回は、MAXさんによるブログ記事「失敗の許容度を設計に組み込む」をテーマに、変化の速い現代の開発における「品質」の定義を掘り下げます。 「失敗しないこと」を目指すのではなく、「失敗をいかに早く検知し、訂正できるか」という視点。このマインドセットの転換が、AIを活用したテスト設計や、継続的なプロダクト運用においてどのような意味を持つのか、自身の共感ポイントを交えて語ります。 📌 今回のエピソードのポイント 品質とは「失敗を防ぐこと」ではなく「最速で検知・修正できる仕組み」であるテストの網羅性や正確性以上に追求すべき「プロセスの健牢さ（復元力）」プロダクト開発と運用は、本質的に「訂正し続けるサイクル」であるAIによるテスト設計を「仮説」と捉え、現実とのギャップから隠れたエッジケースをあぶり出す手法 📕 参考文献 失敗の許容度を設計に組み込む技術力あげたい 🕒 チャプター (00:00) オープニング(02:00) 記事紹介：「失敗の許容度を設計に組み込む」(03:01) 品質＝「最速で検知し、修正できるシステム」の設計(04:30) テストが追求すべき「復元力」とは(06:31) プロダクト開発・運用における「訂正し続けること」の重要性(07:53) AIを活用したテスト設計：仮説と現実のギャップを意図的に作る(11:16) エンディング 📢 あなたのご意見をお聞かせください 皆さんのチームでは、「品質」をどのように定義していますか？また、「失敗を許容する設計」についてどう考えますか？ぜひ感想をお寄せください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    13分

  6. 3月4日

    #13 JaSST'26 Tokyoでクラシフィケーションツリー技法のワークショップを開催します！

    今回は、2026年3月20日に開催される「JaSST'26 Tokyo」でのワークショップ登壇についてお届けします。テーマは、複雑なテスト条件を整理するのに強力な武器となる「クラシフィケーションツリー技法」。JSTQBのアドバンスドレベルでも扱われるこの技法を、なぜ今ワークショップで学ぶべきなのか？その理由と、翌日に予定している恒例（？）の「テスト花見」についてもお話しします。 📌 今回のエピソードのポイント コミュニティ活動としてのPodcast： 自身の活動の軸足である「WACATE」や「ASTER」への想いクラシフィケーションツリー技法とは： 複数の条件を組み合わせるテスト設計において、デシジョンテーブルとの使い分けやメリットを解説JaSST'26 Tokyoの見どころ： 2026年版「ソフトウェアテスト最初の第一歩」として、ワークを通じた体感的スキルの習得貴重な学習機会： 日本語の文献が少ないこの技法を、手順付きで学べるワークショップの希少性【番外編】テスト花見の復活： 2025年のリベンジ！エンジニア同士で語らう「テスト花見」へのお誘い 📕参考文献 JaSST’26 Tokyoテスト花見 2026 🕒 チャプター (00:00) オープニング(01:38) クラシフィケーションツリー技法とは何か(03:03) JaSST'26 Tokyoでの開催概要(03:38) セッション内容：ワークで学ぶテスト設計の勘所(05:30) WACATEのノウハウを凝縮したコンテンツ(07:04) 翌日の「テスト花見」について(09:12) エンディング 📢 あなたのご意見をお聞かせください 皆さんは「クラシフィケーションツリー技法」を実務で使ったことはありますか？また、JaSSTなどのカンファレンスで「こんなワークショップを受けてみたい！」というテーマがあればぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    11分

  7. 3月1日

    #12 ソフトウェアテストの「縁の下の力持ち」ASTER。多岐にわたる活動とは？

    「ASTER」という名前、テストエンジニアなら一度は聞いたことがあるはず。でも、具体的にどんな活動をしている組織なのか、詳しく説明できる人は意外と少ないのではないでしょうか？今回は、日本のソフトウェアテスト技術を支えるNPO法人「ASTER」の裏側に迫ります。 📌 今回のエピソードのポイント ASTERの正体は、非営利で技術振興を行うNPO法人実はここが運営！JSTQBの資格認定とシラバス翻訳の裏側20年以上続くテストの祭典「JaSST」の規模感パワポ形式で無料配布中！？驚きの教育支援と、セミナー参加者を支える「一時保育」制度 📕 参考文献 NPO法人ソフトウェアテスト技術振興協会JSTQBシラバスJaSST（ソフトウェアテストシンポジウム）テスト設計コンテストASTERセミナー標準テキスト 🕒 チャプター (00:00) オープニング(01:30) ASTER（ソフトウェアテスト技術振興協会）とは何か(02:09) JSTQBの資格認定・運営：シラバス無料公開の価値(04:03) テストの祭典「JaSST」：全国に広がるシンポジウムの歴史(04:49) 調査研究事業：テスト開発方法論からAIの品質保証まで(05:52) 教育事業：テスト設計コンテストと社内研修に使える無料テキスト(07:42) ASTERの活動まとめ：サイトを覗いてみるだけでも価値がある(08:47) エンディング 📢 あなたのご意見をお聞かせください 皆さんは、JSTQBのシラバスを読んだり、JaSSTに参加したことはありますか？皆さんのASTERの活動との関わりを教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    10分

  8. 2月22日

    #11 リリース直前の混乱を防ぐ！高速道路の出口標識に学ぶ「スムーズなテスト活動」の極意

    リリース直前になってバグが多発し、開発現場がパニックになる……そんな経験はありませんか？ 今回は、以前「Findy Engineer Lab」に寄稿した記事をもとに、開発スピードを落とさず、安全にリリース（出口）へとたどり着くための「テストの予告」という考え方について深掘りします。 📌 今回のエピソードのポイント 高速道路の「予告標識」が、ドライバーの安全とスムーズな走行をどう支えているのかもしも予告標識がなかったら？開発現場で起こる「急な車線変更（仕様変更）」や「事故（バグ）」の正体開発速度を維持したまま「テストを予告する」ことで得られるチームへのメリットリリース直前の「渋滞（コミット過多）」や「手戻り」を最小限に抑えるための戦略的アプローチ 📕参考文献 高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話 🕒 チャプター (00:00) オープニング(02:03) 高速道路の出口標識のようなテスト活動とは(03:03) 予告標識がスムーズな合流と減速を実現する(04:41) 開発スピードとリリース（出口）をリンクさせる考え方(05:48) リリース直前の「事故」を防ぎ、次のチャンスに備える(07:12) エンディング 📢 あなたのご意見をお聞かせください 皆さんのプロジェクトでは、リリース直前に「突然の出口」が現れてパニックになることはありませんか？「うちはこんな予告標識（工夫）を置いているよ！」といった事例があれば、ぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    9分
すべて見る（18）

番組について

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

情報

  • クリエイター
    ブロッコリー
  • 配信期間
    26年
  • エピソード
    18
  • 制限指定
    不適切な内容を含まない
  • Copyright
    © ブロッコリー
  • 番組のWebサイト
    B-Testing.fm

その他のおすすめ