B-Testing.fm

ブロッコリー
  • 0,0 (0)
  • TECHNOLOGIES
  • CHAQUE SEMAINE

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

  1. -1 J

    #24 AIコーディング時代のQA：加速する開発の裏で「理解の負債」にどう立ち向かうか？

    AIコーディングツールの普及により、コードを生成するスピードは飛躍的に向上しました。しかし、その一方で私たちは「何か」を失いつつあるのかもしれません。 今回は、JetBrains社のQA責任者が提唱した「AI時代のQA」に関する考察を紐解きます。コードを書くコストが下がる代わりに増大する「理解の負債」や「意図の負債」、そして変化するバグ修正のコスト曲線など、AIと共に歩むこれからの品質保証活動について、理論と実感の両面から掘り下げていきます。 📌 今回のエピソードのポイント AIコーディングツールがもたらす「理解の負債」と「意図の負債」とは？コード量ではなく「1行あたりの理解度」が減るという質的な変化修正コストの要因が「手戻りの量」から「理解のギャップ」へシフトするプロアクティブ（予防型）なQAがAI時代にますます重要になる理由人間とAIツールの「調整コスト」をどう抑えるか 📕参考文献 QA in the Age of AI-Accelerated Development翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」#9 テストを早めに行うことの大切さ（B-Testing.fmの過去エピソード）#22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説 🕒 チャプター (00:00) オープニング(01:31) 翻訳記事の紹介(03:11) コードを書くコストと引き換えに失われる2つの知見(06:34) 「コードが増えた」のではなく「理解が減った」という質的変化(07:33) 修正コスト曲線の変化：理解の負債がコストを押し上げる(11:42) 積極的（プロアクティブ）な品質保証と反応的な品質管理(14:03) コスト関数で考える「人間とAI」の調整コスト(18:55) 感想コーナー：第22回「同値分割法」へのフィードバック(20:25) エンディング 📢 あなたのご意見をお聞かせください 開発現場でAIコーディングツールを使っていますか？AIが書いたコードの「意図」を読み解くのに苦労した経験や、AI時代のテスト・品質保証について感じていることをぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    22 min

  2. -5 J

    #23 ソフトウェアレビューも「プロセス」で考えよう：属人化の解消とAI活用のコツ

    日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューをJSTQBの定義する「静的テスト」として捉え直し、あえてプロセスに分解することで見えてくるメリットについて深掘りしました。属人化を防ぐための「レビュー・アーキテクチャ」の考え方や、AIに精度の高いレビューをさせるためのプロンプトのヒントなど、現場で役立つ視点をお届けします。 📌 今回のエピソードのポイント レビューは立派な「テスト（静的テスト）」であるという認識JSTQBのレビュープロセスにおける「個々人のレビュー」をどう言語化するかテストプロセス（分析・設計・実装・実行）をレビューに応用するメリットレビューの「目的」と「観点」を分けることで属人化を防ぐAIにレビューを依頼する際、丸投げよりも「観点」指定が重要な理由 📕 参考文献 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02レビューでは何を確認するといいのかな？さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！(JaSST Review'22発表資料) 🕒 チャプター (00:00) オープニング(01:31) ソフトウェアレビューにおけるプロセスの重要性(02:01) レビューは「静的テスト」の1つである(03:22) JSTQBのレビュープロセスと残る疑問(04:39) テストプロセスを参考にレビューを分解してみる(06:15) レビューアプローチの全体像と属人化の課題(10:52) AIのレビュー精度を飛躍的に高めるヒント(12:51) 質問コーナー：ステークホルダー間での形式化はできている？(14:02) エンディング 📢 あなたのご意見をお聞かせください みなさんの現場では、レビューの「観点」や「手順」は明文化されていますか？それとも「経験豊富なベテランの勘」に頼っている部分が大きいでしょうか？レビューにおける工夫や悩みなど、ぜひ教えてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    15 min

  3. 12 AVR.

    #22 都道府県、いくつテストする？テスト設計の基本「同値分割法」を徹底解説

    今回は、テスト設計技法の代表格である「同値分割法」をテーマにお届けします。 「なんとなく」でテスト値を選んでいませんか？「なぜその値を選んだのか」を論理的に説明できることは、QAエンジニアにとって非常に重要なスキルです。47都道府県のプルダウンを例に、目的やリスクに応じた5つのアプローチを紹介しながら、現場で役立つ思考プロセスを整理していきます。 📌 今回のエピソードのポイント 同値分割法の定義とメリット都道府県のテストで「沖縄県」や「神奈川県」を選ぶそれぞれの理由テストケース作成時に欠かせない「理由を言語化する」ことの大切さ5つの回答例（スクロール、印刷反映、文字数、地域、コードの構造）リスナーからの感想紹介：QAとAIが共創する「建設的相互作用」の可能性 📕 参考文献 #14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回） 🕒 チャプター (00:00) オープニング(01:24) 同値分割法とは何か？(02:45) 例題：都道府県の項目、何個テストする？(03:25) 同値分割の手順と「理由」の重要性(04:30) 5つの回答例：スクロールや配列エラー、出力結果、文字数、地域、全件テストの使い分け(10:20) 感想ポスト紹介：QAとAIのシナジーと仮説検証(12:26) エンディング 📢 あなたのご意見をお聞かせください 皆さんは「都道府県」の項目をテストするとき、いつもどのような狙いで値を選んでいますか？「自分ならこう分ける！」というこだわりや、今回紹介した手法への感想など、ぜひお聞かせください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    14 min

  4. 5 AVR.

    #21 テスト設計技法は「楽をするため」にある？省思考でクリエイティブな仕事に向き合う方法

    今回は「テスト設計とテスト設計技法」の基本について深掘りします。「なぜわざわざ設計が必要なのか？」という根本的な問いから、技法を習得することで得られる意外なメリット、そして数ある技法の効果的な学習順序まで、QAの現場で役立つエッセンスを凝縮してお届けします。 📌 今回のエピソードのポイント 「全数テストは不可能」だからこその設計： 時間制約の中で、効果的・効率的に不具合を見つけるための戦略。「効果」と「効率」の違いを意識する： 多くのバグを出すことと、かけた時間に対してバグを出すことのバランス。技法による「省思考（しょうしこう）」のススメ： 信号機の色の順番を考えなくていいように、標準化によって脳のメモリを解放し、より独創的な仕事へ集中する。技法の学習ロードマップ： 同値分割・境界値分析といった「基本」から始めるべき理由。質問コーナー： 開発経験はQAに必須？テスト観点を養い、技法を使い分けるための「数学の公式」のような考え方。 📕 参考文献 Newbeeさんの動画「AI時代の品質保証最前線　決定論→確率論時代に変わるQAの在り方」スライド「テスト設計技法をチョット俯瞰してみよう」書籍『現代品質管理総論』書籍『ソフトウェアテスト技法練習帳～知識を経験に変える40問⁠～』 🕒 チャプター (00:00) オープニング(01:53) 今回のテーマ：テスト設計とテスト設計技法(02:04) テスト設計はなぜ必要なのか？(03:08) テストにおける「効果」と「効率」の定義(04:41) 技法を用いることで「省思考」を実現する(07:42) テスト設計技法を学ぶべき順番(09:40) 質問コーナー：技法を使い分けられるようになるまでの道のり(13:47) エンディング 📢 あなたのご意見をお聞かせください 皆さんがテスト設計技法を学んでいて「これは目から鱗だった！」というエピソードや、逆に「使い分けが難しい……」と感じている部分はありますか？ぜひ教えてください。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    15 min

  5. 1 AVR.

    #20 まだテストエンジニアの価値を知らないチームに入り込むための方法

    「QAエンジニアって本当に必要？」「開発者がテストすればいいんじゃない？」そんな声が聞こえてきそうな現場に、最初のQAとして飛び込むのは勇気がいるものです。今回は、テストの価値がまだ浸透していないチームにおいて、どのように信頼を勝ち取り、スムーズにテストプロセスを導入していくべきか、具体的な戦略とコミュニケーションのコツを深掘りします。 📌 今回のエピソードのポイント 不具合分析から始めるプロセス導入：いきなり理想を語るのではなく、目の前の痛み（障害）を入り口にする戦略「なぜやらなかったの？」は禁句：相手を責める「評論家」ではなく、共に悩む「当事者」として振る舞うヒアリング術主語を「私」にする意思表明：テスト設計ができないことへの「困りごと」を伝えることで、周囲の協力を引き出すボトムアップ改善の鉄則：大規模組織で提案を通すなら、まずは「勝手にやって実績を作る」のが近道？ 📕 参考文献 書籍『FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48のパターン』 🕒 チャプター (00:00) オープニング(01:37) テストエンジニアの価値をチームに伝えるには(02:39) テストプロセス導入の第一歩は「不具合・障害分析」から(04:17) チームに受け入れられるコミュニケーションのコツ(09:00) 質問コーナー：大規模組織でのボトムアップな改善提案(10:26) 参考文献『Fearless Change』に見る改善のパターン(12:26) エンディング 📢 あなたのご意見をお聞かせください 新しくチームに加わった時や、新しいプロセスを導入しようとした時、あなたが意識している「入り込み方」の工夫はありますか？ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    14 min

  6. 29 MARS

    #19 テストでの「思考」もプロセスで表現してみよう

    「テストを実行する」という言葉の裏側には、実は多くの思考プロセスが隠れています。今回は、多くの方が無意識に通り過ぎてしまいがちな「テスト分析」や「テスト設計」の重要性について、JSTQBの定義を交えながら掘り下げます。 📌 今回のエピソードのポイント 「テスト準備」を一括りにせず、プロセスを細分化するメリットJSTQBが定義する「テスト分析」「テスト設計」「テスト実装」「テスト実行」の違い無意識に行っている「何を・どうテストするか」を言語化・議論する大切さ【質問コーナー】QAからユニットテストを提案する際の「前提」とチーム文化 📕参考文献 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 🕒 チャプター (00:00) オープニング(01:58) よくあるテストプロセスとJSTQBの定義(02:50) テストプロセスを4つに分けて考える(05:35) 「テスト分析」で何をテストするかを決定する(08:31) 質問コーナー：ユニットテストの提案は受け入れられる？(10:13) 開発チーム全体で品質に向き合うマインドセット(12:00) エンディング 📢 あなたのご意見をお聞かせください 皆さんの現場では、テストコードを書く前に「何をテストするか」を議論する時間はありますか？それとも、無意識のうちにスクリプト作成から始めてしまっているでしょうか。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

    14 min

  7. 22 MARS

    #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 min

  8. 18 MARS

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

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

    17 min
Tout afficher (24)

À propos

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

Informations

  • Création
    ブロッコリー
  • Années d’activité
    2 k
  • Épisodes
    24
  • Classification
    Tous publics
  • Copyright
    © ブロッコリー
  • Site web de l’émission
    B-Testing.fm

Vous aimeriez peut‑être aussi