SmartHR Tech Blog

SmartHR 開発者ブログ

探索的テスト補助用テストケースの自動生成 ー 使用したLLMプロンプトもご紹介

AI QA

探索的テスト補助用テストケースの自動生成 ー 使用したLLMプロンプトもご紹介
探索的テスト補助用テストケースの自動生成 ー 使用したLLMプロンプトもご紹介

勤怠管理機能チームでQAエンジニアをしているringoです。

勤怠管理機能の開発では、1つの大きな単位での機能を複数のProduct Backlog Item(以下、PBI)に分割し、リリース前に「フィーチャーテスト」という、機能全体の探索的テストを行なうフェーズを設けています。ここで言う探索的テストは、テスト実行者が機能を実際に操作しながら、事前に定義されていない観点や課題を能動的に発見していくテスト手法を指しています。

今回は、このフィーチャーテストのフェーズにおいて、Clineを用いて探索的テストの補助となるテストケースを生成する取り組みについてご紹介します。

勤怠管理機能チームの状況と開発プロセス

勤怠管理機能チームで行なっているフィーチャーテストは、1つの大きな単位での機能(フィーチャー)全体に対して行なうテストです。各PBIでは事前に考慮した受け入れ条件が正しく実装されているかを確認しているのに対し、フィーチャーテストではPBI同士のつながりやユーザーが一連の機能を触る上で不都合がないかなど、能動的に問題を探す役割を持たせています。

現在、勤怠管理機能は3チーム体制で開発を進めており、2人のQAエンジニアが専属で所属しています。サイズが大きかったり、複雑だったりする機能についてはQAエンジニアが率先してフィーチャーテストを実施していますが、すべてを実施しようとすると開発のボトルネックになってしまいます。

そのため、チームのメンバーであれば誰でもフィーチャーテストができるよう、メンバー向けのマニュアルを作成しました。このマニュアルには、探索的テストの勘所やどのようにテストの終了を判断すればいいか、などを記載しています。 しかし探索的テストに慣れていないと、テストが不足してしまったり、どこから触るのがよさそうなのかの判断が難しいという課題がありました。また、3チームが並列で開発を進めており、次第に大きくなるプロダクトの仕様を全て把握するのは困難な状況でした。

そこで、探索的テストの補助として、PBIの内容や社内ドキュメント、観点を踏まえた上でAIにテストケースの候補を出力してもらうプロンプトを書いて運用してみることにしました。

注意点として、生成されたテストケースは探索的テストの「テストチャーター」の一部として扱っています。テストチャーターとは、探索的テストにおいて「道しるべとなるもの」で、テスト実行者が何を目的として、どの部分に注目してテストを進めていくかの指針となるものです（詳しくはJaSST'18 Tokyo「やってみよう！探索的テスト」をご参照ください）。生成されたテストケースをそのまま実施して探索的テストを完了とするのではなく、これらを出発点として、テスト実行者が柔軟に探索範囲を広げていく、という使い方を想定しています。

テストケース生成のためのプロンプト設計

テストケース生成にはLLMを活用したAIアシスタントツールのClineを採用し、精度向上のため以下の情報源を参照できるようGitHubとDocBaseのMCPサーバを設定しています。

  • PBIの詳細情報 (GitHub)
  • プロダクトの仕様や設計ドキュメント (GitHub, DocBase)
  • テスト観点のリファレンス (DocBase)
# .clinerules

## Rules
### name: テストケースの出力
description: 親issueに紐づく子issueの一覧から、フィーチャーテストで実施するテストケースの候補を生成します

