B-Testing.fm

今回は、QAエンジニア同士で熱い議論を交わす勉強会「語る夕べ」シリーズについてご紹介します。「テスト設計を語る夕べ」や「ドメインテストを語る夕べ」など、過去に開催されたイベントの様子や、参加者のリアルな声を通して、その魅力をたっぷりとお届けします。📌 今回のエピソードのポイント 「語る夕べ」シリーズのコンセプト： 登壇者だけでなく、参加者全員で深く議論し合う場を提供しています。 過去の開催テーマ： テスト設計、ドメインテストなど、多岐にわたるテーマで開催されてきました。 今後の開催予定： 次回はユースケーステストをテーマに開催予定です。ぜひご期待ください！📕 参考文献 ドメインテストを語る夕べ 2026年版 ドメイン分析をアップデートする ドメインテストにおけるONポイントとOFFポイントについて考える🕒 チャプター (00:00) オープニング (01:26) 「テスト設計を語る夕べ」シリーズについて (05:07) コロナ禍前から続く「語る夕べ」の歴史 (06:08) コロナ禍再開後の「語る夕べ」 (08:24) 次回開催「ユースケーステストを語る夕べ」について (09:20) オフライン開催へのこだわり (10:07) エンディング📢 あなたのご意見をお聞かせください「語る夕べ」シリーズで取り上げてほしいテーマや、これまでの開催で印象に残っていることなど、ぜひご意見をお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回は、これまでのテスト設計の話題から少し離れ、「自動テスト」をテーマにお話しします。自動テストと聞くと、「テスト実行の工数削減」が真っ先に思い浮かぶかもしれませんが、実は得られる恩恵はそれだけではありません。「そもそもなぜ自動テストを書くのか？」という根本的な疑問について、ロボット掃除機や食洗機、サーカスの綱渡りといった身近な例えを交えながら、4つの視点でメリットを深掘りして解説しています。自動テストに興味がある方、これから導入を考えている方はぜひお聴きください！📌 今回のエピソードのポイント テスト実行に必要な準備の明確化： ロボット掃除機を買うと床を片付けるようになるのと同様に、自動テストの導入はテストしやすい設計や環境作りを促進します。 安心してコードを変更できるセーフティネット： サーカスの落下防止網があるから大技に挑めるように、自動テストがあるからこそ安全にリファクタリングや仕様変更が行えます。 生きたドキュメントとしての機能： 自動テストは、常に仕様書と実装の乖離を防ぐ「動く説明書」としての役割を果たします。 工数削減とその注意点： テスト実行工数は削減できますが、テストを準備する工数やメンテナンスコストへの意識も重要です。📕 参考文献 テスト自動化のルンバ効果 開発者が適切なテストを行うために🕒 チャプター (00:00) オープニング (01:46) なぜ自動テストを書くのか？ (03:03) メリット1：テスト実行に必要な準備が明確化される (06:36) メリット2：安心して既存コードを変更できる (07:54) メリット3：実装内容の説明書代わりになる (09:13) メリット4：テスト実行の工数が削減できる (11:34) エンディング📢 あなたのご意見をお聞かせください自動テストの導入でつまずいたことや、逆に「導入してよかった！」と感じたエピソードはありますか？ぜひ皆さんの自動テストに関する体験談を教えてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：こちらからお気軽にどうぞ。 フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回のエピソードでは、探索的テストに関する名著の日本語訳版『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』についてご紹介します！「探索的テスト＝仕様書がない時の場当たり的なテスト」というよくある誤解を解きほぐし、具体的なヒューリスティクスやアプローチ手法を体系的に学べる一冊です。テスト設計技術との高度な融合や、実際の開発プロセスへの組み込み方など、テストを専門とする方だけでなく、開発者やプロダクトマネージャーにも役立つ情報が満載。本書が持つ本当の価値と、現場で実践するためのヒントを語ります。📌 今回のエピソードのポイント 「探索的テスト」への誤解を払拭：思いつきや場当たり的なテストというイメージを覆し、明確な意図を持ったテスト手法であることを解説します。 実践的なアプローチとテスト設計の融合：具体的な探索のヒューリスティクスと、従来の手法を組み合わせてテストを完了に導くプロセスが学べます。 あらゆるプロダクト開発者におすすめ：QA担当者だけでなく、開発者やPdMなど、プロダクト開発に携わるすべての人に読んでほしい理由を語ります。📕 参考文献 Newbee Conference 2026 Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド🕒 チャプター (00:00) オープニング (02:30) 翻訳に携わった書籍『Explore It!』の紹介 (04:00) 探索的テストに対するよくある誤解 (05:45) 実践的なアプローチとテスト設計技術との融合 (07:20) 探索的テストの本当の価値とおすすめの読者層 (09:30) エンディング📢 あなたのご意見をお聞かせください今回紹介した『Explore It!』、皆さんはもうチェックされましたか？探索的テストについて普段現場で感じている疑問や、実際に試してみた感想などがあれば、ぜひ教えてください！また、「こんなテストの悩みを解説してほしい」といったリクエストもお待ちしています。 X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

