B-Testing.fm

AIコーディングツールの普及によって開発の現場はどう変わったのか？今回は、AIツールの進化と生産性・リリースへの影響を多角的に分析した海外論文『Writing Code vs. Shipping Code』をご紹介します。コード生成量が劇的に増える一方で最終的なリリース量にはどのようなギャップが生じているのか、またアプリストアで起きている「供給過多と使われないアプリの増加」というリアルな現実について、数値データを交えて詳しく解説します。

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

• AIコーディングツールの3つの世代分類： オートコンプリート型、対話型エージェント、自律型エージェントというAI開発ツールの進化過程とその特徴を整理します。
• コード生成量とリリースの大きなギャップ： AI導入で変更行数が約8.5倍に急増しても、実際のリリース量は+20%程度にとどまる「コードの減衰傾向」を明かします。
• アプリ供給過多と品質管理の重要性： ストアへのアプリ公開数が急増する一方で購入・利用されないアプリが増加しており、作成後の品質確認や運用がいかに重要かを提示します。

📕 参考文献

• Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools

🕒 チャプター

• (00:00) オープニング
• (01:31) 海外論文『Writing Code vs. Shipping Code』の紹介とAIツールの世代分類
• (05:04) AIによるコード大量生成とリリースまでの「減衰傾向」
• (09:18) アプリ公開数の急増と「使われないアプリ」が増える現実
• (15:49) エンディング

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

今回のエピソードで紹介した海外論文の調査結果を聞いて、ご自身の職場や開発現場での実感と比べていかがでしたでしょうか？「うちのチームでも似た傾向がある」「自分の感覚とは少し違う」など、ぜひ皆さんのご意見やご感想をお聞かせください！

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

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

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

今回のテーマは、状態遷移テストにおける「ラウンドトリップカバレッジ」です。ISTQBシラバスの定義をベースに、ストップウォッチの具体例を用いながらテストケースの導出方法や網羅条件をわかりやすく解説します。さらに、状態間を行き来する不具合の検知やチーム内での認識合わせといったメリットに加え、認知度の低さや生成AI（GeminiやChatGPT）に丸投げした際の精度・ケース欠損の注意点についても深掘りします。

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

• 定義と具体例でのケース導出： ISTQBシラバスに基づく定義と、ストップウォッチの遷移図を用いた7つのテストケース導出プロセスを解説。
• 導入メリットと認識合わせの容易さ： 状態間を行き来する複雑な不具合の検出に強く、図をなぞりながらチームで網羅性を共有できる利点を紹介。
• 認知度の低さと生成AIの限界： 資料が少なくAIに任せるとテストケースが欠損する実態を踏まえ、人間が自ら設計する重要性を考察。

📕 参考文献

• コードを書くことだけが技術力じゃないーー10X風間氏が語る、"品質を設計する"エンジニアの仕事 - アンドエンジニア
• 状態遷移テスト（state transition testing） - ISTQB Glossary
• ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03

🕒 チャプター

• (00:00) オープニング
• (01:38) 状態遷移テストとカバレッジのおさらい
• (02:52) ラウンドトリップカバレッジとは
• (04:12) ストップウォッチ例で見るテストケース導出
• (06:17) ラウンドトリップカバレッジの対象外となるケース
• (07:48) ラウンドトリップカバレッジのメリット
• (08:55) 認知度の低さと生成AI活用の注意点
• (10:30) まとめ・現場での活用に向けて
• (11:05) エンディング

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

皆さんは状態遷移テストでラウンドトリップカバレッジを活用したことがありますか？また、テスト設計で生成AIを使った際の精度や工夫などもぜひお寄せください！

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

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

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

状態遷移テストにおける「Nスイッチカバレッジ」について、具体的な図解やお題を交えながらわかりやすく解説します。0スイッチカバレッジ（遷移カバレッジ）と1スイッチカバレッジ・2スイッチカバレッジの違いや、それぞれのテストケースの考え方、実務でどのような不具合発見に役立つのかについて探っていきます。

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

• Nスイッチカバレッジの定義： スイッチの数（遷移の切り替えポイント）をもとにテストの網羅率を計測する仕組みについて解説します。
• 0・1・2スイッチの違いとテストケース数： 状態遷移の切り替えポイントを考慮することで、テストケース数やカバーできる範囲がどのように変化するのかを整理します。
• 不具合検出と実務での活用： 0スイッチでは見落としがちな状態遷移に伴う欠陥を見つけるために、どのような場面で高いスイッチ数を検討すべきかを伝えます。

