B-Testing.fm

「ソフトウェアテストの勉強をしたいけれど、座学だけでは物足りない」「社外のエンジニアと深く交流したい」――そんな悩みを持つ若手エンジニアにぴったりのイベントを紹介します。

今回は、20年近い歴史を持つ合宿型ワークショップ「WACATE（ワカテ）」を特集。実行委員長を務める視点から、イベントの魅力やユニークなコンセプト、さらには次回開催（2026年夏）の詳細までたっぷりとお届けします。

Spotifyでご視聴の方は、会場の様子や参加者データなどのスライドを映像付きでご覧いただけます。

📌 今回のエピソードのポイント

• 「手を動かす」がメイン： 登壇者の話を聞くだけでなく、グループワークで徹底的に考え抜くスタイル
• 夏と冬で異なるテーマ： 「狭く深く」掘り下げる夏と、「広く浅く」発見を得る冬
• データで見るWACATE： 初参加者が約半数！全国から多様な業種のエンジニアが集まる理由
• 破格の参加費： 宿泊・4食付きで3万円前後という、コミュニティ運営ならではのコストパフォーマンス
• 次回予告： 2026年6月27日(土)・28日(日) 幕張で開催決定！

📕参考文献

• WACATE公式サイト
• WACATE 2026 夏 〜テスト千本ノック！〜 開催概要ページ
• #14 「失敗の許容度を設計に組み込む」：AI時代のテスト設計と品質の考え方（B-Testing.fmの過去回）

🕒 チャプター

• (00:00) オープニング
• (01:50) 合宿型ワークショップ「WACATE」を開催します！
• (05:06) WACATEというコミュニティの概要と「はじまり」
• (08:20) コンセプトと夏・冬のスタイルの違い
• (09:47) データ公開：参加者の属性やリピート率、居住地域
• (12:52) 怒涛の2日間スケジュールと、宿泊型ならではの交流
• (13:27) 次回（WACATE 2026 夏）の開催概要と参加費について
• (17:34) 感想コーナー：第14回「失敗の許容度」への反響
• (18:43) エンディング

📢 あなたのご意見をお聞かせください

今回の放送を聞いて、WACATEに興味を持っていただけましたか？「合宿形式の勉強会に参加したことがないから不安」「こんなテーマを扱ってほしい」など、あなたの本音をお待ちしています！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

前回の「境界値分析（BVA）」の基本に続き、今回は一歩踏み込んで「数値ではないデータ」や「自然言語（日本語）」にこの技法をどう適用するかを深掘りします。

「〜まで」「〜から」といった日常的な言葉に潜む曖昧さが、いかにして不具合の種になるのか。テスト技法を単なる「確認作業」としてではなく、仕様の不備を見つける「議論のツール」として活用するための考え方をお届けします。

📌 今回のエピソードのポイント

• 数値でなくても「順序付け」ができれば境界値分析は活用できる
• 「8:00から22:00まで」の「22:00ちょうど」は稼働時間か、休止時間か？
• 同じ「新横浜駅まで」でも、文脈によって意味が変わる日本語の怖さと面白さ
• テスト設計技法を使って、開発の早い段階で仕様の曖昧さを指摘するメリット
• 【質問コーナー】開発者がテストを行う際に、絶対に落としてはいけない「テストの意図」

📕 参考文献

• ⁠ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03⁠

🕒 チャプター

• (00:00) オープニング

• (01:30) 境界値分析（BVA）の定義を再確認する

• (02:12) 自然言語（数値以外）への適用例：背の順で並ぶクラス

• (03:11) 「以上・以下」「から・まで」に潜む境界の曖昧さ

• (03:54) 東海道新幹線の例で考える、文脈による境界値の変化

• (06:16) テスト技法を「仕様の曖昧さを指摘する」ために使う

• (08:05) 質問コーナー：開発者がテストの一部を担う際に気をつけること

• (10:11) エンディング

📢 あなたのご意見をお聞かせください

皆さんは、仕様書の「〜まで」という表現に悩まされた経験はありませんか？あるいは、数値以外の項目にテスト技法を当てはめてみた事例などがあれば、ぜひ教えてください。

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、テスト設計の基本中の基本でありながら、実は奥が深い「境界値分析（BVA）」を深掘りします。

