kickflow Tech Blog

株式会社kickflowのプロダクト開発本部によるブログ

Pull Request単位のホワイトボックステスト観点をAIで自動生成する

AI Devin QA GAS テスト設計 ホワイトボックステスト技法

こんにちは、kickflow QAチームの川村です。

ホワイトボックステストにおける観点抽出に課題を持つQAチームは多いと思います。
コードの実装に踏み込んだ観点は仕様書から読み取れず、どうしても担当者のスキルや経験に依存しがちです。

kickflowのQAチームでは、この課題を解決し、テストの品質と効率を向上させるために、AIを活用したテスト観点抽出の自動化に取り組みました。

この記事では、Devin と Slack を活用し、Pull Request (PR) の内容からホワイトボックステストの観点を自動で抽出し、テスト管理ツールである Qase にテスト項目書を作成するまでの仕組みをご紹介します。

構築したシステムの概要

今回構築したのは、Slackでの簡単な操作をトリガーとして、AIがPRのコード差分を解析し、ホワイトボックステストの観点を抽出し、最終的にQaseへテストケースとして自動登録する一連のワークフローです。

この仕組みにより、これまで手作業で行っていた多くのプロセスを自動化し、開発サイクルの高速化と品質の安定化を目指しました。

この仕組みで目指したもの

このシステムを構築するにあたり、以下の4つの目的を掲げました。

  • 工数削減: テスト観点の洗い出しやテストケース作成にかかる手動作業を大幅に削減します。
  • 品質の標準化: AIが網羅的な観点を提示することで、レビュアーのスキルレベルに依存しない、抜け漏れの少ないテスト観点を得られます。
  • 属人化の解消: ワークフローとして標準化することで、誰でも同じ品質のテストケースを効率的に生成できます。
  • トレーサビリティの確保: GitHub のPR、Issue、Qaseのテストケースが連携し、変更とテストの追跡を容易にします。

自動化の全体像と処理フロー

システムは、以下のシーケンスで動作します。担当者が行う作業はSlack上でのリアクションやURLの入力など、ごくわずかです。

sequenceDiagram
    autonumber
    participant 担当者
    participant Slack
    participant Devin
    participant GitHub
    participant Googleスプレッドシート
    participant Qase

    %% 1. Slackでのワークフロー開始
    担当者->>Slack: 対象メッセージにリアクションする
    Slack->>Slack: ワークフローが発火する
    Slack-->>担当者: PR提出用のボタン付きメッセージを投稿する
    担当者->>Slack: ボタンを押し、PRのURLを送信する

    %% 2. Devinがテスト観点を抽出しIssueを作成
    Slack->>Devin: Playbookを実行し、PR情報を渡す
    Devin->>GitHub: PRを解析してテスト観点を抽出する
    Devin->>GitHub: テスト観点に基づきIssueを作成する
    GitHub-->>Slack: 作成されたIssueをチャンネルに通知する

    %% 3. IssueからQaseへテストケースを生成
    担当者->>Slack: 通知されたIssueプレビューの内容をコピーする
    担当者->>Googleスプレッドシート: 内容を貼り付けて実行ボタンを押す
    Googleスプレッドシート->>Googleスプレッドシート: 内部でGAS(Google Apps Script)が起動する
    Googleスプレッドシート->>Qase: API経由でテストケースを作成する
    Qase-->>Googleスプレッドシート: 処理結果を返す


各ステップを詳しく見ていきましょう。

1. Slackでのワークフロー起動

すべてのプロセスは、Slackのリアクションから始まります。

担当者がQA依頼のあったSlackメッセージに特定の絵文字でリアクションすると、Slackワークフローが起動します。これにより、スレッド内にPRのURL提出を促すボタン付きのメッセージが自動で投稿されます。

2. Devinによるテスト観点の抽出とGitHub Issueの作成

次に、AI（Devin）がテスト観点を抽出します。

担当者は、Slackに投稿されたメッセージのボタンをクリックし、表示されたモーダルに対象となる開発チケットのGitHub PRのURLを入力します。

この操作をトリガーに、あらかじめ定義しておいたDevinのPlaybookが実行されます。Devinは受け取ったPRのURLからコード差分や関連情報を解析し、ホワイトボックステストの観点を自動で生成します。

生成されたテスト観点は、以下のようにGitHub Issueとして自動で起票されます。

3. Qaseへのテストケース自動生成

最後に、GitHub Issueの内容をQaseに連携します。