📕 参考文献

• 状態遷移テスト（state transition testing） - ISTQB Glossary
• ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03

🕒 チャプター

• (00:00) オープニング
• (01:28) 状態遷移テストとカバレッジのおさらい
• (02:51) Nスイッチカバレッジとは
• (04:09) 0スイッチカバレッジ
• (05:11) 1スイッチカバレッジ
• (07:52) 2スイッチカバレッジ
• (09:40) Nスイッチカバレッジのまとめ
• (10:31) エンディング

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

業務で1スイッチカバレッジや2スイッチカバレッジを活用した経験はありますか？「実は業務で使っている」「今回はじめて概念を知った」など、みなさんのご意見やご感想をぜひお寄せください！

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

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

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

状態遷移テストにおける代表的な網羅基準である「遷移カバレッジ（0スイッチカバレッジ）」について解説します。ストップウォッチの具体例を用いて、状態遷移図からどのようにテストケースを組み立て、カバレッジ100%を目指すのかを分かりやすく紐解きます。状態カバレッジとの違いや、実務で他の人と認識を合わせやすいメリットについても触れています。

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

• 遷移カバレッジ（0スイッチカバレッジ）の基本： すべての状態に滞在し、すべての遷移（矢印）を通ることを保証する網羅基準を解説します。
• ストップウォッチの例題で理解： 状態遷移図をベースに、2つのテストケースで遷移カバレッジ100%を達成するステップを紹介します。
• 状態カバレッジとの違いとメリット： 単に状態を通るだけでなく、遷移まで網羅することでテストの抜け漏れを防ぎ、認識を合わせやすくなる理由を語ります。

📕 参考文献

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

🕒 チャプター

• (00:00) オープニング
• (01:19) 遷移カバレッジとは
• (07:56) エンディング

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

「遷移カバレッジ」という言葉は知らなくても、普段の業務で自然と実践されていた方も多いのではないでしょうか？「うちの現場ではこんなカバレッジ基準を使っている」「実務でこう工夫している」など、みなさんの体験談やご感想をぜひお聞かせください！

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

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

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

今回は、状態遷移テストにおける「状態表の作成」について詳しく解説します。状態遷移図だけでは気づきにくい動作の抜け漏れや、「自己遷移」「非活性（N/A）」を洗い出す状態表の組み立て方から、実際のテストケースへどう落とし込んでいくかまで、ストップウォッチの具体例を用いてわかりやすく紐解きます。

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

• 状態表で遷移の漏れを防ぐ： 状態遷移図をマトリクス形式の状態表に変換することで、図だけでは見落としがちな未定義の動作や潜在的な漏れを効率よく発見できます。
• 「自己遷移」と「非活性（N/A）」の整理： 操作しても状態が変わらない動作（ハイフン表記）と、仕様上起こり得ない動作（N/A表記）を明確に区別して整理するコツを解説します。
• テストケースへの具現化： 状態表をもとにテスト実装段階のテストケースを作成する際、期待結果をより詳細に記述するメリットと注意点をまとめています。

📕 参考文献

• ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 4.2.4 状態遷移テスト

🕒 チャプター

• (00:00) オープニング
• (01:50) 状態表の定義と役割
• (02:51) 例題（ストップウォッチ）と状態遷移図の復習
• (03:34) 状態表の作成プロセス
• (05:43) 空白セルから気づく「自己遷移」と「非活性（N/A）」
• (09:25) 状態表からテストケース例への落とし込み
• (12:01) まとめと次回への展望
• (12:51) エンディング

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

普段のテスト設計で「状態表」を活用していますか？「これまで状態遷移図しか使っていなかったけれど試してみたい」「現場でこう使っている」など、皆様のご意見やエピソードをぜひお聞かせください！

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

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

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

テスト設計技法のひとつである「状態遷移テスト」の基本となる「状態遷移図」の作成方法について解説します。ストップウォッチの動作を例に、状態・イベント・遷移といった構成要素や「開始疑似状態」の役割を紐解きます。さらに、テスト設計で状態遷移図を積極的に活用すべき2つの重要なパターンについても詳しく紹介します。

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