なぜ「パスワードの文字数チェック」のような単純な仕様でも、テストケースが膨大になってしまうのか、そしてどうすれば効率的に、かつ確実にバグを見つけられるのかを解説します。

「不等号ひとつ」のミスが命取りになる開発現場で、明日から使える実践的な思考プロセスをお届けします。

📌 今回のエピソードのポイント

• なぜ「全数テストは不可能」なのか？テストの7原則から考える
• 境界値分析を正しく行うための4つの実践ステップ
• コードカバレッジが100%でもバグを見逃してしまう落とし穴
• 仕様書には書かれていない「システム上の境界」と「精度の問題」
• 開発者とQAエンジニア、それぞれのテストの使い分けと理想的な関係性

📕 参考文献

• ISTQBテスト技術者資格制度Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03

🕒 チャプター

• (00:00) オープニング
• (01:44) 境界値分析とは何か？
• (04:22) 境界値分析の具体的な実践ステップ
• (06:14) なぜ境界値をテストする必要があるのか：不等号のミスを防ぐ
• (07:44) カバレッジ100%の罠：テスト設計の重要性
• (09:56) システム上の境界値と「有効桁数」の落とし穴
• (13:17) 質問コーナー：エンジニアとQAのテストの使い分け
• (15:09) エンディング

📢 あなたのご意見をお聞かせください

皆さんの現場では、境界値のテストはどこまで厳密に行っていますか？「カバレッジは取れているのにバグが出た」という苦い経験や、開発者とQAの役割分担について思うことなど、ぜひ教えてください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のエピソードでは、5月に予定されている3つの大きな登壇イベントについて詳しくご紹介します。

10Xでの実践を通じた「QA＝テスト」という呪縛を解くためのアプローチや、マイクロサービスにおけるQAの進め方についての質問にもお答えします。

📌 今回のエピソードのポイント

• 【Scrum Fest Niigata 2026】V字モデルの右側にしわ寄せがいかないチーム作り
• 【GENDA Tech Talk #04】少数精鋭のQA組織はどう戦うべきか？
• 【Flexy meetup】10x流「シフトレフト」な品質保証を1時間みっちり深掘り
• リスナー質問：複数のマイクロサービスが連動する変更、QAはどう進める？

📕参考文献

• ピタゴラスイッチ
• テキシコー
• Scrum Fest Niigata 2026
• GENDA Tech Talk #4「少数精鋭QAのリアル：プロダクトが増え続ける組織で、QAはどう戦うか」
• Flexy meetup「10X流・QAと開発者がシームレスに連携するシフトレフトな品質保証アプローチとは」

🕒 チャプター

• (00:00) オープニング
• (01:59) 登壇告知その1：Scrum Fest Niigata 2026
• (05:30) 登壇告知その2：GENDA Tech Talk #04
• (07:30) 登壇告知その3：Flexy meetup
• (09:24) 質問コーナー：マイクロサービス連動時のQA戦略
• (13:25) エンディング

📢 あなたのご意見をお聞かせください

「テストが最後に詰まってリリースが遅れる……」そんな「右側のしわ寄せ」に悩んだ経験はありませんか？今回の登壇内容への期待や、あなたのチームでのQAの悩みなど、ぜひ教えてください！

• X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。

• お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

• フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

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

日々の開発に欠かせない「レビュー」ですが、実は「なんとなく」で行われてしまいがちな活動でもあります。今回は、レビューを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アプリでのフォローをぜひお願いします！

今回は、テスト設計技法の代表格である「同値分割法」をテーマにお届けします。

「なんとなく」でテスト値を選んでいませんか？「なぜその値を選んだのか」を論理的に説明できることは、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アプリでのフォローをぜひお願いします！

今回は「テスト設計とテスト設計技法」の基本について深掘りします。「なぜわざわざ設計が必要なのか？」という根本的な問いから、技法を習得することで得られる意外なメリット、そして数ある技法の効果的な学習順序まで、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アプリでのフォローをぜひお願いします！

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

「テストを実行する」という言葉の裏側には、実は多くの思考プロセスが隠れています。今回は、多くの方が無意識に通り過ぎてしまいがちな「テスト分析」や「テスト設計」の重要性について、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アプリでのフォローをぜひお願いします！