今回はユースケーステストについての3回目のエピソードとして、ユースケース図やユースケース記述をもとに、どのようにシナリオベースのテストに落とし込んでいくかについて語っています。DVDレンタルの例を用いて、基本フローから代替・例外フローへの寄り道パターンの考え方、そして業務全体の流れを通したテストだからこそ見つかる「リカバリー不全」の不具合など、実践的なポイントを解説しています。実際の業務で活用する際の注意点にも触れていますので、ぜひテスト設計の参考にしてみてください。📌 今回のエピソードのポイント ユースケーステストとシナリオテスト： ユースケースの動作を実行するように設計する「シナリオテスト」との関係性と、その記載形式について整理します。 DVDレンタルを例にしたテスト作成手順： 基本フローから寄り道する代替フロー・例外フローを含めた、具体的なシナリオの書き方を解説します。 業務フロー全体を通したテストのメリット： 画面単体のテストでは見逃されがちな、エラー操作後のリカバリー不全などの不具合を発見できる強みを語ります。📕 参考文献 #17 【水曜日のダウンタウン】ザ・スベリドリームマッチ ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version 3.1.1.J03 ASTERセミナー標準テキスト[Ver3.1.1] 第98回： ユースケーステスト（後編） - Kouichi Akiyama - note🕒 チャプター (00:00) オープニング (02:35) ユースケーステストとは・シナリオテストとの関係 (05:45) ユースケーステストの作り方 (07:07) ユースケーステストの作成手順（実装するフローを考える） (10:46) ユースケーステストを作成するメリット (14:13) まとめ (15:43) 実際の業務で活用する際のポイント (17:28) エンディング・お知らせ📢 あなたのご意見をお聞かせください「ユースケーステストって実際こういう感じなんだ」「実際の業務で使ってみたらうまくいったよ！」といった、実践してみた感想や体験談があればぜひ教えてください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！

ユースケーステストの続編として、今回は「ユースケース記述」の基本から書き方のコツまで詳しく解説します。ユースケース図だけでは表現しきれない詳細なやり取りや例外処理をどのようにテキスト化するのか、DVD貸し出しシステムを例に挙げながら具体的に紐解きます。アクターとシステムの対話を意識した正しい粒度の揃え方や、仕様の曖昧さ・不備を防ぐ記述のメリットを学んでいきましょう！📌 今回のエピソードのポイント 図では見えない詳細の視覚化： ユースケース図のシンプルさでは表現しきれない、会員証の有効期限確認などの具体的な工程や例外フローを明確化できるメリットを解説します。 アクターとシステムの交互の対話： 基本フローを書く際は、アクターの入力とシステムのフィードバックが交互に展開する構造を意識するのが重要なポイントです。 適切なトランザクションの粒度： ボタンを押すレベルの細かすぎる操作ではなく、「会員証情報を入力する」といった分けることのできない一連の情報処理の粒度で書くコツを紹介します。📕 参考文献 『有田脳』シーズン3.5『有田脳人』Ep.5 ゲスト・藤井智久（テレビ朝日「くりぃむナントカ」プロデューサー） ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 第97回： ユースケーステスト（前編） - Kouichi Akiyama - note🕒 チャプター (00:00) オープニング (02:12) ユースケース記述とは (03:09) ユースケース記述の例（DVD貸し出しシステム） (05:52) ポイント：アクターとシステムが交互に登場する (06:23) ユースケース記述を書くメリット (07:44) ユースケース記述を書くコツ（適切な粒度とは） (09:25) まとめ・エンディング📢 あなたのご意見をお聞かせください皆さんの現場では、ユースケース記述をどのように活用していますか？「仕様の抜け漏れを見つけた経験」や「記述の粒度に悩んだこと」など、ぜひご意見やご感想をお寄せください！ X（旧Twitter）：ハッシュタグ #b_testing でのポストをお待ちしています。 お便りフォーム：⁠⁠⁠⁠⁠⁠⁠⁠⁠こちらからお気軽にどうぞ。⁠⁠⁠⁠⁠⁠⁠⁠ フォローのお願い：最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします！