B-Testing.fm

ブロッコリー
  • 0,0 (0)
  • ТЕХНОЛОГИИ
  • ЕЖЕНЕДЕЛЬНО

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

  1. -2 ДН.

    #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 мин.

  2. -5 ДН.

    #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 мин.

  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 мин.

  4. 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 мин.

  5. 22 ФЕВР.

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

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

    9 мин.

  6. 19 ФЕВР.

    #10 プロポーザル添削Gemを作成しました——AIを「壁打ち相手」にして採択率を上げる

    「テックカンファレンスに応募したいけれど、プロポーザルがこれでいいのか自信がない……」 そんな悩みを持つ人のために、GoogleのGeminiで活用できる「プロポーザル添削Gem」を自作しました。今回は、自身のDevelopers Summit（デブサミ）コンテンツ委員としての経験をAIに落とし込み、いかにして「採択されるプロポーザル」を磨き上げるか、その活用法を徹底解説します。 AIに頼り切るのではなく、自分の「思考」と「言語化」をブーストさせるための新しい試みについてお話しします。 📌 今回のエピソードのポイント デブサミ・コンテンツ委員の視点：約400件の審査経験から導き出された「良いプロポーザル」の観点。「プロポーザル添削Gem」の誕生秘話：ブログ記事の観点をGeminiに学習させ、壁打ち相手に変える方法。実際の添削デモ：ブロッコリーさん自身の過去のプロポーザルをAIはどう評価したか？具体的なフィードバック例を紹介。Gem活用時の注意点：評価ランク（S〜D）はあくまで目安。他の応募者との相対評価やバランスが鍵となる。修正案をあえて出さない理由：自分の言葉で語る大切さを守るため、あえて制限している機能について。 📕参考文献 プロポーザル添削Gemプロポーザルを書くときに心がけ、採択するときに注目していることカンファレンスの審査委員として6年で約400件のプロポーザルに投票コメントをしたときの観点note添削用のGemを作りました 🕒 チャプター (00:00) オープニング(01:12) 今回のテーマ：プロポーザル添削Gemを作成しました(01:23) デブサミ・コンテンツ委員の主な仕事（採択・プログラム提案）(02:27) 参考にしたブログ記事：プロポーザルを書く際のコツと審査の観点(03:33) Geminiで活用できる「プロポーザル添削Gem」の紹介(05:05) 実演：過去の自身のプロポーザルを添削してみた結果(05:59) 項目別の評価と、具体的な改善アドバイスの内容(07:39) 活用時の注意点：評価内容が採択を保証するわけではない理由(07:42) 「修正案」の提示をあえて制限している、ブロッコリーさんのこだわり(08:41) 開発のきっかけ：note添削Gemをヒントに(09:26) まとめ：Gemを活用して、より良いプロポーザルを世に送り出そう(09:51) エンディング 📢 あなたのご意見をお聞かせください 「このGemを使ってみた感想」や「実際にプロポーザルを書いてみた苦労話」など、ぜひお聞かせください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    11 мин.

  7. 15 ФЕВР.

    #9 テストを早めに行うことの大切さ

    「テストは早めにやったほうがいい」 開発現場でよく耳にするこの言葉、具体的に「いつ」から始めるのが理想なのでしょうか？今回は「シフトレフト」をキーワードに、テストを前倒しすることの真のメリットと、多くの人が陥りがちな勘違いについて深掘りします。 単にスケジュールを早めるだけではない、QAエンジニアとしての立ち振る舞いや、プロセスへの関わり方についてお話しします。 📌 今回のエピソードのポイント 「テストを早めに」の本当の意味：何をもって「テストを開始した」と言えるのか。シフトレフトの誤解：ただ単にテスト工程を左（前）にずらすだけでは不十分な理由。実装前からのテスト：コードが書かれる前、設計や要件定義の段階でQAができること。不具合の「発見」から「予防」へ：早い段階で関わることで得られる、圧倒的なコストパフォーマンス。理想的なテストの開始タイミング：プロジェクトのどの地点からQAが介入すべきか。 📕参考文献 ISTQB テスト技術者資格制度Foundation Level シラバス日本語版Version 2023V4.0.J02『ソフトウェア開発201の鉄則』The Economic Impacts of Inadequate Infrastructure for Software Testing 🕒 チャプター (00:00) オープニング(00:55) 今回のテーマ：テストを早めに行うことの大切さについて(01:30) 「シフトレフト」という概念：テスト工程を前倒しする考え方(02:15) シフトレフトがもたらす最大のメリット：不具合修正コストの削減(03:45) よくある間違い：テスト実行だけを早めてもうまくいかない(05:10) 実装前にQAができること：要件レビューとテスト設計の並行(06:50) 「テスト＝画面を触ること」という固定観念を捨てる(08:15) 理想の介入ポイント：企画・要件定義の段階からQAが同席する価値(09:30) まとめ(10:10) エンディング 📢 あなたのご意見をお聞かせください 皆さんのプロジェクトでは、どのタイミングからテストを意識し始めていますか？ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    13 мин.

  8. 8 ФЕВР.

    #8 Dan Northが考える「テストとは何か」——信頼を築くための証拠と対話

    「テストの目的はバグを見つけること」という固定観念を、さらに一歩押し進めてみませんか？ 今回のエピソードでは、振る舞い駆動開発（BDD）の考案者として知られるDan North氏のブログ記事「We need to talk about testing」を紐解きます。彼が提唱する「テストの目的」とは、単なる不具合の発見ではなく、「証拠を通じて、利害関係者の信頼を高めること」。 第5回で紹介した「納得」というキーワードとも深く共鳴する、Dan North流のテスト観。QAエンジニアが単なる作業者で終わらず、チームの信頼の要となるためのヒントが詰まっています。 📌 今回のエピソードのポイント Dan Northってどんな人？：BDD（振る舞い駆動開発）を生み出し、世界の開発プロセスに影響を与えた人物。テストの真の目的：具体的な「証拠」を提示することで、関わるすべての人（利害関係者）の信頼を勝ち取るプロセス。証拠なき仕事は「テスト」ではない？：Dan Northの鋭い指摘から、自分たちの日常業務を振り返る。テスト思考：画面を操作する前の「アーキテクチャ設計」や「UIコンポーネントの選択」こそがテストの本質であるという考え方。「労力」は外注できても「能力」は外注できない：第6回のAIの話とも繋がる、エンジニア自身の思考力の重要性。 📕参考文献 We need to talk about testing翻訳記事「テストについて話し合わなくてはならない」 🕒 チャプター (00:00) オープニング(01:24) 今回のテーマ：Dan Northが考えるテストとは何か(01:42) Dan Northの紹介と、彼が書いた「テストについて話し合わなくてはならない」という記事について(02:25) Dan North流「テストの目的」の定義(02:45) 用語解説①：利害関係者（ステークホルダー）とは誰を指すのか？(03:25) 用語解説②：「信頼を高める」ことの本当の意味(03:43) 用語解説③：議論の余地のない「証拠（データ）」の重要性(04:08) 信頼を高めない作業は「テストをしていない」のと同じ(05:07) 第5回の「にしさん」の考え方との共通点(05:59) 「テスト思考」という概念：設計段階から不具合を予防する(07:51) テスト実行の「前」に考えることの重要性(08:11) まとめ：信頼を築くために、私たちは何を証拠として示すべきか(09:11) エンディング 📢 あなたのご意見をお聞かせください Dan North氏の「信頼を高めない作業はテストではない」という言葉、あなたはどう感じましたか？ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠こちらからお気軽にどうぞ。⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    11 мин.
См. все (15)

Об этом подкасте

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

Информация

  • Автор
    ブロッコリー
  • Годы выхода
    2 тыс.
  • Выпуски
    15
  • Ограничения
    Без ненормативной лексики
  • Авторские права
    © ブロッコリー
  • Сайт подкаста
    B-Testing.fm