GitHubとSlackの連携機能により、Issueが作成されると指定のSlackチャンネルに通知が届きます。
ここからQaseへの登録は、Google Apps Script (GAS) を使って自動化しています。

  1. 担当者はSlackに投稿されたIssueのプレビュー内容をコピーします。
  2. 専用のGoogleスプレッドシートにペーストし、実行ボタンを押します。
  3. GASが起動し、スプレッドシートの内容を解析してQase APIを呼び出します。
  4. Qase内にテストケースが自動で生成され、プロセスは完了です。

工夫した点

この一連のフローには、いくつか工夫した点があります。

  • なぜわざわざPRのURLを貼らせるのか？
    • これは仕組みというより運用上の都合です。1つのタスクチケットに複数のPRが紐づいたり、反対に複数のチケットが1つのPRで対応されることがあるため、明確にどのPRがテスト対象であるかの最初の指示の部分は人がやった方が手戻りが少ないと考えたからです。
  • なぜSlackを経由するのか？
    • 業務委託のテストベンダーメンバーにGitHubアカウントを配っていない場合でも、Slack上の情報だけで作業を完結できるようにするためです。プロパーの作業待ちをなくすことも今回の目標の1つでした。
  • なぜ一度GitHub Issueに書き出すのか？
    • Devinが生成するMarkdownテキストは、そのままSlackに投稿すると書式が崩れることがありました。一度GitHub Issueに整形された形式で出力し、そのプレビューをSlackに通知することで、書式崩れを防いでいます。
  • Zapierの活用
    • さらに、Devinが常に意図したフォーマット（コードブロックなど）で出力してくれるとは限りません。そのため、GitHubからSlackへ通知する間にZapierを挟み、Issueの本文を強制的にコードブロック化する処理を追加しています。これはGithub Actionsで自作のjobを組んでも良いので必ずしもZapierが必要なわけではないですが、フィルタ条件を指定するのにZapierのほうが楽だったので利用しています。
  • なぜスプレッドシートを経由するのか？
    • Devinの観点をそのままQaseにアップロードすることもできますが、出てきた観点で不要な項目を削除したり、文言を修正したりする作業はスプレッドシート上でやってしまったほうが労力がかからないためです。

苦労した点

DevinのPlaybookのプロンプト調整

この仕組みの肝となるのが、Devinに与える指示（プロンプト）です。狙い通りの質の高いテスト観点を得るために、試行錯誤を重ねました。

単に「テスト観点を出して」と依頼するだけでは、期待する結果は得られません。テスト対象のシステム特性に合わせて「どのようなテスト観点を」「どのテスト技法を用いて」生成してほしいかを、こちらから明確に指示する必要がありました。

また、コツのような感じですが、以下の一文をプロンプトに加えることが非常に効果的でした。

テスト観点は必ずエンドユーザー目線で記載すること（ソースコードの関数名やjob名などは使わないこと）

AIはコードを直接解析するため、どうしても関数名やジョブ名といった実装レベルの言葉をそのまま使いがちです。
この一文を加えてあげることで、実際にテストを行うテスターが実装の詳細を知らなくても理解できる、分かりやすい観点が出力されるようになりました。

DevinからQaseへのデータ連携フロー

もう一つの課題は、Devinが生成したテスト観点を、いかにしてテスト管理ツールであるQaseにスムーズに登録するかでした。

ここでも鍵となったのはDevinのプロンプトで、試行錯誤の結果、毎回ほぼ同じフォーマットで観点を出力させられるようになりました。この安定した出力を前提とし、GoogleスプレッドシートとGAS（Google Apps Script）を中継させる方法を採用しました。

Devinが出力したテキストをスプレッドシートに貼り付けると、スプシで組んでおいた関数がネスト構造などを自動で整理し、GASでQaseのAPIが受け取れる形式に変換してアップロードします。
この仕組みにより、複雑なSuiteやCaseの親子関係を含めて一括でテストケースを登録できるようになりました。

まとめ

今回は、Devin、Slack、GitHub、GAS、Qaseといった複数のサービスを連携させ、PRからのホワイトボックステスト観点抽出とテストケース生成を自動化する仕組みを紹介しました。

この仕組みを導入したことで、テスト観点の洗い出しにかかる時間を大幅に短縮できただけでなく、AIによる網羅的な視点を取り入れることで、テスト品質の底上げにも繋がっています。

手動作業が減ったことで、QAチームはより創造的な業務や、複雑なテストシナリオの設計に集中できるようになりました。今後も、AIや自動化技術を積極的に活用し、開発プロセス全体の生産性と品質を向上させていきたいと考えています。

最後に

kickflowでは、このように技術を活用してQAプロセスを改善していくことに興味がある仲間を募集しています！

少しでも興味を持っていただけた方は、ぜひ採用サイトをご覧ください。

careers.kickflow.co.jp