Geminiと一緒にテスト観点表を作ってみた話

テスト観点表について

簡単に説明すると、ソフトウェアテストに必要な観点を一覧で示したもののことです。
テスト観点表には、観点の分類、確認する具体的な内容、期待値などが一覧形式で記載されています。

【Geminiが最初に作ってくれたテスト観点表】

【完成版のテスト観点表（一部のみ表示）】

ここから担当する案件のテスト（システムまたは機能のUAT）で必要な観点を取捨選択し、テスト概要やテストケースを作成していくことで、必要な観点がテストから漏れるのを防ぐことができます。

実際の作成手順

では、実際に行ったテスト観点表の作成手順を説明していきます。
まずはテスト観点表づくりに必要なものを準備します。

必要なもの

• 作成者（経験とスキルのあるテストエンジニア）
• Gemini（または使用可能な生成AI）
• レビュアー（経験とスキルのあるテストエンジニア、テストチームのリーダー）

Geminiにおまかせするだけだったり、作成者が単独で作成した場合、観点に漏れや偏りが出る可能性が高くなります。
レビュアーは1人以上いると安心です。経験値の高い有識者だとなおよし。

プロンプトの実行と作成

Geminiで1つ目のプロンプトを実行します。

あなたはJSTQB FLレベルのQAエンジニアです。
ソフトウェアテスト（UAT）において、標準的な観点を網羅したテスト観点表を作成してください

これだけでもテスト観点表を作ってくれますが……、おそらく実運用するには色々足りてないものができると思います。
というわけで、何度かプロンプトを実行して観点を追加していきます。

	プロンプト	リプライ後にやった作業	所要時間の目安
1	あなたはJSTQB FLレベルのQAエンジニアです。ソフトウェアテスト（UAT）において、標準的な観点を網羅したテスト観点表を作成してください	返答内容の表をスプレッドシートにコピペして、内容を吟味	1分以内
2	UIの表示周りの観点、入力のバリデーションをもっと具体的に盛り込んで	内容を確認する	10秒以内
3	最初の回答と2つ目の回答を合わせた表を作成して	改めてスプレッドシートにコピペする	10秒以内
4	入力バリデーションの「データ型検証」「桁数・範囲検証」の観点について、より具体的で詳しい表を作成してください	足りない観点がないか点検→プロンプトの結果をコピペ→正しい位置に適切な書式に整えて配置	5分くらい
5	1. ビジネス要件適合性　の「業務フローの検証」の観点について、より具体的で詳しい表を作成してください	※上記と同じ流れ※	5分くらい
6	※上記と同じく観点追加（複数回）※	※上記と同じ流れ※	5分くらい
7	排他制御（同時操作が行われた場合にデータの競合を避ける処理）の観点を適切な位置に追加できるよう、具体的で詳しい表を作成してください	※上記と同じ流れ※	5分くらい
8	※上記と同じく観点追加（複数回）※	※上記と同じ流れ※	5分くらい

実際には17回ほどラリーを繰り返し、たたき台としてのテスト観点表が出来上がりました。
かかった工数は計4時間前後（間に別の作業が入ったりしているため）。13時ごろから始めて、15時ごろにほぼ完成しています。そこからさらに観点追加などの細かい修正作業を追加して、17時に第1版が完成です。

こちらで記載している工数は今回実際にかかった工数であり、作成したいテスト観点表の内容などによって大きく変動する場合があります。必ず同じ結果になるようなものではありませんので、あくまでも参考値としてお考えください

長い！！と感じる方もいるかもしれませんが、本来なら「テスト観点表　UAT」とかググって、コピペしたり手書きしたりして、さらに必要な観点をググっては追加して……、生成AI登場以前の作業工数を思えば、かなり速いです。Geminiなしだと2営業日（16時間）は必要になるはずです。
独力では完成度も怪しくなりがちですが、Geminiがあちこちから知識をとってきてくれるので、この点もかなり心強く感じました。

チーム内レビューと修正

第1版と呼べるものが出来上がっても、まだ終わりではありません。チームで運用できるように最適化するため、レビューと修正をやります。

具体的には以下の作業を行いました。

• 作成された観点の中で被っているものを削除、あるいは整理して統合
• 次のステップで使いやすいように用語を選定しなおす
• チームで話し合いながら内容をブラッシュアップする(=文章を分かりやすいように修正したり、テスト観点の記載順を実際のテストに合わせて調整したり、観点をさらに追加したり)

Geminiとラリーで観点を追加した結果、複数の箇所で観点被りがありました。
また、あれだけプロンプトを繰り返してもなお、漏れている観点がレビュー中に複数見つかりました。
イケてない（＝何を言っているのか一目ではわからない）分類や観点名もいくつかあり、ああだこうだと議論しながらメンバーが直感的に分かる名称に修正したり、観点の説明をまとめ直したりする部分もありました。

次のステップのためにやること

いくつかの工程を経てテスト観点表が出来上がりましたが、次に何をするべきなのか？
具体的な作業として、以下が想定されます。

• 実際のテスト設計でテスト観点表を運用する（必要な観点に〇を付ける）
• テスト観点表を基にテストマップを作る¹
• テスト観点表・テストマップを基に、具体的なテストケースを作成する

うちのチームではテスト設計の対象となるものが複数あるのが常で、かつ、もともとテスト観点表を使っていなかったので、ここで1つ懸念事項がありました。

「ただでさえ忙しいのに、余計な手間が増えた」

せっかく作成したテスト観点表が活用されなかったら？

Gemで手間を減らしましょう！

あなたはJSTQB FLレベルのQAエンジニアです。
知識に置かれたテスト観点表に従い、プロンプトとして添付されたファイルの内容を確認し、〇付けを行います。

ルール：
1.テスト観点表は知識として置かれたものをそのまま使用する。
2.必要な観点には〇、不要な観点には―を入力し、それ以外の行為は行わない。
3.結果は知識のテスト観点表と同じ、スプレッドシートの形で出力する。

Gemの「カスタム指示」に上記の内容を記載し、「知識」として完成版のテスト観点表を置きます。
名前と説明を任意で記載して保存すれば、添付ファイルとして案件の資料を置くだけで、必要な観点に自動で〇を付けてくれます。
あとはその内容が妥当かどうかを確認し、次のステップへと進めます。

将来的には、テストマップも自動で作成できるようにしたいなと思いつつ、Gemだと安定した品質でのテストマップ生成が困難だったので……、何かの手段でできるようになったらまた報告させていただきます。

1. テスト対象の機能とテストに必要な観点を俯瞰図にしたもの。詳しくは画像検索を推奨 ↩