• 状態遷移図の構成要素： 状態、イベント、遷移、そして「開始疑似状態」など、システムの振る舞いをモデル化するための基本用語と役割を整理します。
• ストップウォッチを例にした作成手順： 「待機中」「計測中」「一時停止中」といった状態が、ボタン押下というイベントによってどう変化するかを順を追って図解します。
• 積極的に作成すべき2つのパターン： 「同じイベントでも前状態によって遷移先が変わる場合」と「同じ状態でもイベントによって遷移先が変わる場合」の活用ポイントを解説します。

📕 参考文献

• 状態遷移テスト（state transition testing） - ISTQB Glossary
• ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 4.2.4 状態遷移テスト

🕒 チャプター

• (00:00) オープニング
• (01:40) 状態遷移テスト・状態遷移図とは何か
• (03:24) 例題：ストップウォッチのテスト
• (04:05) 状態遷移図の作成手順
• (07:17) 積極的に作成すべきパターン①（前状態による違い）
• (08:33) 積極的に作成すべきパターン②（イベントによる違い）
• (08:55) まとめと次回予告
• (09:34) エンディング

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

みなさんは普段のテスト設計で「状態遷移図」を活用していますか？「開始疑似状態」の表記など、知っていたことや新しい発見があれば、ぜひご意見やご感想をお寄せください！

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

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

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

今回は、先日開催された2つの大きなテストコミュニティイベント「WACATE 2026 夏」と「JaSST'26 Kansai」の振り返りと舞台裏をお届けします。前半は、実行委員長を務めたWACATE2026夏「テスト千本ノック！」での問題作成のこだわりや、状態遷移テストへの想い、そしてGoogleのUI生成AIツール「Stitch」を活用した画面イメージ作成の裏話を公開。後半は、大阪で開催されたJaSST'26 Kansaiにて、スポンサーセッションとワークショップ合わせて3時間弱に及ぶ怒涛の登壇を果たしたエピソードや、関西におけるコミュニティの認知度について語ります。

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

• WACATE 2026 夏の炊飯器問題： 今回のテーマ「テスト千本ノック！」において、状態遷移テストの魅力を伝えるために組み込み系の「炊飯器」を題材に選んだこだわりを明かします。
• UI生成AI「Stitch」の活用： デザインが苦手な人でも、仕様をインプットするだけでそれっぽい画面イメージを効率的に作成できたGoogleの生成AIツールの活用法を紹介します。
• JaSST関西での怒涛の3時間登壇： スポンサーセッションとワークショップの再演で誰よりも長く登壇した振り返りと、関西での「WACATE」の意外な認知度について語ります。

📕 参考文献

• WACATE 2026 夏 〜テスト千本ノック！
• Stitch - Design with AI
• JaSST'26 Kansai
• JaSST'26 Kansaiの投影資料
• B-Testing.fm #26 意外と奥が結婚深い「境界値分析」〜100%のカバレッジでもバグが出る理由〜

🕒 チャプター

• (00:00) オープニング
• (01:30) WACATE 2026 夏「テスト千本ノック！」の舞台裏とAI活用
• (10:18) JaSST'26 Kansaiでの怒涛の登壇振り返り

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

WACATE 2026 夏やJaSST'26 Kansaiに参加されたみなさまからの感想をお待ちしています！また、普段のテスト設計で生成AIツールを使っている事例や、組み込み系・状態遷移テストでの工夫などもぜひ教えてください。

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

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

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

今回は、前回に引き続き「テストの7原則」の後編をお届けします。ソフトウェアテストの基礎となるISTQB（JSTQB）シラバスに記載されている7つの原則のうち、残りの3つ（テストの弱化、コンテキスト次第、欠陥ゼロの落とし穴）について、具体例を交えながら分かりやすく解説します。さらに質問コーナーでは、現場のリアルな悩みである「テスト待ちの解消」についての体験談とアプローチもシェア。テストに関わるエンジニアはもちろん、開発者やマネージャーの方々にもぜひ知っておいていただきたい内容です！

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

• テストの弱化（殺虫剤のパラドックス）： 同じテストを繰り返しても新しい欠陥は見つからなくなるため、テストも常にアップデートが必要であるというお話。
• テストはコンテキスト次第： 人命に関わる医療システムとスマートフォンゲームとでは、テストにかけるべきコストや求める品質が全く異なるというお話。
• 「欠陥ゼロ」の落とし穴： バグが全くなくても「起動に5時間かかるシステム」は使えないように、欠陥がないことと素晴らしい製品であることは必ずしもイコールではないというお話。

📕 参考文献

• 10X.fm Tech Talk
• ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02

