UQAM(Usage-model-driven QA Methodology)の紹介

生成AIが実行主体となり、人間がそのサポートを担うQA体制を構築するための方法論「UQAM; Usage-model-driven QA Methodology」について整理しています。
ユーザ目線の使い方の抽象度で作られた仕様モデルを生成AIの手綱とし、BFBL; Boosted FeedBack Loopで生成AIを乗りこなす、という両輪が特徴です。

また、特にweb系プロダクトにおいてUQAMを実現する際に活用でき得るモデルとして、テストアーキテクチャテーブル・UCOD・AIMを併せて紹介しています。

【2026/06/01追記】
「UQAMのその先」と題して、UQAMをプロダクト開発全体に拡張したモデルを紹介するスライドを公開しました。
https://speakerdeck.com/ukigmo_hiro/uqamnosonoxian

Transcript

1. すずき UQAMの紹介 (Usage-model-driven QA Methodology)
2. 最近のQA組織によくある課題 2 QA活動に ⽣成AIを活⽤しきれていない 気がする…… プロダクト実装の ベロシティが ⽣成AIパワーで向上している QA活動のベロシティも 向上させる必要があるが…… QA活動 = レビュー‧(動的)テスト‧改善施策開発‧etc.
3. QA with ⽣成AIの体制を考える • 実現の⽅針は「主従の逆転」 ▪ プロダクトの実装において ⽣成AIは⼈間のコーディングの補助 → ⽣成AIがコーディングをして⼈間が補助 という主従の逆転現象が起こった ▪ テストも ⽣成AIはQA活動の補助 → ⽣成AIがQA活動をして⼈間が補助 という主従の逆転現象を起こさないと「よくある課題」は解けなさそう ▪ • そんな体制を考える必要がある…… • と思いきや 組み込みソフト開発の分野ですでに提案されている ▪ QualiTrax: ⾃動テストが主‧⼈間は補助的に意思決定などを⾏う⽅法論のひとつ 3
4. 参考: QualiTrax 4 https://www.slideshare.net/slideshow/tomorrows-software-testing-for-embedded-systems-japanese/185483726
5. QualiTraxを参考にQA with ⽣成AIの体制を考える • QualiTraxはいわば「全部乗せQA⽅法論」 ▪ アジャイル開発‧モデルベースド開発 ▪ TDD ▪ QA/テストアーキテクチャ‧テスト観点によるテスト設計 ▪ テスト⾃動化‧テスト⾃動⽣成 ▪ シフトレフト/フロントローディング‧シフトライト ▪ AI(機械学習)の活⽤ ▪ • ⽣成AIの台頭により モデルベースド開発化‧テスト⾃動⽣成体制の実現に追い⾵ ▪ QualiTraxライクな ⽣成AIとの主従逆転QA体制を作りやすくなった、かも 5
6. ⽣成AIは「⾺」 • ⽣成AIは明⽇にでも ⼈間よりパワー(技術⼒)もスピードもある存在になる ▪ もうすでにかもしれないが…… ▪ • ⾺も「⼈間よりパワーもスピードもある存在」 ▪ ⾺と同様に ⽣成AIの「⼿綱」と「乗り⽅」が重要になる 6 https://jra.jp/gallery/3minmeiba/horse6/index.html
7. ⽣成AIの「⼿綱」 • ⽣成AIを使ったコーディングの「⼿綱」の流派は⼤きく分けて2つ ▪ ⼿綱をしっかり握るプロンプトエンジニアリング派 ▪ ⼿綱をほとんど握らないバイブコーディング派 • QA with ⽣成AIにおいては「⼿綱をしっかり握る」⽅針が良い ▪ QAのキモは説明責任を果たすこと ▪ バイブQAでは説明責任を果たせず 品質を保証できない • ただしプロンプトに全ての指⽰を内包する⽅針は良くない ▪ すぐに⼈間がQA活動の全貌を把握できなくなる ▪ 補⾜‧注意‧その他といったセクションがどんどん肥⼤化する • モデルに情報を集積し プロンプトでモデルの使い分けを指⽰する⽅針にする ▪ PlantUMLやMermaidなど 実態はテキストファイルだが画像にも簡単に変換できる形式でモデルを書く 7
8. 「⼿綱」としてのモデル • どういうモデルが「⼿綱」として必要なのか テストの5W1Hをもとに考えてみる ▪ When: テスト/QAプロセス → QAアーキテクチャ内で定義可能 ▪ Where: テスト環境 → QAアーキテクチャ内で定義可能 ▪ Who: ⽣成AIが主‧⼀部⼈間 → 本⽅法論における前提なので決定済 ▪ What: テスト対象プロダクト → 仕様のモデルで表現可能 ▪ Why: テスト/QA観点 → QA観点図で表現可能 ▪ How: ⾃動テストフレームワーク → 本⽅法論のスコープ外 ▪ • ⼿綱として下記3つのモデルがあればよさそうだ ▪ QAアーキテクチャ (= テストアーキテクチャ + レビューアーキテクチャ) ▪ 仕様のモデル ▪ QA観点図 (= テスト観点図 + レビュー観点図) 8
9. 「仕様」という⾔葉の危うさ • 「仕様」という語が指す概念はロールや場⾯によって異なる ▪ • そのため「仕様のモデル」として整理しておくべき情報は どの「仕様」なのか検討する必要がある ▪ メンテナンス‧保守運⽤しやすい抽象度にする必要がある • 握りやすい⼿綱にする ▪ • 本⽅法論ではユーザ⽬線の使い⽅のモデルを使うことにする ▪ ⼤抵のQAエンジニアにとって(恐らく)最も直感的な抽象度であるため 9
10. ⽣成AIの「乗り⽅」 • 本⽅法論では下記のような役割分担‧プロセスである BFBL(Boosted FeedBack Loop)を「乗り⽅」とする 1. ⼈間がモデルを作る 2. ⽣成AIがそのモデルに基づいてQA活動を実施する 3. その結果から導かれる改善案を⼈間に提案する 4. ⼈間がそれを⾒てさらなる発想‧アイデアを加え 意思決定し 適宜モデルを更新する 5. • 補⾜: BFBLはBETを参考にした概念‧プラクティスである ▪ BET; Boosted Exploratory Testing (c.f. https://ieeexplore.ieee.org/document/9440172) • AIにより⼈間のセンスをブーストさせる探索的テスト ▪ BFBL; Boosted FeedBack Loop • ⽣成AIにより⼈間の発想‧アイデアをブーストさせるフィードバックループ 10
11. QualiTraxを参考にしたQA with ⽣成AIの体制 • このスライドで紹介する⽅法論は ▪ QualiTraxを参考にした ⼈間以外のプレイヤーが実⾏主体のQA⽅法論である • 現時点では実⾏主体は⽣成AIを想定している • しかし将来的にこれが変わっていく場合を考慮し ⽣成AIに限定はしていない - つまり⽣成AIは重要なファクターではあるが本⽅法論の本質ではない ▪ モデルドリブンな⽅法論である • よくある「仕様の情報を仕様書(ドキュメント)で与える⽅法」は採⽤せず 「モデルで与える⽅法」を採⽤している • 特に「仕様のモデル」について 保守運⽤の容易性を考慮して ユーザ⽬線の使い⽅のモデルを採⽤している • このスライドで紹介する⽅法論を以降 UQAM; Usage-model-driven QA Methodology と呼称する 11
12. UQAMで推奨するプロセスの全体像 12 QAウェア: テストウェアをQA活動全体に拡張した⾔い⽅
13. UQAMで推奨するプロセスの詳細 • 途中成果物のレビュー ▪ 要件‧設計‧プロダクトコードなどについて ⽣成AIでQA観点図に基づいたレビューコメントを作成する • c.f. “レビュー体系化”の経過報告 レビュー体系とレビューアーキテクチャ c.f. https://www.jasst.jp/symposium/jasstreview23/pdf/S1.pdf ▪ ⼈間がBFBL的なレビュー‧修正を⾏い 途中成果物の作成者にレビューコメントを伝える • 仕様のモデルの更新 ▪ ⽣成AIで途中成果物に基づいた仕様のモデルの更新を⾏う ▪ ⼈間がBFBL的なレビュー‧修正を⾏う • テスト開発 ▪ ⽣成AIで 途中成果物‧QA観点図‧仕様のモデルに基づいてテスト開発を⾏う • ⼤部分については⽣成AIで⾃動テストスイートを⾃動⽣成する - c.f. FaVSTeP; Fully-automated VSTeP c.f. https://www.slideshare.net/slideshow/line-developer-meetup-in-tokyo-39-presentation-modified/104158117#88 • 極⼀部のテストスイート(e.g. 定性評価が必要‧⾃動化するとFlaky)については ⼈間がBETの起点として実⾏‧利⽤する • QA観点図とQAアーキテクチャの更新 ▪ ⽣成AIでテスト結果に基づいた改善案を作成する ▪ ⼈間がその改善案に基づいたBFBLで改善施策を仕上げ 適宜QA観点図‧QAアーキテクチャの更新を⾏う 13
14. UQAMを実現できたら • プロダクトの設計‧実装について下記のような主張が多くある ▪ ⽣成AI活⽤により空いた⼯数は さらなるプロダクト設計‧実装で消費するのではなく 顧客/同僚との対話やユーザー理解‧プロダクト理解に使うべき • QAについても同様である ▪ UQAMの導⼊など⽣成AI活⽤により空いた⼯数は テストを増やすあるいはQA⼈員を削減するといった形で消費するのではなく 顧客/同僚との対話やユーザー理解‧プロダクト理解に使うべき • 顧客/同僚との対話: - 顧客と対話し 顧客にとっての「品質」が何なのか解像度を上げる - 設計‧実装プロセスの改善をQA以外のエンジニアと共に⾏う - PdMとプロダクトの将来像について議論する - マネージャーや経営陣と組織の将来像について議論する • ユーザー理解‧プロダクト理解: - プロダクトが使われている現場へ⾒学に⾏く(三現主義) - プロダクトを触る時間を増やす 14
15. UQAMのまとめ • UQAM(Usage-model-driven QA Methodology)は ▪ レビュー‧(動的)テスト‧改善施策開発といったQA業務を ⽣成AIが主体になって実施し ⼈間はそのサポートをする という体制を実現するための⽅法論である ▪ ⽣成AIの「⼿綱」としてモデルを重視している • QAアーキテクチャ • 仕様(ユーザ⽬線の使い⽅)のモデル • QA観点図 ▪ ⽣成AIの「乗り⽅」としてBFBL(Boosted FeedBack Loop)を提案している ▪ その導⼊により空いた⼯数は 対話やユーザー理解‧プロダクト理解に使うべきという⽴場を取っている • テストで忙殺されているQAから あらゆる「品質」を保証するためにあらゆる業務を⾏うQAへと変わる きっかけのひとつに過ぎない 15
16. 参考資料 • Tomorrow's software testing for embedded systems 〜明⽇にでも訪れてし まう組込みシステムのテストの姿〜 ▪ https://www.slideshare.net/slideshow/tomorrows-software-testing-for-embedded- systems-japanese/185483726 • 説明できるテストをつくるためにできることを考える ▪ https://jasst.jp/symposium/jasst24tohoku/report_pdf/S1.pdf • Boosted Exploratory Test Architecture: Coaching Test Engineers with Word Similarity ▪ https://ieeexplore.ieee.org/document/9440172 • JaSST nano vol.17 #3 「⽔銀中毒はAI⽺の夢を⾒るか」 ▪ https://youtu.be/EngO7O4hghw?si=szOG-6IOHeJPVkt_ • “レビュー体系化”の経過報告 レビュー体系とレビューアーキテクチャ ▪ https://www.jasst.jp/symposium/jasstreview23/pdf/S1.pdf 16
17. ここまでがUQAMの概要です 以降のページでは 特にweb系プロダクトに対する UQAMの実現⽅法のひとつとして いくつかモデルの具体例を紹介します
18. web系QAにてUQAMを実現するための推奨モデル 1. QAアーキテクチャテーブル 2. UCOD 3. AIM 18
19. QAアーキテクチャテーブル • どのQA観点をどのテストレベルで実⾏するか検討するための表 ▪ 列名はあくまで例であり 組織ごとに変更する • QA観点レベルでのQAアーキテクチャ改善に活⽤できる ▪ より早いテストレベル(左側の列)で実⾏するようにしよう(シフトレフト) ▪ リリース後のテストレベル(右側の列)で実⾏するようにしよう(シフトライト) 19 レビュー 静的解析 単体テスト 結合テスト システムテスト リリース後テスト モニタリング QA観点図 サブツリー名 1 観点数: n ケース数: m 観点数: n ケース数: m …… QA観点図 サブツリー名 2 …… QA観点図 サブツリー名 3
20. 仕様のモデル UCOD • UCOD(ユーコッド, UI Class Operation Diagram) ▪ c.f. https://github.com/hansuoi/ucod ▪ クラス図と画⾯遷移図をベースとしたモデリング記法 • 各ノードは POM(Page Object Model)を⽤いた⾃動テストのPage Objectクラスだと思えばよい • 各⽮印は画⾯間の遷移が可能であることを表す • ⽣成AIによる⾃動テスト⾃動⽣成のインプット⽤途以外に 複雑なページ(e.g. UI要素が多すぎる‧遷移先が多すぎる)を識別し仕様を改善する⽤途にも使える 20 B Page ------------------------ (Img) Logo ------------------------ Action 2 A Page ------------------------ (Button) To B Page ------------------------ Action 1
21. 仕様のモデル AIM • AIM(エイム, Action Impact Model) ▪ c.f. https://github.com/hansuoi/aim ▪ クラス図をベースとした プロダクトにおけるユーザーのアクションによる影響範囲を可視化して テストの"狙い"を定めるためのモデリング記法 • UCODの姉妹モデル • ⽮印は アクションからUI要素への影響(変更‧削除/⾮表⽰化‧追加‧etc.)を表す 21 B Page A Page (Button) To B Page Action 1 (Img) Logo Action 2
22. おしまい