トクバイ2人目のQAエンジニアとしてジョインした岡です。
トクバイはサービス対象で分けた場合、小売向けのtoB、消費者向けのtoCから構成されており、toB向けを担当しています。
toB向けサービスの開発過程におけるChatGPTを活用したシフトレフト1の取り組みとして、BDD(Behavior Driven Development) 2 のDSLであるGherkin3 を利用したテストケース作成の事例についてご紹介します。
私がこのブログの下書きをPullRequestしたらレビューがもらえるユーザーストーリーをGherkinで記載すると：
Function ブログのレビュー Scenario GitHubで下書きのPullRequest作成 Given 私がエンジニアとしてテックブログを下書きするとき When GitHubで下書きのPullRequestを作成すると Then 他のエンジニアがレビューして、フィードバックをくれる
のようになります。
環境的な背景
1名体制だった頃は、toBとtoCとQAエンジニアの3者でスプリント毎に協議の上で優先度が高い案件にQAをアサインする形でしたが、 2名体制に切り替わったタイミングでサービス対象毎の専任を設ける対応に変更しました。
トクバイのtoB部分は、主にサーバーサイドの開発領域が大部分を占めていて、 アジャイルテストの四象限の第1象限をrSpecによるUnitTest、FeatureTestやソースコードレビューによる品質保証を開発エンジニア自身が保っている側面が強いです。 更に、ビジネスインパクトを基に粒度を勘案して、ビジネス上大きなインパクトがある部分のユーザービリティや受け入れテストと言ったアジャイルテストの第2象限にあたるテストをPdMと協働で行う手動テストとして戦略をとっています。
現場での課題
受け入れテストにあたって、同じような言葉で構成したテストケースを作成するリードタイムが冗長であると考えられます。 理想としては、要件に対応するユーザーストーリーを作ってPdM, QA, エンジニアが合意したら、受け入れテスト項目が出来上がっているようにしたいと考えました。
ユーザーストーリーのテスト項目化やその先の自動化という点で、BDDのGherkin言語による構造化を考えましたが、 特に日本語はハイコンテクストな言語であることもあり、 GherkinのGiven部分をどう書くか等の記述に慣れるのに時間がかかることが懸念され、 習得するまでのコストや再現性をPdMに持ってもらうのが難しいことが考えられました。 そこをChatGPT使ってなんとかできないかと考えた次第です。
BDD的なプロセスを導入するために、試してみたこと
生成系AIユースケースを書いたら、Gherkin形式のテストシナリオが出来上がる仕組みを試作して、 その結果出来上がるテストケースが実際どの程度使えたか実例をご紹介します。
社内で利用できるChatGPTでどのような出力になるか試してみる
アイディアはChatGPTに壁打ちだったり、ふらっと試してみるに限るので試しました。 (当初コスト面からモデルは3.5Turboで実験しています) プロンプトや試した入力出力として以下を与えてみた結果いけそうな手応えがありました。
プロンプト
"prompt": "あなたはBehavior Driven Developmentの開発するチームを支援するアシスタントです。ユースケースを記載するのでBDDの文法で答えてください",
"temperature": 0.5,
"folderId": null
"id": "gpt-3.5-turbo",
- 確認したい仕様
- 該当ページはSP向けのWeb版のみに提供する
- 入力例
- PCから該当ページにアクセスした場合、該当ページには遷移せず、通常のページに飛ばされる
- 出力例
Feature: 該当ページにアクセス
Scenario: PCから該当ページににアクセスした場合、通常のPCページにリダイレクトされる
Given PCから該当ページににアクセスする
When 該当ページに遷移する
Then 通常のPCページにリダイレクトされる
コラボレーションするためにGoogleスプレッドシートからOpenAIで呼べるようにする
ChatbotのUIに対して都度ユーザーストーリーを書いていくのは、やり方としてあまり良く無いので Googleスプレッドシート上でGoogleAppsScriptによるカスタム関数を作ってOpenAIのAPIを実行させる様にしました。 但し利用規約でAPIキーの共有は利用規約違反に当たるのでAPIキーをオーナー以外が閲覧できない共同編集を実現する必要があります。 アドオン実装するまでもなく、手軽にスプレッドシートのメリットを享受するために、 アクセス権限が違うファイルを2個作ってOpenAPIへのアクセスをカプセル化するような仕組みで使用しました。 OpenAIのBestPractice記事
手順
APIキーの準備
- OpenAIのAPIキーを発行する。
スプレッドシートの作成と設定
- GAS実行用の「スプレッドシート1」を作成し、オーナー以外には閲覧権限のみを与える。
- 共同編集用の「スプレッドシート2」を作成する。
- 「スプレッドシート1」にAPIキーをスクリプトプロパティに埋め込み、カスタム関数を作成する。
列の準備とデータ入力
- 両スプレッドシートに列A（ユーザーストーリー記入用）と列B（Gherkinに変換用）を準備する。
- 「スプレッドシート2」の列Aにユーザーストーリーを手入力する。
データ関連付けと変換実行
- 「スプレッドシート1」の列Aで
importrange関数を用いて「スプレッドシート2」の列Aからデータを参照する。 - 「スプレッドシート1」の列BでGherkinの変換を実行するカスタム関数を使用する。
- 「スプレッドシート1」の列Aで
結果の共有
- 「スプレッドシート2」の列Bで
importrange関数を用いて「スプレッドシート1」の列Bから変換結果を参照する。
- 「スプレッドシート2」の列Bで
使ってみてスクリプトを調整する
あなたはBehavior Driven Development(略称BDD)での開発するチームを支援するアシスタントです。日本語でユースケースを記載するので、BDDの考え方に沿ってキーワードFeature, Scenario、Given、When、Thenを記載してください。Gherkinコードとして書いてください
以下は例です。
Feature: 日本語
Scenario: 日本語
Given 日本語
When 日本語
Then 日本語
先頭の行間隔を例として使用して、上記の例を正確に書いてください
実際継続的に業務で使っていけるかという観点で試算する
発生する経費について把握するのは業務で行う以上必須です。 こちらの試算は、tiktokenを使って試算したのですが、 今回の利用ケースだと以下の通り、１回の施策で$0.02(約3円)でまあまあ満足できる性能なので良さそう。 モデルによってはスクリプトの調整が必要となる為、GPT4-Turboでスクリプトをチューニングするとおそらく、もう少しかかる印象はあります。
gpt-3.5-turbo-1106 input:242, output: 191 prompt tokens counted by tiktoken. input cost: $0.000242, output cost: $0.000382, total cost: $0.000624 per 1 request 40 request cost is $0.02496 gpt-4-1106-preview input:242, output: 191 prompt tokens counted by tiktoken. input cost: $0.00242, output cost: $0.00573, total cost: $0.00815 per 1 request 40 request cost is $0.32599999999999996 gpt-4 input:242, output: 191 prompt tokens counted by tiktoken. input cost: $0.00726, output cost: $0.01146, total cost: $0.01872 per 1 request 40 request cost is $0.7488
実際にプロダクトのQAでどのように使ったか
- QAエンジニアが仕様文書からユーザーストーリー形式で受け入れ要件をNotion上に書き直して、PdM、エンジニアにレビューをしてもらいました。
- レビューしてもらったものを今回作ったスプレッドシートに適用します。
- 運悪く期間中に仕様変更がありましたが、仕様変更が発生したMTG中にシナリオを書き足して、項目化できました。
- 生成されたGherkin形式の記述毎に結果をつけるようなテストケースをスプレッドシート上に作成して実行しました。
今回得られた知見
- 会議中に項目化まで行なえた事は反響が大きかったです。
- スプレッドシートから呼ぶという方式にすることで簡単な前処理みたいな微調整が容易でした。
- QAエンジニアがしてみたいという内容の概念検証であれば、GPT3.5Turboでもサクッとできたが、項目自体の品質に対しては、人の目で見る必要がありました。
- 似た様な入力に対して、出力がブレるので、強制して矯正する必要がありました。
- モデルを変えてより性能をあげたいとなった時にプロンプトチューニングが必要な点に注意を要します。
方法論としての課題
- 「画面Aだけ例外的に特定のUIが表示される。画面A以外には特定のUIが表示されない。」という仕様に対して〇〇以外というのを明確に分解して指示する必要があります。これはスプレッドシート化したことで入力文を関数で文字列結合するなどで解決しました。
- ログインしているユーザー〜がというストーリーを書いた時に、ログインしていないユーザーが〜という逆のケースも書いてくれる場合がありましたが、書いてくれないこともあり、十分にコントロールができませんでした
- 使った感想としてはコンテキストを理解しているPdM、QAエンジニアがテストする分には問題ないレベルのものは作れます。
- この方式はあくまでユーザーストーリーを起こしたものなので、事前条件は自然言語で記載されていて、単純に１文で書かれているけれど、その状況を作るのが大変・・という課題はありますので、別の切り口からそのシナリオの状況を作る為の準備ステップについて別途明確化する様な必要があると感じました。
今後
ATDD(受け入れテスト駆動開発)のDSLの採用や、実例マッピング 等の要求定義段階での仕様への解像度を上げるプラクティスとの連動等を検討しています。
終わりに
ここまで読んでいただきありがとうございました。 くふうAIスタジオではエンジニアを募集中です。
- シフトレフトとは、開発の時系列を左から右に見立てて、左側からテストを行い品質を作り込む概念です。↩
- Behavior Driven Development. ビヘイビア駆動開発。ユーザーストーリーを基にステークホルダー,PdM,開発者,QAとで共通理解を促進する開発方法論。Gherkin言語のような自然言語に近いドメイン記述言語に基づいてテストを行います。↩
- Gherkin言語 : BDDのツールCucumberが提供するドメイン記述言語で、自然言語に 近い 形式でGiven（事前条件やコンテキスト）、When(特定のアクション)、Then(期待される結果、アウトカム)を中心に構成されます。↩