🕒 チャプター

• (00:00) オープニング
• (01:37) テストの7原則（後編）
• (02:21) 5. テストの弱化
• (05:16) 6. テストはコンテキスト次第
• (07:26) 7. 「欠陥ゼロ」の落とし穴
• (10:18) 質問コーナー：テスト待ちを解消したなと思った瞬間はどんな時ですか？
• (12:48) お知らせ・エンディング

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

今回ご紹介した「テストの7原則」の中で、皆さんの日々の業務において一番ハッとさせられた原則はどれでしたか？また、現場でのテストにまつわる「あるある」や「お悩み」などがあれば、ぜひお気軽にお聞かせください！

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

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

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

今回のテーマは、ソフトウェア開発に関わるすべての人に知っておいてほしい「テストの7原則」の前編です。JSTQBシラバスにも記載されているこの原則は、QAやテストエンジニアだけでなく、開発者、マネージャー、経営層など、あらゆるロールの方に役立つ共通のガイドラインとなります。今回は7つのうち、前半の4つの原則について、具体的な例（名前入力欄のテストパターン数など）を交えながら分かりやすく解説します。

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

• バグゼロの証明は不可能： テストによって欠陥を見つけることはできても、「絶対にバグがない」と証明することはできず、全数テストも現実的には不可能です。
• 早期テストの重要性： テストを後回しにせず、いかに早く欠陥に気づけるかが、結果的にプロジェクトの時間とコストの大幅な節約に繋がります。
• 欠陥は偏在する： バグはシステム全体に満遍なく存在するのではなく、特定の箇所や境界値などに局所的に集中して発生する傾向があります。

📕 参考文献

• ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02

🕒 チャプター

• (00:00) オープニング
• (01:38) テストの7原則とは？
• (03:08) 1. テストは欠陥があることは示せるが、欠陥がないことは示せない
• (04:27) 2. 全数テストは不可能
• (06:58) 3. 早期テストで時間とコストを節約
• (07:38) 4. 欠陥の偏在
• (09:37) 質問コーナー：スケジュール上「QA開始」なのに実装が終わっていない時は？
• (12:07) お知らせ・エンディング

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

「テストの7原則」の中で、あなたが特に重要だと感じたポイントはどれですか？また、日々の業務で直面しているテストや品質に関するお悩み、番組へのご質問があれば、ぜひお気軽にお寄せください！

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

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

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

ソフトウェアテストの設計手法の一つである「直交表」について、因子間で水準数が異なる場合の応用的な使い方を深掘りします。よくある2水準の直交表に、3水準の因子をどうやって組み込むのか、身近なコーヒーショップのカスタマイズを例に具体的手順を解説します。また、後半の質問コーナーでは「テストスキルと生成AI（LLM）の相性」について議論します。LLMに直交表の作成を任せた際の具体的な失敗例を交え、AIが苦手とする「交互作用」の概念や、テスト設計における人間の専門性の重要性に迫る必聴のエピソードです。

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

• 水準数が異なる直交表の作り方： 2水準の直交表（L8）を拡張し、3水準の因子を組み込む具体的なテクニックを解説します。
• 直交表の性質とペアワイズ（2因子間網羅）： 拡張した直交表における出現回数の偏りと、それでもペアワイズが満たされる理由について紐解きます。
• テストスキルと生成AIの意外な相性： 生成AIに直交表のテストケース作成を依頼するとどうなるか？AIが「交互作用」を理解できずに失敗するメカニズムを鋭く分析します。

📕 参考文献

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

🕒 チャプター

• (00:00) オープニング
• (01:27) 水準数が異なる直交表の使い方
• (03:00) 説明に使うお題（コーヒーショップのカスタマイズ）
• (04:09) 直交表の拡張と具体的な当てはめ方
• (06:14) 実際に利用する際の注意点（出現回数とペアワイズ）
• (08:20) L9直交表を用いた別のアプローチ
• (09:44) 質問コーナー：QAスキルとLLM活用の相性はよかったりしますか？
• (12:01) なぜLLMは直交表の作成に失敗するのか？（交互作用の理解）
• (15:49) エンディング・お知らせ

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

生成AI（LLM）をソフトウェアテストの設計に使ってみて、期待通りにいかなかった経験はありますか？また、直交表のような高度なテスト技法を実務でどのように工夫して活用しているか、ぜひ皆さんの知見やエピソードをシェアしてください！

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

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

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