こんにちは、kickflow QAチームのNです。
kickflowのQAでは、機能変更ごとに用意したテストケースを、QAチームが内製したテスト管理ツール「KickRail」で管理しています。
KickRailを作った背景や仕組みについては、以前の記事「テスト管理ツール「KickRail」を内製した話」で詳しく紹介しています。
最近は、実行条件が整ったテストケースの一部をAIに実行してもらっています。
私たちはこの取り組みを「AI実行」と呼んでいます。
この記事では、AI実行で何をしているのかと、AIの結果をQA担当が使える形にするための工夫を簡単に紹介します。
AI実行とは
ここでいうAI実行は、決まった手順を繰り返す自動テストとは少し違います。
機能変更ごとに用意した日本語の手動テストケースをAIが読み、内容に合わせて操作や確認を進めます。
自動テストを置き換えるのではなく、これまで人が行っていた手動テストの一部をAIに任せる取り組みです。
流れは次のとおりです。
- AIが対象の変更とテスト環境を確認する
- AIが必要なテストデータやユーザーを準備する
- AIがケースに沿って画面やAPIを操作する
- AIが仮の判定とスクリーンショットなどの根拠をKickRailへ残す
- QA担当が仮の判定と根拠を確認し、最終結果を決める
AIが残す仮の判定は、人が決める最終結果とは別に保存します。
最終結果の確定と機能全体のQA完了は、QA担当が行います。
KickRailでは、AIによる仮の判定、期待した挙動、実際に確認した挙動、スクリーンショットをまとめて確認できます。
この一連の作業は、AIに作業手順や判断基準を伝える「スキル」として管理しています。
一つの大きな指示書にはせず、役割ごとに三つへ分けました。
| 工程 | スキルの役割 |
|---|---|
| 仕分け | ケースと仕様を読み、実行対象、必要な権限、必要な根拠を決める |
| 準備 | テストデータと実行ユーザーを用意する |
| 実行 | ブラウザやAPIを操作し、結果と根拠をKickRailへ保存する |
全体を管理するスキルが、この三つを順番に呼び出します。
QAが最初からやり直さなくていい結果を残す
AIが「Pass」と答えても、QA担当が「本当に？」と思ったら、結局同じテストを最初からやり直すことになります。
これでは、AIに任せても人の仕事は減りません。
そのため、Passには、人が見て納得できる根拠を必ず残します。
たとえば一覧の絞り込みなら、操作後の画面だけではなく、「2件あったものが1件になった」と分かるところまで確認します。
一方で、ログイン切れやテストデータ不足で操作できなかったケースは、プロダクトの不具合と同じFailにはしません。
準備を整えてから実行し直すか、判断できなかった理由を添えて人へ戻します。
AIに判定させることよりも、QA担当が同じテストをやり直さず、その場で最終判断できること。
AI実行では、ここを一番大事にしています。
まとめ
kickflowのQAチームでは、KickRailに登録された機能変更ごとのテストケースをAIが実行し、結果と根拠を残す取り組みを進めています。
ポイントは、AIにテストを丸ごと任せることではありません。
- AIが実行条件と必要なデータを確認する
- AIが画面やAPIを操作し、結果と根拠を記録する
- 判断できないものは人へ戻す
- 最終結果はQA担当が決める
AIが準備、操作、記録を進め、人が結果の確認と最終判断に集中できる形を目指しています。
次の記事からは、AI実行をもう少し深掘りします。
同じテストケースを複数のAIで実行するとどんな違いが出るのか、AIの結果を別のAIでチェックできるのか、判定ミスをどう残して改善につなげるのかを紹介していく予定です。
kickflowでは、一緒にプロダクトを作ってくれる仲間を募集しています。
興味を持っていただけた方は、ぜひ採用サイトをご覧ください。
