生成AIに仕様を入力して、
「この機能のテスト観点を出してください」
と聞くと、かなり簡単にそれらしい回答を出してくれます。
正常系、異常系、境界値、エラー処理、権限、性能など、短時間で多くの観点を挙げてくれるので、テスト設計のたたき台としてはかなり便利です。
自分も、生成AIはテスト業務と相性がよいと感じています。
ただし、実際に使うときには一つ注意したいことがあります。
AIが出したテスト観点を、そのまま正しいものとして使わないこと
です。
今回は、生成AIにテスト観点を出してもらうときに、どこを確認すればよいのかを整理してみます。
AIは「それらしい観点」を出すのが得意
生成AIに仕様を渡すと、かなり幅広くテスト観点を出してくれます。
例えばログイン機能であれば、
-
正しいIDとパスワードでログインできる
-
間違ったパスワードではログインできない
-
未入力時にエラーになる
-
文字数の上限・下限
-
アカウントロック
-
セッション管理
-
権限
-
セキュリティ
といった内容がすぐに出てきます。
ゼロから自分で考えるより、最初の候補を出してもらう用途ではかなり便利です。
ただ、ここで注意したいのは、
観点が多いことと、必要な観点がそろっていることは別
という点です。
観点が抜けていないか確認する
AIは一般的な観点を広く挙げるのは得意ですが、そのシステム固有の重要な条件まで理解しているとは限りません。
例えば、
「この機能は特定の装置との通信状態によって動作が変わる」
「既存バージョンとの互換性が重要」
「特定の設定変更後だけ問題が起きやすい」
といった背景は、仕様書だけでは分からないことがあります。
実務では、こうしたシステム固有の事情が重要になることがあります。
そのため、AIが出した結果を見たあとに、
「この製品だからこそ必要な観点が入っているか」
を確認する必要があります。
逆に、不要な観点が入っていることもある
生成AIは多くの候補を出してくれるため、一見すると網羅的に見えます。
ただし、実際には、
「このシステムでは存在しない条件」
「仕様上あり得ない操作」
「優先度がかなり低いケース」
まで含まれていることがあります。
AIが20個の観点を出したからといって、その20個を全部テストする必要があるわけではありません。
テストには時間も工数も限りがあります。
そのため、
本当に必要なテストなのか
リスクに対して優先順位は適切か
を人が判断する必要があります。
重複している観点がないか確認する
生成AIに何度か観点を出してもらうと、似たような内容が別の表現で並ぶことがあります。
例えば、
-
入力値が上限を超えた場合
-
最大文字数を超えた場合
-
許容文字数を超えた場合
など、実質的に同じ内容が複数出ることがあります。
項目数が多いと安心してしまいますが、数が多いこと自体には意味がありません。
むしろ、
同じ目的のテストが重複していないか
を整理して、必要な観点にまとめることが重要です。
「なぜその観点が必要なのか」を確認する
AIが出したテスト観点を見たとき、自分なら、
「なぜこのテストが必要なのか」
を考えるようにします。
理由が説明できない観点は、もう一度確認したほうがよいと思います。
例えばAIに、
このテスト観点を確認する目的と、確認しなかった場合のリスクを説明してください。
と聞いてみてもよいです。
目的とリスクが分かると、
「これは優先度が高い」
「これは今回の変更では不要」
と判断しやすくなります。
仕様だけではなく、変更内容も伝える
生成AIを使うとき、単純に仕様を渡すだけではなく、
今回どこを変更したのか
も伝えたほうが使いやすいと思います。
例えば、
この機能のテスト観点を出してください。
だけではなく、
今回、認証方式を変更しました。
既存機能への影響も含めて、重点的に確認すべきテスト観点を出してください。
というように聞きます。
そうすると、単なる機能テストではなく、変更による影響も意識した回答が出やすくなります。
実務では、新規機能だけでなく、
変更によって既存部分に何が起きるか
を見ることも重要です。
前提条件をできるだけ伝える
AIの回答品質は、与える情報によってかなり変わります。
例えば、
-
対象システム
-
今回の変更内容
-
想定ユーザー
-
制約条件
-
重要な機能
-
過去に問題が起きた部分
-
特に確認したいリスク
などを伝えると、一般論だけではない回答になりやすくなります。
逆に、情報が少なければ、AIも一般的な回答しか出せません。
これは人にテスト設計を依頼する場合でも同じだと思います。
AIに「抜け」を確認させる使い方もできる
自分で作ったテスト観点をAIに渡して、
以下のテスト観点について、抜けている可能性がある観点を指摘してください。
と聞く方法もあります。
AIに最初からすべて作らせるのではなく、
自分が考えた観点のレビュー役として使う
方法です。
個人的には、この使い方はかなり相性がよいと思います。
人が考えた内容をAIに確認させることで、
「自分では気づかなかった視点」
が出てくることがあります。
もちろん、追加された観点が本当に必要かどうかは、最後に人が判断します。
一度で完成させようとしない
生成AIを使うときに、
「完璧なテスト観点を一回で出してもらおう」
と考える必要はないと思います。
まず大きな観点を出してもらう。
その中から重要なものを選ぶ。
選んだ観点について、さらに具体化する。
最後に抜けがないか確認する。
というように、何回かに分けて使うほうが整理しやすいです。
例えば、
まず大きなテスト観点だけを10個以内で出してください。
と聞いたあと、
その中の「エラー処理」について、詳細な観点を出してください。
という流れです。
最初から大量のテストケースを作らせるより、段階的に考えたほうが内容を確認しやすくなります。
機密情報は入力しない
実務で生成AIを使う場合は、もう一つ重要な点があります。
社外秘の仕様や顧客情報などを、そのまま入力しないこと
です。
利用している生成AIサービスや、会社のルールによって扱いは異なります。
業務で使用する場合は、必ず社内のルールや利用可能な環境を確認する必要があります。
テストを効率化するためにAIを使っても、情報管理上の問題を起こしてしまっては意味がありません。
自分ならこんな流れで使う
テスト観点を生成AIで考える場合、自分なら次のような流れで使います。
-
対象機能と変更内容を整理する
-
AIに大きなテスト観点を出してもらう
-
不要な観点を削る
-
システム固有の観点を追加する
-
重要な観点を詳細化する
-
AIに抜けがないかレビューさせる
-
最後に人が確認する
ポイントは、
AIに最終判断を任せないこと
です。
AIは観点を広げたり、別の視点を出したりするのには便利ですが、
「この製品で本当に重要なのは何か」
を判断するのは、まだ人の役割だと思います。
AIはテスト設計の「代わり」ではなく「補助」として使う
生成AIを使うと、テスト観点を考えるスピードはかなり上げられます。
特に、
-
最初のたたき台を作る
-
別の視点を追加する
-
自分の観点をレビューする
-
観点を整理する
といった使い方は便利です。
一方で、
AIが出したものをそのままテスト仕様にする
という使い方には注意が必要です。
前の記事でも書きましたが、AIの回答を評価するためには、やはりテストの基礎知識が必要になります。
AIを使うことでテストエンジニアの仕事がなくなるというより、
AIを使いながら、どこを確認すべきか判断する力がより重要になる
のではないかと考えています。
生成AIは、テスト設計を全部任せる相手ではなく、
一緒に観点を広げるための補助役
くらいに考えるのが、今のところ一番使いやすいと思います。
次回は、この流れをもう少し実践的にして、
「生成AIにテスト観点を出してもらうプロンプトの作り方」
についてまとめてみたいと思います。
