DiscoverB-Testing.fm
B-Testing.fm
Claim Ownership

B-Testing.fm

Author: ブロッコリー

Subscribed: 0Played: 0
Share

Description

B-Testing.fmは、テストや品質の深淵を探求し、現場で役立つ思考のヒントを届ける番組です。「テストは何のために行うのか?」「品質の正体とは?」抽象的で捉えどころのないこれらの言葉をQAエンジニアの視点から紐解き、自分たちの言葉で「言語化」できるようになることを目指します。

【配信日時】 毎週月曜 朝8:00配信

🎙 ホストプロフィール:ブロッコリー
・Developers Summitでのベストスピーカー賞など多数の受賞歴を持つQAエンジニア。
・「Holistic Testing」日本唯一の公式トレーナー
・『Agile Testing Condensed』などの翻訳を通じて、知見を発信中。

開発者、QA、PdMなど、プロダクトを良くしたい全ての方へ。あなたの「テスト観」をアップデートする時間をお楽しみください。


📢 番組に参加する

リスナーの皆様からのお便りをお待ちしています!
・ハッシュタグ:#b_testing (ポストする
投稿フォームはこちら
公式サイト
15 Episodes
Reverse
今回は、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アプリでのフォローをぜひお願いします!
今回は、MAXさんによるブログ記事「失敗の許容度を設計に組み込む」をテーマに、変化の速い現代の開発における「品質」の定義を掘り下げます。「失敗しないこと」を目指すのではなく、「失敗をいかに早く検知し、訂正できるか」という視点。このマインドセットの転換が、AIを活用したテスト設計や、継続的なプロダクト運用においてどのような意味を持つのか、自身の共感ポイントを交えて語ります。📌 今回のエピソードのポイント品質とは「失敗を防ぐこと」ではなく「最速で検知・修正できる仕組み」であるテストの網羅性や正確性以上に追求すべき「プロセスの健牢さ(復元力)」プロダクト開発と運用は、本質的に「訂正し続けるサイクル」であるAIによるテスト設計を「仮説」と捉え、現実とのギャップから隠れたエッジケースをあぶり出す手法📕 参考文献失敗の許容度を設計に組み込む技術力あげたい🕒 チャプター(00:00) オープニング(02:00) 記事紹介:「失敗の許容度を設計に組み込む」(03:01) 品質=「最速で検知し、修正できるシステム」の設計(04:30) テストが追求すべき「復元力」とは(06:31) プロダクト開発・運用における「訂正し続けること」の重要性(07:53) AIを活用したテスト設計:仮説と現実のギャップを意図的に作る(11:16) エンディング📢 あなたのご意見をお聞かせください皆さんのチームでは、「品質」をどのように定義していますか?また、「失敗を許容する設計」についてどう考えますか?ぜひ感想をお寄せください。X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
今回は、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アプリでのフォローをぜひお願いします!
「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アプリでのフォローをぜひお願いします!
リリース直前になってバグが多発し、開発現場がパニックになる……そんな経験はありませんか?今回は、以前「Findy Engineer Lab」に寄稿した記事をもとに、開発スピードを落とさず、安全にリリース(出口)へとたどり着くための「テストの予告」という考え方について深掘りします。📌 今回のエピソードのポイント高速道路の「予告標識」が、ドライバーの安全とスムーズな走行をどう支えているのかもしも予告標識がなかったら?開発現場で起こる「急な車線変更(仕様変更)」や「事故(バグ)」の正体開発速度を維持したまま「テストを予告する」ことで得られるチームへのメリットリリース直前の「渋滞(コミット過多)」や「手戻り」を最小限に抑えるための戦略的アプローチ📕参考文献高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話🕒 チャプター(00:00) オープニング(02:03) 高速道路の出口標識のようなテスト活動とは(03:03) 予告標識がスムーズな合流と減速を実現する(04:41) 開発スピードとリリース(出口)をリンクさせる考え方(05:48) リリース直前の「事故」を防ぎ、次のチャンスに備える(07:12) エンディング📢 あなたのご意見をお聞かせください皆さんのプロジェクトでは、リリース直前に「突然の出口」が現れてパニックになることはありませんか?「うちはこんな予告標識(工夫)を置いているよ!」といった事例があれば、ぜひ教えてください。X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
「テックカンファレンスに応募したいけれど、プロポーザルがこれでいいのか自信がない……」そんな悩みを持つ人のために、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アプリでのフォローをぜひお願いします!
「テストは早めにやったほうがいい」開発現場でよく耳にするこの言葉、具体的に「いつ」から始めるのが理想なのでしょうか?今回は「シフトレフト」をキーワードに、テストを前倒しすることの真のメリットと、多くの人が陥りがちな勘違いについて深掘りします。単にスケジュールを早めるだけではない、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アプリでのフォローをぜひお願いします!
「テストの目的はバグを見つけること」という固定観念を、さらに一歩押し進めてみませんか?今回のエピソードでは、振る舞い駆動開発(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アプリでのフォローをぜひお願いします!
「もし明日、今の会社がなくなったら、あなたはどうしますか?」ショッキングな問いかけですが、終身雇用という考え方が薄れつつある現代において、これは全てのエンジニアが向き合うべきリアルな課題です。今回のエピソードでは、前回のAI時代の生存戦略から一歩進んで、自分が望む環境(働きやすい場所)を自ら手に入れるためのキャリア論を展開します。会社に依存しすぎず、自分のスキルを正当に評価してもらうための「言語化」の技術と、転職市場における会社とのマッチングの極意についてお話しします。📌 今回のエピソードのポイント会社依存からの脱却:リスクヘッジとしての「自立したキャリア観」を持つ大切さ。自分のスキルを証明する「言語化」:QAエンジニアにありがちな「テスト設計ができます」という曖昧な表現をどう変えるか。履歴書・経歴書は「自分を伝える武器」:自分がどういう考えを持ってテストを遂行しているか、そのプロセスを明文化する。会社との幸せなマッチング:自分の「テスト観」をぶつけることで、相性の悪い会社をあらかじめフィルタリングする手法。登壇イベントのお知らせ:2月19日(木)「Developers Summit 2026」にて、副業・独立・キャリアチェンジをテーマとしたパネルディスカッションに登壇!📕参考文献⁠⁠⁠Developers Summit 2026 での登壇セッション ”副業? 独立? キャリアチェンジ? それぞれの視点から語る、エンジニア人生「キャリアの磨き方」”⁠🕒 チャプター(00:00) オープニング(01:39) 今回のテーマ:自分が働きやすい場所で働くためには?(02:08) エンジニア人生で大事なこと:自分のスキルを言語化し、会社依存を避ける(02:54) 「明日、会社がなくなったら?」という問いを自分に投げかける(04:13) 経歴書に対する会社の反応は分かれる(05:15) 給職者と会社、双方が幸せになるための「ミスマッチ防止策」(07:03) 開発者以上に難しい?QAエンジニアの成果とスキルの伝え方(07:43) 告知:Developers Summit 2026(デブサミ)登壇のお知らせ(08:57) デブサミの内容:副業・独立・キャリアチェンジ、3人の視点で語るキャリアの磨き方(09:28) エンディング📢 感想・お悩みをお寄せください「自分のスキルをどう言語化すればいいか分からない」といった具体的なお悩みも大歓迎です!X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
「AIがテストを自動で作るようになったら、QAエンジニアの仕事はなくなるの?」急速に進化する生成AI(LLM)を前に、多くのエンジニアが抱くこの不安。今回のエピソードでは、QAエンジニアとしてのキャリアとAIの共生について、本質的な視点から切り込みます。AIがテスト設計で見せる「新人〜中堅レベル」の実力とその限界、そして私たちがAIに代替されないために今磨くべきスキルとは何か。これからの時代を生き抜くための「自分自身の言語化」についてお話しします。📌 今回のエピソードのポイントAI時代のキャリア形成:特定の技術に固執せず、リスクヘッジの観点から「仕事の本質」を考える。LLM(大規模言語モデル)の仕組みとテスト設計:AIは「計算」しているのではなく「確率」で推測しているという事実。AIによるテスト設計の現状評価:なぜAIのバージョンが上がっても、テスト設計の精度は劇的に向上しないのか。「わからないものはレビューできない」の罠:AIに任せきりにすることの危険性と、人間のレビュー能力の重要性。今こそテスト技術を磨くべき理由:AIを使いこなすためにも、まずは既存のテスト設計技法を血肉化する。自分の能力を「言語化」しよう:AIとの対話において、自分が何を提供できるのかを明確にする大切さ。📕参考文献⁠5. QAエンジニアの仕事は今後AIでどうなるんですか?的質問について - テストウフCAST | Podcast on Spotify⁠⁠AI(ChatGPT-4)によるテスト設計作成の現状を評価する⁠⁠LLMのキモい算術⁠⁠ベテランプログラマは生成AIをどう活用しているのか?そして初学者は生成AIをどう活用すべきか?⁠⁠AI時代のソフトウェア開発を考える(2025/07版)⁠⁠ブロッコリーのポスト⁠🕒 チャプター(00:00) オープニング(00:50) 今回のテーマ:QAエンジニアのキャリアと生成AI(01:31) 参考ポッドキャスト『テストウフCAST』に見るAIへの向き合い方(03:30) 現状のAIに対する私の評価:3年前の発表から変わらぬ「新人〜中堅レベル」(04:32) LLMの「キモい算術」から紐解く、AIが答えを出す仕組み(07:41) テスト設計に対するAIの学習は、実はあまり進んでいない?(08:22) AIに投げた「お願い」がろくな結果を生まない境界線(08:43) 労力は外注できても、能力は外注できない(10:10) 私の意見:基本のテスト技術を磨き、自分を言語化しよう(11:10) エンディング📢 感想をお寄せくださいAIと隣り合わせのこれからのQA業務について、あなたはどう考えますか?X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
「テストをたくさんやれば、品質は上がるのか?」QAエンジニアなら一度は直面するこの問いに、ひとつの答えを提示します。今回は、日本のテスト界の第一人者である「にしさん」の2013年の講演から、テストの本質を突く3つのスタンスをご紹介します。テストを単なる「作業」や「エビデンス」に留めず、チーム全体の「信頼」に変えるための思考法を、一緒に紐解いていきましょう。📌 今回のエピソードのポイントにしさんが唱える「テストの3つのスタンス」:行動・説明、そして「納得」へスタンス1:テストとは行動である——「何件やったか」という量への注力とその限界スタンス2:テストとは説明である——「仕様を100%網羅した」という説明責任と、潜む「無責任」スタンス3:テストとは納得してもらうことである——ステークホルダーと「全体像」を共有する対話の重要性「納得」を生むためのテスト設計力:モデリングやテスト設計技法が、なぜ「納得」への近道になるのか開発者と責任を分かち合う:バグが見つかった時にお互いを責めない「合意」の作り方📕参考ページ⁠テスト設計コンテスト 2013 関西地域予選の招待講演の動画(タイムスタンプ付きのリンクにしています)⁠⁠講演スライド⁠⁠文字起こしの記事⁠🕒 チャプター(00:00) オープニング(00:48) 今回のテーマ:テストは「納得してもらうこと」である(01:35) 抜粋元:テスト設計コンテスト2013でのにしさんの招待講演(03:16) テストに対する3つのスタンス(03:40) スタンス1:テストとは行動である(期間や件数での対話)(05:28) スタンス2:テストとは説明である(仕様書網羅と説明責任)(06:51) 説明責任が招く「説明無責任」とは?(07:57) スタンス3:テストとは納得してもらうことである(08:26) 「押し付け」ではなく「一緒に検討する」コミュニケーション(09:05) なぜ今、テスト設計力やモデリングが重要なのか(11:11) まとめ:3つのスタンスを使い分けていますか?(11:41) エンディング・お便り募集📢 感想をお寄せください今日の話を聞いて、あなたはどのスタンスでテストに向き合いたいと感じましたか?X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
今回のB-Testing.fmは特別編として、2026年2月3日(火)に開催されるオフラインイベントの告知をお届けします。テーマは、『脱・テスト待ち』 〜"速さ"と"品質"を両立させる、組織とプロセスの再設計〜。QAエンジニアとして、また本業の10X社での活動を通して日々向き合っている「テスト待ち」という課題。これをいかにして解消し、開発のスピードを落とさずに品質を担保していくのか。イベントの見どころや、共に登壇するメンバーとの「縁」についても深く語ります。📌 今回のエピソードのポイントイベント概要の紹介:QA目線で語る「リリース頻度向上」のリアルな悩みと乗り越え方。「脱・テスト待ち」の本質:前回の「テストの目的」とも繋がる、不具合の「予防」という考え方。オフラインならではの楽しみ:イベント後の懇親会で、リスナーの皆さんと直接お話しできることへの期待。📕参考ページ⁠イベントページ「『脱・テスト待ち』〜"速さ"と"品質"を両立させる、組織とプロセスの再設計〜」( https://bitkey.connpass.com/event/377909/ )⁠⁠【QA部屋第4回】「QAのキャリア論とテスト設計の魅力」ゲスト:株式会社ナレッジワーク・河野哲也さん - 10X.fm⁠( ⁠https://open.spotify.com/episode/20WhZHEukFphvByQHvgaTZ )🕒 チャプター(00:00) オープニング(00:45) 今回は特別編!2月3日開催イベントの告知(01:08) イベント詳細:『脱・テスト待ち』〜組織とプロセスの再設計〜(01:57) 「不具合を予防する」——テスト待ちを解消するための思考(02:45) 登壇者紹介①:ナレッジワーク・tettanさんとの大学時代からの縁(04:37) 登壇者紹介②:ビットキー・白木さんとの前々職時代のエピソード(05:22) 当日のタイムスケジュールとパネルディスカッションの内容(06:05) オフライン開催への想いと、懇親会での交流について(06:45) エンディング・お便り募集📢 イベント参加・お便りをお待ちしています!イベント当日に東京にいらっしゃる方は、ぜひリアルでお会いしましょう!X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠⁠こちらからお気軽にどうぞ。⁠フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
「テストってバグを見つけるためにやってるんですよね?」もしあなたがそう聞かれたら、どう答えますか?実は、テストの目的はバグ探しだけではありません。今回は、世界的なテスト技術者資格「JSTQB」のシラバスを参考に、テストが果たすべき4つの重要な役割について深掘りします。ソフトウェアの品質を支える「テスト」の真の意味を知ることで、明日からの開発や評価の視点が変わるはずです。📌 今回のエピソードのポイントバグを見つけるだけじゃない? テストが持つ「多角的な目的」とはJSTQBシラバスの変遷:2011年版と最新版で何が変わったのか「意思決定」の材料としてのテスト:ステークホルダーを納得させるための情報提示「欠陥の作り込み防止」という予防的視点:開発プロセス全体をどう改善するか参考ページJSTQBシラバスChapters(00:00) オープニング(01:33) そもそも、なぜテストを行うのか?(よくある意見)(02:34) JSTQB(2011年版)に記載されたテストの4つの目的(07:02) 最新のJSTQBシラバス(2023年版)での定義の変化(08:53) まとめ(09:22) エンディング・お知らせ📢 リスナーの皆様へB-Testing.fmでは、皆様からの感想や質問を募集しています!X(旧Twitter):ハッシュタグ #b_testing でポストをお願いします。お便りフォーム:こちらからお気軽にどうぞ。フォローのお願い:Podcastアプリでフォローしていただくと、最新回の通知をすぐに受け取れます。
「品質を上げろ!」とよく言われますが、そもそも「品質」の正体とは何でしょうか?実は、私たちが普段使っているこの言葉には、時代や文脈によってさまざまな定義があります。書籍『現代品質管理総論』や『ワインバーグのシステム思考法』などを引用しながら、ソフトウェア開発における「品質」の真の意味を解き明かします。「品質=バグがないこと」だけではない、多角的な視点を持つことで、あなたのチームの品質への取り組み方が変わるかもしれません。📌 今回のエピソードのポイント「品質」の語源を知る:「品(しな)」ではなく「品(ひん)」が良いとは?JIS規格による定義:対象に備わっている特性が、要求事項をどれだけ満たしているか速報性 vs 正確性:オリンピックの金メダル速報を例に、時代で変わるニーズを考える「誰かにとっての価値」という視点:フェラーリの排気音は騒音か、それとも価値か?チームで語り合う大切さ:代表者(CEO)も含めて「品質」を議論した実体験参考ページ書籍 『現代品質管理総論』( ⁠https://www.asakura.co.jp/detail.php?book_code=27566⁠ )書籍『ワインバーグのシステム思考法』( ⁠https://www.kyoritsu-pub.co.jp/book/b10011607.html⁠ )Chapters(00:00) オープニング(01:11) 「品質」って何だろう?——言葉の定義を掘り下げる(01:42) 書籍『現代品質管理総論』から紐解く語源(02:44) JIS規格における品質の定義:要求事項を満たす程度(03:09) 具体例:オリンピック報道に見る「品質」の変化(05:09) ワインバーグによる定義:「誰かにとっての価値」(05:47) フェラーリを例に考える「価値の多様性」(06:40) 組織ごとに異なる「品質」の重み:コーヒーショップの例(08:15) CEOと品質について議論した実体験(09:05) エンディング・お知らせ📢 感想をお寄せくださいあなたや、あなたの所属する組織にとっての「品質」とは何ですか?ぜひお聞かせください。X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠こちらからお気軽にどうぞ。フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
#1 自己紹介

#1 自己紹介

2026-01-0411:48

ついに始まりました、テストと品質の深淵を探求するポッドキャスト「B-Testing.fm」。記念すべき第1回は、本番組のホストであるブロッコリーの自己紹介回です。なぜ今、ポッドキャストという形で「品質」や「テスト」の考え方を発信するのか。これまで培ってきた豊富なキャリアや専門的な実績を交え、今後の番組の展望についてお話しします。テストの自動化やプロセス改善に悩む方はもちろん、アジャイルな開発組織を目指す全ての方に向けた「品質の学び場」の第一歩を、ぜひお聞きください。📌 今回のエピソードのポイントブロッコリーって何者?:社内ツールの開発からQA、そして「B-Testing」としての独立までの軌跡受賞歴とコミュニティ活動:色々な社外活動をしていますなぜ「言語化」にこだわるのか:イベント登壇だけでは伝えきれない、深い考えをPodcastに込める理由今後の配信予定:毎週10分、テストや品質の「リアル」を届けるための目標📕参考ページ⁠WACATE⁠⁠JaSST⁠⁠Developers Summit⁠🕒 チャプター(00:00) オープニング:2026年、新番組「B-Testing.fm」スタート!(00:58) ブロッコリーのプロフィール:開発エンジニアからQA・品質保証の世界へ(02:02) 本業と副業:QAチームの立ち上げやコンサル実績について(02:26) 具体的な実績:様々な会社・団体での活動(04:22) 専門的な資格:日本唯一の「Holistic Testing」公式トレーナー(05:24) 受賞歴の紹介:Developers Summitでの評価と、発信への想い(06:15) 社外コミュニティ活動:WACATEやJaSST Review、そして「SReEE」のリーダー(08:38) 執筆実績:Agile TestingやBDD(振る舞い駆動開発)に関する翻訳書籍(08:55) これからの番組展望:日本中、世界中のテストに興味がある方へ届けたい(10:10) エンディング📢 感想をお寄せくださいこれから取り上げてほしいテーマや、ブロッコリーへの質問をお待ちしています!X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。お便りフォーム:⁠こちらからお気軽にどうぞ。番組フォローのお願い:次回から本格的な「テスト・品質論」が始まります。Podcastアプリでのフォローをぜひお願いします!
Comments 
loading