はじめに
SkillnoteでQAエンジニアをしている山添です。生成AIを実務に取り入れる取り組みとして、テスト設計の一次案をPullRequest時にAI（Devin）で自動生成する仕組みを試し、運用を始めました。狙いは2つです。
- 設計工数の削減：スクラムチームの時間を開発へ回す
- 観点の抜け漏れ削減：人に依存しがちな網羅性を底上げする
どうやっているの？
ざっくり下記のフローでAIによるテスト設計が実行されるようになっています。（下記フローとは別にGitHub上でPRに特定のLabelをつけることで手動実行もできます。）
- 人間がストーリーチケット単位での開発完了後、指定したブランチに対してPRを作成
- GitHub Actionsが起動し、Devin APIを呼び出し
- テスト設計の一次案（CSVおよびExcel）をDevinが自動生成、PRに投稿される
- QA／開発がレビューし、テスト実施
PR後、DevinのセッションURLが投稿され、Devinセッションの中でテストケースが作成される
Devinのインプットに使っている情報は主に下記の3点です。
-
Jiraチケット：背景、受け入れ条件、影響範囲などコンテキスト（文脈）を与える
SkillnoteではPR時、題名にJiraのチケット番号を記載する習慣があるので、GitHub Actionsからそのチケット番号をDevinに渡すことで該当のJiraチケットを参照させています。 - PR差分：どこをどう変えたか、実装で具体的に変更した部分の情報
- テスト観点表：QA／開発で整理しているテスト観点
実行フロー概要
実際のアウトプット
実際のアウトプットはこんな感じです。個人的にはテストケースも読みやすく、人間が書いたものよりレビューしやすいのではないかと思っています。
テストケース一例
運用してわかったコツ
LLMのアウトプットを制御する
-
出力フォーマットを固定
出力フォーマットを固定させることで常にアウトプットを同じものにさせます。（例：ID,テスト概要,手順,期待値,作成背景等）
特に、なぜこのテストケースをAIは作成したのか不明になることもあるので、「作成背景」のような項目も出力させると、人がレビューしやすいです。
また、DevinのPlaybooks機能を使って処理をテンプレート化し、再利用できるようにしています。
プロンプト例（※一部抜粋）
-
変換処理も固定化
初めの方はDevinのExcel出力が安定せず、出力される行が崩れたりなどの問題がありました。根本原因はCSV ⇒ Excelに変換するときの処理が毎回異なっていることでした。
対策としてはPythonスクリプトを直接プロンプトに記載し、そのスクリプトを使用させることで、確実に毎回同じ処理を実行させられるようになり、常にアウトプットを期待した形で出力することができました。 -
用語の選び方に注意
プロンプトに入力する内容として、たとえばホワイトボックス／ブラックボックスなど、単語1つで出力の方針が大きく変わるため、期待するアウトプットが得られるように用語の選択を調整したほうがよいです。
実際の効果は？
下記は概算ですが、10ケースあたり約35分ほどの工数削減ができている認識です。
- 人がゼロから10ケース作る：約50分
- Devin＋人のレビューで10ケース：約15分
→ 10ケースあたり約35分の削減見込み
また、人間が考慮できなかった（Devinの作成した）テストケースで不具合が見つかるケースがあり、冒頭で記載した狙い（設計工数の削減、観点の抜け漏れ削減）に対しても効果があると感じています。
正直、うまくいっていないところと改善案
-
観点表の活用不足
Devinにテスト設計時にテスト観点表を参照させていますが、網羅性がまだ弱いです。下記のように生成用とレビュー用で役割を分けたAIを用意すると精度が上がりそうだと考えており、検証してみたいです。- 生成用AI：文脈と実際の変更点、および観点表ベースでケースを作成
- レビュー用AI：欠落／重複／曖昧さを指摘する
-
設計タイミングが遅い
現在のDevinによるテスト設計は、実際のコードを読むことでテスト設計を行っているので、ある程度実装が進んだ状態でしか使用できません。またホワイトボックス的な内容が重視されているケースも見受けられます。
実装前にテストケースを作ることで考慮漏れを防ぎ品質をより高められるため、より速いフェーズで使用できるAIによるテスト設計の導入を考えていきたいです。 -
意識せず使ってもらえる仕組みができていない
少しずつチームでの使用率が上がっていますが、完全に仕組化できていないため、AIでのテスト設計が十分に活用されないケースがあります。QAとしてはAIでのテスト設計を使用するメリットを十分検証できているので、今後は意識せず最適なタイミングで実行できる仕組みを構築していきたいです。
おわりに
今回はQAチームの活動を紹介しました。今後も各技術領域のエンジニアが記事を公開していく予定なので、ぜひチェックしてみてください！
Discussion