私たちはなんでテストするんだっけ? Ver.東北IT物産展2026 in 会津若松

東北IT物産展2026 in 会津若松でJaSST東北実行委員のおおひら ゆうすけが話した内容
Have you lot ever actually stopped to think about why we test in product development?

Transcript

1. 私たちはなんでテストするんだっけ？ 〜あらためてテストの意味を考える〜 Ver.東北IT物産展2026 in 会津若松 JaSST東北実⾏委員 おおひら ゆうすけ 1
2. ⾃⼰紹介 • おおひら ゆうすけ from ⽯川町 • プロダクト開発が好きな ｢ただ（そこにいるだけ）のテスター｣ • BtoB SaaS の QAエンジニア • 運営 • JaSST東北（⾒習い • SRE Next（幽霊部員 • テストの街｢葛飾｣（区⺠ • 好きなスキル: Grill-me • 好きな本:闘うプログラマー • 好きなプロトコル:LDAP 2
4. イントロダクション 6
5. プロダクト開発をAIエージェントに任せる • プロンプト → ハーネス → ループ→ グラフ • AIの出⼒を、環境（テスト‧ドキュメント‧ツール）で制御する • エージェントを⾃律的に回し続ける • 複数エージェントを協調させる ⼈間がコードを読まない‧介⼊しない時代になりつつある 3
6. テストが重要になっている？ • Robert C. Martin（Uncle Bob）のポスト • （@unclebobmartin, 2026/7/23） • "My current strategy is to not read any of the code written by my agents." • AIエージェントが書いたコードは、もう読まない • 代わりに、エージェントを厳格な制約で取り囲む • ユニットテスト、Gherkinテスト、QA⼿順、品質メトリクス、ミューテ ーションテスト、カバレッジ など • すべての関⾨を通過するからこそ、⽣成されたコードに very high confidence（⾮常に⾼い信頼） を持てる テストが「信頼」を担保する装置になっている？ 4
7. その「テスト」は、何を指しているのか？ • 多くの場合、それは「正しく動いているか」の確認を指している • もちろんそれは⼤事。でも、テストの意味はそれだけ？ あらためて テスト活動の意味を考えませんか 5
8. 私たちはなんでテストするんだっけ？ 6
9. 本⽇のながれ 1. テストの基本概念 • テストの⽬的∕V&V∕チェッキングとテスティングテストオラクル問題∕ • ホリスティックテスト∕アジャイルテスト4象限∕品質ナラティブ 2. AIエンジニアリングとテスト • 各フレームワークで整理すると⾒えてくる⼿薄なところ 3. ⾃分たちが作るべきものに向きあう • 5つの実践例 • 顧客の声‧チームで合意‧探索的テスト‧オブザーバビリティ‧本番でのテスト 4. まとめ 7
10. テストの基本概念 8
11. テストの⽬的 • テストの⽬的（ISTQB CTFL v4.0 セクション1.1.1）: • 要件、ユーザーストーリー、設計、コードなどの作業成果物を評価する • 故障を引き起こし、⽋陥を発⾒する • テスト対象の必要なカバレッジを確保する • ソフトウェア品質が不⼗分な場合のリスクレベルを下げる • 指定された要件が満たされているかを検証する • テスト対象が契約上、法的、規制上の要件に準拠していることを検証す る • ステークホルダーに情報を提供し、根拠ある判断をしてもらう • テスト対象が完成し、ステークホルダーの期待どおりに動作するかを妥 当性確認する • テスト対象の品質に対する信頼を積み上げる 9
12. V&V • V&V = Verification & Validation • 成果物の正しさを2つの視点で確認する考え⽅ • Verification（検証）: ｢仕様｣通りか • 出⼒が「⼊⼒（仕様‧前⼯程の要求）」通りに正しく作れているか • Validation（妥当性確認）: 「ユーザーの要求」通りか • 出⼒が「もともとのユーザーの要求」に合っているか • Barry Boehm • Verification = Are we building the product right? （正しく作っているか） • Validation = Are we building the right product? （正しいものを作っているか） 出典: B. Boehm (1979) V&Vガイドライン論⽂ / ISTQB CTFL Syllabus v4.0 11
13. チェッキングとテスティング • テスト活動の「性質」を分ける考え⽅ • 「テスト」と⼀⼝に⾔っても、実は性質の違う2つの活動が混ざっている • Michael Bolton が提起（2009）、James Bach と共に精緻化（2013） • チェッキング（checking）: 期待結果が決まっていることを 確認 する • 「Aを⼊れたらBが返る」。合否を機械的に判定できる。⾃動化しやすい • テスティング（testing）: まだ分からないことを 探索 し新しい情報を得る • 「ここに問題はないか？」と問う。⼈の知恵と判断が要る ※この線引きは絶対ではなく、良いチェッキングにも知恵が要るという議論 もある（Dinwiddie, Kaner ほか） 12
14. ホリスティック･テスト • テスト活動は特定のフェーズではなく全フェーズで⾏われる • Janet Gregory & Lisa Crispin 提唱 • 開発ライフサイクルを「無限ループ」として捉える（気づき→計画→理解 →ビルド→デプロイ→リリース→観察→学び） • ホリスティック=「全体観」 • チーム全体‧製品組織‧顧客まで含めて品質を考える。始まりも終わりも ない 出典: Janet Gregory & Lisa Crispin「Holistic Testing Model」Agile Testing Fellowship (© 2023) （https://agiletestingfellow.com） 13
15. ホリスティック･テスト 出典: Janet Gregory & Lisa Crispin「Holistic Testing Model」Agile Testing Fellowship (© 2023) （https://agiletestingfellow.com） 13
16. ループ左側 — 早期にできるテスト • 気づき（Discovery） • アイデアの検証。「この問題は解く価値があるか」を問う • 計画（Planning）: • リスク特定と品質特性の優先順位付け。受け⼊れテストの検討を始める • 理解（Understanding）: • 実例マッピングやプロトタイプなどで、あいまいな要求を具体例に落と す素早いフィードバックを得て、仕様を固める • ビルド（Building） • ユーザーストーリーやフィーチャーを実装し、TDDなどを活⽤して可能 な限り早くテストする • ⾃動テストがリグレッションスイートになっていく 14
17. ループ右側 — バグを⾒つけ、学びにつなげるテスト • デプロイ（Deploying）: • 複数環境に展開し、パフォーマンスやセキュリティなど品質特性を検証 する • リリース（Releasing） • フィーチャートグルやカナリアリリースなどで段階的にユーザーに届 ける • 観察（Observability） • 本番のイベントを記録し、顧客がどう使っているかを観る • エラー監視だけでなく、利⽤パターンの発⾒も含む • 学び（Learning）: • 観察から仮説を⽴て、検証する。学びが次の「気づき」に戻る 15
18. アジャイルテスト4象限 • Brian Marick 原型 でLisa Crispin & Janet Gregory が発展 • 2軸で分類: ビジネス⾯∕技術⾯ × チームを⽀援∕製品を批評 • Q1｜技術 × ⽀援: ユニット / コンポーネントテスト • Q2｜ビジネス × ⽀援: 機能‧ストーリーテスト / 受け⼊れテスト • Q3｜ビジネス × 批評: 探索的テスト / ユーザビリティ / UAT • Q4｜技術 × 批評: 性能 / 負荷 / セキュリティ • 使い⽅: ⾃分たちのテストをマッピングし、各テストの⽬的は何か？偏りや ⼿薄な象限がないかを整理する 16
19. アジャイルテスト4象限 ビジネス⾯ Q2 ビジネス × ⽀援: 機能‧ストーリーテスト / 受け⼊れテスト Q3 ビジネス × 批評 探索的テスト / ユーザビリ ティ / 受け⼊れテスト チームを⽀援 製品を批評 Q1 技術 × ⽀援: ユニット / コンポーネント テスト Q4 技術 × 批評 性能 / 負荷 / セキュリティ 技術⾯ • ※ 各象限のテスト種類はあくまで例 16
20. 品質の語られ⽅：3つの品質ナラティブ • 品質ナラティブ • 企業で品質について考えたり話したりしている、その「語られ⽅」 （Ronald Cummings-John & Owais Peer『LEADING QUALITY』） • 3つのナラティブがある • ① 責任ナラティブ（The Ownership Narrative） • 誰が品質に責任を持つかが語られている • ② テストナラティブ（The "How to Test" Narrative）: • 品質向上につながる 正しいテスト技法‧ツールはどれか が語られて いる • ③ 価値ナラティブ（The Value Narrative） • 品質に投資した場合の ⾒返り（ROI） が語られている • 品質‧テストについて話すとき、それが3つのどのナラティブの話なのかを 意識すると議論がかみ合う 18
21. AIエンジニアリングとテスト 19
22. テストの考え⽅で整理する • AIエンジニアリング（ハーネス‧ループ設計など）で語られる「テスト」 を、各枠組みに当てはめると • 品質ナラティブ • 主に テストナラティブ（どう‧どのツールでテストするか） • V&V • 主に Verification（仕様どおりに作れているか） • チェッキング/テスティング • 主に チェッキング（既知の期待結果との照合） • ホリスティック/4象限 • 主に ビルド段階のQ1（技術×⽀援） が中⼼ • なぜこう偏るのか？ • 正解がある領域はテストが作りやすく⾃動化しやすい 21
23. テストオラクル問題 • テストオラクル • ある⼊⼒に対する 正しい出⼒（期待結果）を教えてくれる情報源 • テストの基本構造は、実際の出⼒を、オラクル（期待結果）と照らし合わせること • テストオラクル問題 • その「正しい出⼒」を判定すること⾃体が難しい、という問題 • オラクルが はっきりある 領域と、あいまいな 領域がある: • はっきりある例: 「⼊⼒Aなら出⼒はB」。仕様書‧期待値‧既存テストで判定できる （Verification寄り） • あいまいな例: 「この機能はユーザーにとって価値があるか」。正解が⼀つに定まらな い（Validation寄り） • ⽣成AIはコードを速く作れるが、「プロダクトとして何が価値か」､｢何を 作るべきか｣は判断しにくい 20
24. ⼿薄なところが⾒えてくる • 傾向として⼿薄になりやすいのは オラクルがあいまいな「何を作るべきか 」の側 • 品質ナラティブで⾔えば → 価値ナラティブ • V&Vで⾔えば → Validation • チェッキング/テスティングで⾔えば → テスティング • ホリスティック/4象限で⾔えば → ループ左側（気づき‧理解）と右側 後半（観察‧学び）、Q3（探索的テスト） ※ あくまで傾向。顧客の利⽤データからAIが価値を分析するなど、あいまい な部分でAIを活⽤する例もある → ⾃チームの状況で考える 22
25. 自分たちが作るべきものに向き合う 23
26. 作るべきものに向き合う • ホリスティックテストやアジャイルテストの4象限で⼿薄な部分を整理する • 顧客理解が浅い→顧客の声を聞く • 気づき‧理解（Q2‧Q3）：何が価値かを顧客から知る • 仕様の共通認識があわない→具体例で合意を作る • 計画‧理解（Q2）：あいまいな仕様を⾔語化する • 想定外が漏れる→探索的テスト • ビルド（Q3）：作ったものから想定外を⾒つける • 仮説を確かめたい→本番でのテスト • 学び（Q3‧Q4）：段階リリースで本番で仮説を確かめる • 顧客の利⽤状況が⾒えない→オブザーバビリティ強化 • 観察（Q4）：本番で実際どう使われているかを観る 24
27. 顧客の声を聞く：何が価値かを顧客から知る • 課題 • 「何を作るべきか」の判断基準が、チームの中だけでは分からない • ⽅法 • ユーザーインタビュー、利⽤観察、フィードバック収集 • 多くの⼈は「テスト」と思っていないが、「正しいものを作っているか 」のオラクルを顧客から⼿に⼊れる活動 • AIはコードを⽣成できるが、「これがユーザーにとって価値があるか」 というオラクルは持っていない。顧客から得るのは⼈の仕事 • 顧客の声を聞く活動を、テスト活動として位置づけ直してみる 25
28. 具体例で合意を作る：あいまいな仕様を⾔語化する • 課題 • 抽象的な要件だけでは、チームの認識がずれる（仕様があいまい） • ⽅法 • Specification by Example（SbE）：具体的な例で仕様を定義すえう • 合意した具体例は、そのまま受け⼊れテストの判定基準になる • 他にも合意を形式仕様（機械が検査できる形）で書き、Alloy Analyzer で検査可能にする（AIが記述を⽀援できる） • 開発前に、PO‧開発者‧テスターで具体例を出し合う場を作る 26
29. 探索的テスト：作ったものから想定外を⾒つける • 課題 • 決めた⼿順で確認するだけでは、想定していない問題は⾒つからない • ⽅法 • 探索的テスト • テスト設計‧実⾏‧学習を同時並⾏で進める。チャーターで「何を‧な ぜ‧どう探索するか」を短く定義 • コード⽣産が速くなるほど、作ったものから学ぶ活動の価値が増す。 • AIにチャーターの壁打ちを頼めば、テストの発想や切り⼝も広がる • チェッキングでは⾒つかりにくい問題を発⾒する 27
30. 本番でのテスト：段階的にリリース • 課題 • 早期に仮説を確かめたいが､リリースの影響が⼤きい • ⽅法 • 本番でのテスト（Testing in Production） • カナリアリリース（⼀部ユーザーに先⾏）∕フィーチャートグル（公開 タイミングを切り替え） • 実際のユーザーに対して、本番で仮説を確かめる（Katrina Clokie『A Practical Guide to Testing in DevOps』） • 段階的にリリースして、リスクを抑えながら本番で学ぶ: • 重要な機能を、⼀部ユーザーへの段階リリースで出してみる 29
31. オブザーバビリティの強化：どう使われているか • 課題 • 「作って終わり」だと、本番で意図どおり価値が届いているか分からな い • ⽅法 • プロダクトの利⽤状況を本番で計測し、観察する • 顧客がどの機能をどう使っているか。使われていない機能はないか。想 定と違う使い⽅はないか • V&Vの軸で⾒れば、これは Validation（要求に合っているか）を本番の 事実で問う活動 • 顧客の利⽤データからAIを活⽤が価値を分析することもできる • 「使われ⽅」を観る計測を1つ⼊れてみる 28
32. まとめ 31
33. テストを⾃分たちで問い直す • いろいろなテストの考え⽅ • V&V∕チェッキング‧テスティング∕ホリスティック∕4象限∕品質ナラティブ∕オラ クル問題 • これらは⾃分たちのテストを⾒つめ直すレンズ • 4象限の中⾝も、⼿薄になりやすい側も、あくまで例‧あくまで傾向。当てはまるかは ⾃分たち次第 • レンズを当てて問い直すと、⾃分たちの⼿薄なところが⾒えてくる • チーム､状況によって違う 「私たちはなんでテストするんだっけ？」を、⾃分たちの⽂脈で問い直すこと が出発点 32
34. AIとテストオラクル問題 • ⽣成AIは、私たちのテストに2つの変化をもたらす • ① チェッキングから解放してくれる • ハーネスエンジニアリング等で、チェッキング（答え合わせ）が開 発プロセスに組み込みやすくなった • コード⽣産はAIが⾃律的に動き、⼈が監視する形（human on the loop）へ → Verificationは加速する • ② テスティングの幅を広げてくれる • Vibe Codingのツールで、テストの試⾏が速くなる • AIが壁打ち相⼿になり、テストの発想‧切り⼝を広げてくれる • テストオラクル問題 • AIはオラクルがはっきりしているのが得意 • オラクルがはっきりしていないところは⼈の⼒がまだ必要 33
35. ⾃分たちが作るものに向き合う • ｢プロダクトとして何が価値か」､｢何を作るべきか｣ • 正解がないチェッキングが難しい部分はテスティングで確かめる • 「何を作るべきか」､｢何が価値か｣をテストする 34
36. 私たちはなんでテストするんだっけ？ ぜひ､この問いを⾃分たちのチームで考えてみてください｡ 35
37. JaSST東北のご紹介 • JaSST（Japan Symposium on Software Testing） • NPO法⼈ASTER主催 • JaSST東北: 「東北地⽅で働くエンジニアの“明⽇のテストを楽にする”」 • JaSST'27 Tohoku 2027年5⽉28⽇開催予定 • X: @JaSST_Tohoku 36
38. JaSST東北のご紹介 ソフトウェアテスト技法練習帳 〜知識を経験に変える40問〜 36
39. ご静聴ありがとうございました 35
40. 参考資料 (1/4) • 川⼝恭伸「アジャイルリーダー視点で考える、我々はなぜ、テストをする のか？」Scrum Fest Niigata 2022 / YouTube: https://www.youtube.com/watch?v=07QRjD6q1IE • Michael Bolton「Testing vs. Checking」DevelopSense（2009）（James Bachと共同で発展）: https://developsense.com/blog/2009/08/testingvs-checking • Janet Gregory & Lisa Crispin「Holistic Testing」Scrum Guide Expansion Pack: https://scrumexpansion.org/holistic-testing/ • Dan Ashby「We test here and here and here」 • Brian Marick「Agile Testing Quadrants」 • Lisa Crispin & Janet Gregory『Agile Testing Condensed』 • Ronald Cummings-John & Owais Peer『LEADING QUALITY』 • Gojko Adzic『Specification by Example』(2011) 37
41. 参考資料 (2/4) • ISTQB CTFL Syllabus v4.0.1 (2024): https://astqb.org/assets/documents/ISTQB_CTFL_Syllabus_v4.0.1.pdf • JSTQB Foundation Level シラバス v4.0 ⽇本語版: https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf • Cem Kaner「Exploratory Testing」(2006) / Kaner.com: https://kaner.com/?p=30 • Andrej Karpathy「Vibe Coding」(2025) • Elaine Weyuker「On Testing Non-Testable Programs」(1982) • James Bach「Exploratory Testing Explained」(2003) • Jon Bach & James Bach「Session-Based Test Management」(2000) Software Testing & Quality Engineering Magazine：SBTM の原典 38
42. 参考資料 (3/4) • t_wada「Agentic Software Engineering」（2026/7）Speaker Deck: https://speakerdeck.com/twada/agentic-software-engineering-2026-07findy-edition • Mitchell Hashimoto「Harness Engineering」（2026/2） • Addy Osmani「Loop Engineering」（2026/6） • Peter Steinberger「Graph Engineering」（2026/7） • r.kagaya「ループエンジニアリングの本質」Zenn: https://zenn.dev/r_kaga/articles/a27a3879dd3ce4 • Dan North「We need to talk about testing」(2021): https://dannorth.net/blog/we-need-to-talk-about-testing/ • Dan North「BDD is not about Testing」BDDx 2016 slides: https://speakerdeck.com/tastapod/bdd-is-not-about-testing 38
43. 参考資料 (4/4) • おおひら「Cursorと始める形式⼿法（Alloy）」Loglass Tech Blog: https://zenn.dev/loglass/articles/5e24364ef06aa9 • George Dinwiddie「Three Amigos」（2009） • Katrina Clokie『A Practical Guide to Testing in DevOps』(2017) • ソフトウェアテストが持つ「透明性」の側⾯ https://zenn.dev/55_ymzn/articles/software_testing_transparency 38