parameters:
  - name: parent_issue_id
    type: string
    description: 親issueのID (例: org/reponame#1234)
    required: true

examples:
  - input: parent_issue_id = "org/reponame#1234"
    output: |
      探索的テストの観点と確認項目ごとの具体的な操作ステップを以下に提案します：

      ## 1. 実績の編集に関する確認
      ### 1-1. 複数の休憩時間を持つ勤務日で、休憩を1つずつ削除した際に他の休憩時間が正しく保持されている
      - [ ] 以下のパターンで日をまたぐ勤務を登録し、前日・翌日との重複チェックを確認する
        1. 当日23:00-翌1:00の勤務を登録
        2. 翌日の勤務情報画面で0:30に出勤打刻を登録
        ... (以下略)

steps:
  1. constraintsの「参考にするドキュメント群」に記載されたドキュメントをすべて取得する
  2. 「参考にするドキュメント群」に記載されたドキュメントをすべて取得できているか確認する
      - 取得できていなければ前のステップが正しくできていないのでやり直す
  3. 親issueを取得する
    - docbaseへのリンクがissue内に含まれていたら、そのドキュメントも取得する
  4. parent_issue_idから子issueの一覧を取得する
    - 子issueの一覧取得の条件
      - search_issues toolを使用すること
      - 以下のパラメータを使用すること
        - "q": "is:issue parent-issue:org/reponame#{issue_number}"
      - 1APIで30件までしか取得できないため、全件取得できるまで繰り返すこと
  5. parent_issue_idの子issueの件数を確認し、前のステップで取得した子issueの数と一致するか確認する
      - 一致しなければ前のステップが正しくできていないのでやり直す
  6. 子issueの内容から主要な機能や変更点を分析する
  7. 探索的テストの項目を生成する
    - 特にプロダクトとして優先すべき項目から順番に挙げること
    - 「参考にするドキュメント群」の内容を優先度の判断に加味すること
  8. チェックリスト形式でmarkdownとしてファイル出力する
    - 項目ごとに、それをどのように確認するか、可能な限り具体的にステップを記載すること
    - 実際にどのステップでどのような値を入力するか、どのようなことを確認するかなどを記述しなければならない

constraints:
  - すべてのステップについて、それが正しく実施されているかどうかをチェックし直すこと
  - docbaseMcpのsearchPosts は使用禁止
  - テストケースの生成について
    - 受け入れ条件と同様の書き方（`- [ ]` 形式）を使用する
    - issueに記載された受け入れ条件はすべて確認済みであるとする
    - 各カテゴリ1-6個程度の具体的な確認項目を含める
      - プロダクトとして注目すべき観点ほど項目を多く提案して良い
    - エッジケースや複数機能の組み合わせに注目する
  - 参考にするドキュメント群
    - 以下に挙げたドキュメントの内容を加味した上でテストケースを生成すること
      - [勤怠管理機能プロダクトの概要説明](DocBaseのURL)
      - [勤怠管理機能テスト観点リスト](DocBaseのURL)
      - [勤怠管理機能 探索的テストの手引き](DocBaseのURL)
      - [勤怠管理機能で防ぎたいバグ一覧](DocBaseのURL)
        - ここに掲載されているものは、探索的テストで確認すべきものとして優先度が高い

.clinerules ファイルの中で、「テストケースの出力」という名称でルールを定義しています。 以下、各項目についての補足説明をします。

examples

入力となる値と出力の例を明示しています。具体的なテストケースの記述フォーマットや、どの程度の詳細さが求められるかを示すことで、一貫性のある出力を得られるようになりました。

steps

MCPを使ってインプットとなる情報を取得する方法と、テストケースを出力する方法について具体的に記載しています。手順が多いほど、サイレントにステップを無視することがあるので、ステップ2や5のように、前のステップの完了を確認するステップを明示的にいれています。

constraints

制約条件として、stepに関わらず守ってほしいことを列挙しています。 「issueに記載された受け入れ条件はすべて確認済みであるとする」という記載は、フィーチャーテストが各PBIの受け入れ条件をそのまま確認することは目的としていないことを示しています。各PBIの受け入れ条件の確認が正しく行なわれていないのであれば、それはフィーチャーテストのフェーズではなく、PBIをマージするまでのプロセス改善で救うべき、という設計にしています。 また、勤怠管理機能というプロダクトのコンテキストを把握させるため、ドキュメントとして以下を読ませています。

  • 勤怠管理機能プロダクトの概要説明
  • 勤怠管理機能テスト観点リスト
  • 探索的テストの手引き
  • 勤怠管理機能で防ぎたいバグの一覧

テスト観点リストは、勤怠管理機能やSmartHRプロダクト全体で必要な観点を網羅したドキュメントです。このリストは、書籍『アジャイル品質パターン「QA to AQ」』で紹介されている「品質チェックリスト」を参考に、勤怠管理機能固有の要件や品質基準を加えて作成しています。

テストケースの生成例

以下は実際にテストケースを生成した例です。

[入力]
@/.clinerules  の「テストケースの出力」の手順に従って org/reponame#3535 のテストケースを出力してください
[出力]
テストの観点と確認項目ごとの具体的な操作ステップを以下に提案します：

## 1. 基本的な労働日・休日区分の変更
### 1-1. 管理者・上長による直接編集
- [ ] 労働日から法定休日・所定休日への変更
  1. ある従業員の労働日の勤務情報を開く
  2. [編集]メニューから労働日を法定休日に変更して保存
  3. 同様に所定休日に変更して保存
  4. 変更履歴に変更内容が正しく記録されていることを確認

### 1-2. 労働日・休日区分の変更申請
- [ ] 従業員による変更申請と承認フロー
  1. あなたの勤務情報画面から労働日を所定休日に変更申請
  2. 上長が申請を承認
  3. 承認後に勤務情報が正しく更新されていることを確認

## 2. 代休・振替に関連する変更パターン
### 2-1. 振替出勤・振替休日の設定
- [ ] 代休・振替休日設定で振替が許可されているケース
  1. 法定休日を振替出勤に設定し、対応する振替休日を別日に設定
  2. 設定した両日の勤務情報が正しく連動して更新されることを確認
  3. 振替休日側の勤務情報の編集が制限されていることを確認

### 2-2. 休日出勤と代休の連携
- [ ] 代休の自動付与と利用制限
  1. 所定休日に休日出勤を設定し代休利用を「する」に設定
  2. 出退勤実績を登録
  3. 代休が正しく付与されることを確認
  4. 休日出勤日より前の日付で代休を取得できないことを確認

## 3. エッジケースとエラーパターン
### 3-1. 複数の変更を組み合わせたケース
- [ ] 以下の組み合わせパターンで検証
  1. 振替の取り消しと労働日・休日区分の変更を同時に実施
  2. 休日出勤の適用と労働日・休日区分の変更を同時に実施
  3. それぞれ保存が成功し、意図した通りの状態になることを確認

### 3-2. バリデーションの確認
- [ ] 不正な操作に対するエラーチェック
  1. 休日出勤が設定されている日の労働日・休日区分を変更しようとする
  2. 振替出勤が設定されている日の労働日・休日区分を変更しようとする
  3. 適切なエラーメッセージが表示されることを確認

## 4. 履歴管理と休日設定との連携
### 4-1. 変更履歴の記録
- [ ] 各種変更のタイミングでの履歴記録
  1. 振替出勤・振替休日の設定時の履歴
  2. 休日出勤の設定時の履歴
  3. それぞれの変更前後の状態が正しく記録されていることを確認

### 4-2. 休日設定との整合性
- [ ] 休日設定変更時の挙動確認
  1. 労働日・休日区分を変更して保存
  2. 休日設定を更新
  3. 変更した労働日・休日区分が維持されることを確認

## 5. モバイル対応とUI確認
### 5-1. スマートフォンでの表示・操作
- [ ] モバイル環境での操作性確認
  1. iPhoneとAndroidそれぞれで勤務情報画面を開く
  2. 労働日・休日区分の変更操作を実行
  3. 各要素が適切に表示され、操作可能であることを確認

### 5-2. UI表示の一貫性
- [ ] 各状態でのUI表示確認
  1. 申請中の場合の表示
  2. 確定済みの場合の表示
  3. エラー時の表示
  4. それぞれの状態で適切なUIが表示されることを確認

1回の指示に対して、だいたい上記のような出力が行なわれます。 生成されるテストケースは、代表的なシナリオから始まり、込み入ったシナリオ、他の機能との組み合わせ、最後の方に見落としがちな観点でのテスト（モバイル環境での動作確認やユーザビリティなど）という順で提案されることが多かったです。特に前半に出力されるテストケースは仕様としては正しいものになっていることがほとんどで、後半にいくほどあまり正確ではなくなっていく傾向がありました。

たとえテストケースとしては正しくなくても、人間がそれをチェックする中で観点に気づけるので、特に大きい機能ほど参考になると感じることが多くありました。また、出力された内容に対して「3のエッジケースとエラーパターンの観点で、さらにテストケースを生成して」と追加の指示をして掘り下げてもらうこともできるので、探索的テストをしながら気になった部分を深堀りして確認していくという使い方ができました。

成果と課題

今回のテストケース生成においては、プロダクトコードを読ませることはしておらず、基本的には自然言語で書かれたドキュメントがインプットデータとなっています。これらはAI生成のために記述したのではなく、もともと勤怠管理機能の開発チームメンバー同士が読むために書かれたドキュメント群だったので、この取り組みもかなり簡単に試すことができました。PBIの受け入れ条件を記載するときは、読む人によって解釈の揺れがないような文章、MECE 1 な記述を心がけるようにチームで継続的に改善を重ねていたので、そういった活動も良い影響を及ぼしたのではないかなと思います。

一方、プロダクトコードを参照していないため、提案されるテストケースの内容がどうしてもブラックボックステストに終始してしまったという課題もあります。この点については、プロダクトコードも観点に含めるような改善を検討したいです。

今後の展望

勤怠管理機能チームではPBIの作成にもAIを活用しており、受け入れ条件は詳細かつ網羅的になりました。曖昧さは減りましたが、文章量が増えたことで人間による確認作業の負荷が高くなっています。

現状ではAIによるテストケース生成はテスト実施者の助けになるレベルに留まっており、一部の仕事を代替するまではできていません。 社内の別の開発チームではブラウザテストもAIに実施させて、そのレポートを人が確認する、という方法を実践し始めているところもあります。今回のAIによるテストケース生成とAIによる実施を組み合わせることができれば、単純な確認はAIにやらせて、そこから漏れているものを人間が考える、というやり方でより一層の生産性向上を目指したいと考えています。

We Are Hiring!

SmartHRではAIを使って生産性を上げようという活動を全社で活発に行なっています。 プロダクトコードを生成させることについては定着していますが、品質保証における生産性向上はまだ発展途上であり、大きな伸びしろがあると思います。AIによる開発が当たり前となっていく状況で、どのように品質保証活動をするのが良いのかを一緒に考えたい方、ぜひご応募をお待ちしております。

  1. Mutually Exclusive and Collectively Exhaustiveの略。「互いに重なり合わず、かつ全体的に漏れなく網羅された」状態を指します。↩