AI new
AIを活用してテストケースを書いてみる
皆さんお久しぶりです、かっちゃんです。 最近NextatではCodexを使用して開発の効率を上げていこう期間に入りまして、その一環で記事を書いています。
テストケース ✖︎ AI で楽にテストを書こう
今回、なぜテストケース ✖︎ AI という組み合わせにしたかというと、自分自身がテストケースを書くのが苦手だからです。笑
めっちゃ細かいところまで書かないとダメだし、いろんなパターンのケースを考えないといけないし、思考量も書く量も非常に多くて大変です。そこで文章理解と、思考をまとめるのが得意な AIに嫌な部分を担ってもらおう ということです。
大前提として、実装の元となる設計書が詳細に書かれていること。
じゃないと今回の記事で紹介する手法の本領は発揮されません。
BDDという開発手法を使う
BDDとは Behavior-Driven Development（振る舞い駆動開発） の略で、ソフトウェア開発における開発手法の一つです。
BDDは、既存のテスト駆動開発（TDD）を発展させたもので、テストを書く前に「何を作るべきか」の共通理解を深めることに重点を置いています。
テストを書く前に「何を作るべきか」を深めるというところがポイントです。
Gherkin（ガーキン）形式
BDDでは「Gherkin（ガーキン）」と呼ばれる特定の形式の自然言語を使用して、テストケースを記述します。Gherkinは以下の3つのキーワードを中心に構成され、これを「シナリオ」または「ユーザーストーリー」と呼びます。
| キーワード | 役割 | 意味 |
|---|---|---|
| Given (前提) | システムの初期状態や環境を設定する。 | 「〇〇が既に存在する状態のとき」 |
| When (事象/行動) | ユーザーが行う行動や、システムに起こるイベント。 | 「ユーザーが××という操作をしたとき」 |
| Then (結果) | 期待されるシステムの結果（振る舞い）。 | 「システムは△△という結果を返すはずだ」 |
【記述例】
フィーチャ: ログイン機能 利用者は正しい認証情報でシステムにログインできる シナリオ: 成功ログイン Given ユーザー「Taro」がデータベースに登録されている When ユーザーがメールアドレスと正しいパスワードを入力してログインボタンを押す Then ユーザーはダッシュボード画面にリダイレクトされる
AIに設計を読ませてBDDを書いてもらう
まず必要なのがAIに読み込ませるための設計と、BDDを作成してもらうためのルールです。
AIへの指示（ルール）
あなたはソフトウェア品質保証とテスト設計の専門家です。 以下の「要件」と「設計」を読み取り、BDD（Behavior Driven Development）の形式で日本語のシナリオを作成してください。 出力フォーマットは以下の通りにしてください： 機能: [対象となる機能の簡潔な説明] | シナリオ | 前提 | 操作 | 期待結果 | | :--- | :--- | :--- | :--- | | [具体的なシナリオ名] | [テスト実行時の前提条件] | [ユーザーまたはシステムの操作・イベント] | [期待される結果] | ルール: - FrontとBackの両方の設計を読んで反映させてください - 各「機能」ごとに複数のシナリオを用意してください - 正常系と異常系を両方含めてください - シンプルで明確に、曖昧な表現を避けてください - テスト自動化や受け入れテストで利用できる粒度で記述してください - 正常系グループと異常系グループとバリデーションエラーに分けてください
ECサイト クーポン適用機能 設計書（要約）
今回は例として出しているので簡易的な設計になっています。
| 項目 | 概要 |
|---|---|
| 機能概要 | 注文時にクーポンコードを入力し、複数のビジネスルールに基づいたバリデーションと割引計算を行い、最終的な注文金額を確定する。 |
| 処理フロー | 1. クーポン取得 → 2. バリデーション実行（失敗で中断） → 3. 割引対象金額特定 → 4. 割引計算（上限額考慮） → 5. 最終支払額返却。 |
| バリデーション | 1. 存在確認（無効なクーポンコード）→ 2. 期間チェック（利用期間外）→ 3. 会員の使用回数チェック（上限到達）→ 4. 割引対象商品チェック（対象商品なし）→ 5. 最低利用金額チェック（金額不足）。 |
| 割引計算 | 割引対象金額 A に基づき、固定値もしくは割合で割引額 D を計算し、maxDiscountAmountで上限を適用する。総支払額 T = ({カート合計}) - ({確定割引額})。 |
AIのアウトプット：BDDシナリオ
これらのテキストをAIに読み込ませたアウトプットがこちらです。
今回は省いていますが、設計だけでなく要件も読み込ませるとより詳細なアウトプットを出してくれます。
機能: クーポンの適用と割引計算
| シナリオ | 前提 | 操作 | 期待結果 |
|---|---|---|---|
| I. 正常系グループ (成功ケース) | |||
| S-01: 固定金額割引の成功適用 | クーポンA（固定500円割引、上限なし）が有効期間内で、会員が未利用。カート内の対象商品の合計金額が3,000円。 | ユーザーがクーポンコード「A」を入力し、適用を試みる。 | 割引額が500円と計算され、総支払額が500円差し引かれて確定する。 |
| S-02: パーセント割引の成功適用 | クーポンB（10%割引、上限なし）が有効期間内で、会員が未利用。カート内の対象商品の合計金額が5,000円。 | ユーザーがクーポンコード「B」を入力し、適用を試みる。 | 割引額が500円（5,000円 × 10%）と計算され、総支払額が500円差し引かれて確定する。 |
| S-03: 割引上限額の適用 | クーポンC（15%割引、割引上限1,000円）が有効期間内で、会員が未利用。カート内の対象商品の合計金額が10,000円。 | ユーザーがクーポンコード「C」を入力し、適用を試みる。 | 計算上の割引額（1,500円）が上限を超過しているため、割引額が1,000円に固定され、総支払額が1,000円差し引かれて確定する。 |
| S-04: 最低利用金額の厳密な充足 | クーポンD（固定1,000円割引）の最低利用金額が5,000円。カート内の対象商品の合計金額が5,000円ちょうど。 | ユーザーがクーポンコード「D」を入力し、適用を試みる。 | 割引額が1,000円と計算され、正常に適用される。 |
| II. 異常系グループ (バリデーションエラーによる中断) | |||
| E-01: クーポン存在チェック失敗 | データベースにクーポンコード「INVALID」は登録されていない。 | ユーザーがクーポンコード「INVALID」を入力し、適用を試みる。 | 割引は適用されず、「無効なクーポンコードです。」のエラーメッセージが返される。 |
| E-02: 使用期間チェック失敗 | クーポンEの有効終了日時が、現在時刻より前に設定されている。 | ユーザーがクーポンコード「E」を入力し、適用を試みる。 | 割引は適用されず、「このクーポンは現在ご利用いただけません。」のエラーメッセージが返される。 |
| E-03: 会員の使用回数チェック失敗 | クーポンF（最大利用回数1回）が、当該会員によって既に利用済み。 | ユーザーがクーポンコード「F」を入力し、適用を試みる。 | 割引は適用されず、「このクーポンは使用回数の上限に達しました。」のエラーメッセージが返される。 |
| E-04: 割引対象商品チェック失敗 | クーポンGは特定カテゴリのみが対象だが、カート内の商品が全て対象外。 | ユーザーがクーポンコード「G」を入力し、適用を試みる。 | 割引は適用されず、「このクーポンはカート内の商品には適用できません。」のエラーメッセージが返される。 |
| E-05: 最低利用金額チェック失敗 | クーポンHの最低利用金額が5,000円。カート内の対象商品の合計金額が4,999円。 | ユーザーがクーポンコード「H」を入力し、適用を試みる。 | 割引は適用されず、「合計5,000円以上で利用可能です。」のエラーメッセージが返される。 |
これらのシナリオが一発で出てきてくれました。計算ロジックが4パターンと異常系が5パターンと、シナリオ自体の数は合っていますし、前提と操作と結果も分かりやすく書かれています。
あとは、これをプロジェクトのテンプレートに合わせて加工していけばテストケースの完成です。
まとめ
今回は例として出しているので簡単にうまくいってる感じが出ていますが、実際のプロジェクトになってくると設計が複雑だったり、そもそもの設計の情報が不十分だったりします。
なので、その時は今回の例をそのまま使うのではなく、部分的に使ってみたり、前提の知識を人間の手で加えたりと工夫が必要です。
テストケースに限らず、人間がどのようにAIを活用するかによって期待値が大きく変わってくると思うので、人間側のアップデートも必要だなとしみじみ感じております。
