生成AIを使った検証業務は、だいぶ便利になった。
仕様書や画面キャプチャをAIに読み込ませると、数秒でテスト項目書が作成される。しかも、ただ項目が並ぶだけではない。大項目、中項目、小項目に分類され、前提条件、操作手順、期待値まできれいに整理されている。
依頼の仕方によっては、その確認内容が仕様書のどこに記載されているのか、備考欄に参照元まで入れてくれる。
これは本当に便利だと思う。
昔なら、仕様書を読み、画面設計書を確認し、項目を洗い出し、観点を整理し、Excelの形に整えるだけでもかなり時間がかかった。レビューに出せる形にするには、さらに体裁も整えなければならない。
それが、AIを使えば数秒で出てくる。
見た目もきれいだ。
項目数もそれなりにある。
分類もされている。
手順と期待値も書かれている。
納品物として見た場合、かなり優秀に見える。
しかし、ここに罠がある。
テスト項目書として見た目が整っていることと、そのテスト項目書で品質を保証できることは、まったく別の話だからだ。
仕様書にない項目が紛れてくる
AIが作成したテスト項目書を確認していると、いくつか気になることがある。
まず、仕様書に記載されていない内容が、普通にテストケース化されていることがある。
AIは、入力された仕様書をもとに作成しているように見える。けれど、実際には仕様書に明記されていない内容についても、一般的なシステムの動きや、よくある画面仕様をもとに、それらしい確認項目を作ることがある。
たとえば、登録画面があれば、登録後に一覧へ反映される確認を入れる。
入力欄があれば、未入力時のバリデーションを入れる。
ステータス変更がありそうなら、変更後の表示確認を入れる。
場合によっては、APIの返り値やDB登録の確認まで項目に入っていることもある。
もちろん、それが正しい場合もある。むしろ、経験のあるテスターが作るような観点を先回りして出してくれることもあるので、たたき台としてはかなり助かる。
ただし、問題は外れたときだ。
テストケースには「登録後、ステータスが更新されていることを確認する」と書かれている。ところが、実際の画面を触ると、そもそもステータスを確認する画面がない。
「確認ダイアログが表示されること」と書いてあるが、実装では確認ダイアログは出ない。
「DBに登録されていること」と書かれているが、テスト実施者にはDBを確認する権限がない。
「APIの返り値を確認する」と書かれているが、今回の受入テストではそこまで確認しない。
こうなると、実施者は困る。
これはテストケースが間違っているのか。
それとも実装が間違っているのか。
仕様書が古いのか。
今回の確認範囲ではないのか。
そもそも誰に聞けばいいのか。
判断ができない。
結果として、テスト項目書をもとにテストを進めるはずが、質問ばかりが増えていく。
「この項目は実施対象ですか」
「このボタンが画面上にありません」
「仕様書ではAですが、実装ではBになっています」
「DB確認とありますが、こちらで確認できる環境はありますか」
「API確認は単体テスト側で確認済みという認識でよいですか」
AIが作ったテストケースによって、逆に現場の確認事項が増える。そして、テストがなかなか進まなくなる。
不足を聞けば、不足が出てくる
もうひとつ怖いのは、AIに再確認させると、たいてい不足が出てくることだ。
最初にAIへ仕様書を読み込ませて、テスト項目書を作成させる。出力された内容を見ると、それなりに整っている。項目も多い。一見すると、十分に確認できそうに見える。
ところが、そのあとにこう聞く。
「このテスト項目書に不足している観点はありませんか」
すると、かなりの確率で不足観点が出てくる。
権限別の確認が不足しています。
異常系の確認が不足しています。
登録後の一覧反映が不足しています。
編集後の再表示確認が不足しています。
画面遷移後の戻る操作が不足しています。
境界値の確認が不足しています。
さっき完成したような顔をして出してきたはずなのに、聞けば不足が出てくる。
これは、AIが悪いというより、AIで作成したテスト項目書を「完成品」として扱うことが危ういという話だと思う。
AIの出力は、たたき台としてはかなり優秀だ。しかし、そのまま品質保証の成果物として使えるかというと、そこにはまだ大きな隔たりがある。どんな観点が抜けやすいかは、テストパターン集で体系的に確認できる。
特に単体テストの網羅性や、異常系の深さ、権限による表示差分、データ状態による挙動の違いなどは、AIがきれいに拾ってくれるとは限らない。
AIはきれいな表を作る。でも、きれいな表であることと、抜けがないことは違う。ここを勘違いすると危ない。
渡したドキュメントが正しいとは限らない
そもそも、AIに読み込ませているドキュメント自体は正しいのだろうか。
要件定義の覚書。画面設計書。機能仕様書。画面キャプチャ。
これらをAIにインプットすれば、AIはその資料を前提にテスト項目書を作成する。
しかし、現場では要件定義から仕様が変わることなど日常茶飯事だ。
最初はAという仕様だった。途中でBに変更された。開発都合でCになった。リリース直前にDへ調整された。
では、その変更はすべて設計書に反映されているのだろうか。
おそらく、そうではない。
Slackには残っている。BacklogやJiraのコメントには書かれている。会議では決まっている。口頭では共有されている。開発者の頭の中にはある。
しかし、画面設計書には反映されていない。要件定義書は古いまま。仕様書の一部だけが更新され、別の資料とは食い違っている。
こういうことは、普通に起きる。
その状態で、古い仕様書や一部だけ更新された画面設計書をAIに読み込ませるとどうなるか。
AIは、その資料を正しいものとして扱う。
「この資料は古い可能性があります」「現在の実装と差分があるかもしれません」「仕様変更後の内容が反映されているか確認してください」——と、気を利かせて言ってくれるわけではない。
もちろん、そう聞けば答えるかもしれない。しかし、聞かれていなければ、AIは渡された資料を前提に、それらしいテスト項目書を作成する。
つまり、インプットした資料の時点ですでに現場と差分が生じている場合、その差分を含んだまま、きれいな試験書ができあがる。
見た目は整っている。項目もある。参照元も書いてある。でも、前提としている仕様が古い。
そうなると、テストケースの正しさ以前に、テストケースが見ている世界そのものが現場とズレていることになる。
見た目の違和感は拾えない
さらに、AIは見た目の違和感を拾うのが苦手だ。
仕様書に書かれている内容をもとに、入力、登録、更新、削除、検索、一覧反映、エラーメッセージ表示などの確認を作ることはできる。これはかなり得意な部類だと思う。
しかし、実際の検証では、それだけでは足りない。
たとえば、iPhoneの独自フッターによって画面下部のボタンが隠れる。ネイティブアプリのサイドメニューを開いたときに、画面全体のUIが勝手に圧縮される。Androidでは問題ないのに、iOSだけ余白が崩れる。PCではきれいに見えるのに、スマホではボタンが下に落ちる。長い名前を入力すると、カードの高さが崩れる。エラーメッセージが表示された瞬間、入力欄が押し出される。固定ヘッダーとモーダルが重なって、閉じるボタンが押せない。
こういう不具合は、仕様書には書かれていない。でも、ユーザーは普通に気づく。そして、品質としてはかなり重要だったりする。
AIが作るテスト項目書は、どうしても「仕様書に書かれている内容」に寄りやすい。もちろん、指示の仕方によっては、UI崩れやレスポンシブ確認などの観点を追加することもできる。
ただ、それでも実際に画面を触っているときの違和感や、この端末だと崩れそうだという勘所までは、なかなか拾えない。
ここは、経験のあるテスターが強い部分だと思う。
仕様書に書いてあるから確認するのではなく、書いていないけれど当然確認したほうがいいことを見つける。
この導線なら、戻る操作を見たほうがいい。
この画面なら、長い文字列を入れたほうがいい。
このボタン配置なら、スマホで押しづらいかもしれない。
この一覧なら、0件、1件、大量件数を見たほうがいい。
この権限なら、表示されてはいけない情報が出るかもしれない。
こういう「べき論」の確認は、仕様書だけからは出てこない。そして、品質保証ではこの部分がかなり重要になる。
AIが作ったものを検証できる人が強い
結局、AIでテスト項目書を作ること自体は、もうかなり現実的になっている。
仕様書を入れれば、きれいなテストケースができる。画面キャプチャを入れれば、画面項目に沿った確認も作れる。要約された設計書もできる。参照元付きの試験書もできる。
そこだけ見れば、検証業務はかなり楽になったように見える。
しかし、実際の品質管理として考えると、話はそこまで単純ではない。
仕様書が古いことがある。仕様変更がドキュメントに反映されていないことがある。AIが勝手に補完した観点が混ざることがある。実施できない確認がテストケースに入ることがある。逆に、肝心な確認が抜けていることもある。見た目の崩れや使いづらさのような、現物を触らないと気づけない問題もある。
つまり、AIが作ったテスト項目書は、きれいではある。しかし、きれいなテスト項目書があるからといって、品質が担保されるわけではない。
ここを間違えると、現場はかなり混乱すると思う。
これから活躍するのは、AIにテスト項目書を作らせられる人ではないかもしれない。それは、おそらく誰でもできるようになる。
仕様書を入れる。テスト観点を出してもらう。Excel形式にしてもらう。大項目、中項目、小項目に分けてもらう。期待値を書いてもらう。
この作業自体の価値は、どんどん下がっていくと思う。
むしろ重要になるのは、AIが作ったテスト項目書を見て、違和感に気づける人だ。
この項目は今回の試験範囲ではない。
この確認は実施者にはできない。
この仕様は今の画面と違う。
この観点は単体テスト側で見るべきだ。
この異常系が抜けている。
この導線はユーザーが詰まりそうだ。
この端末では表示が崩れるかもしれない。
この仕様変更は横展開されていないかもしれない。
そういう判断ができる人だ。
言い換えると、きれいな試験書を作れる人ではなく、雑な試験書でも腹案を持って実施できるテスターが強くなるのではないかと思う。
テストケースに書かれていることだけを確認するのではなく、実際に触りながら、「このパターンはどうだろう」「この条件だと壊れそうだ」「この操作はユーザーがやりそうだ」「ここは仕様書にないけど、確認したほうがいい」と考えられる人。
AIが作ったものをそのまま信じるのではなく、AIが作ったものを検証できる人。
今は、AIでテスト項目書を作れること自体が注目されている。でも、おそらく生成AIブームが少し落ち着いたあとに見えてくるのは、そこではないと思う。
AIで作った試験書をどう使うか。AIの出力をどこまで信じるか。どこから先を人間が見るべきか。
この整理ができていない現場では、きれいな試験書だけが増えて、実施者の質問も増え、肝心な品質確認は抜けていく。
AIは便利だ。テスト項目書の作成も、設計書の要約も、観点の洗い出しも、確実に楽になる。
ただし、品質はAIが保証してくれるわけではない。
テスト項目書を作ることと、品質を保証することは違う。
そして、その違いに気づける人が、これからの検証業務では一番必要になるのだと思う。バグかどうか判断に迷う場面では、バグ判定AIツール「これってバグなの？」が手元の判断をサポートしてくれる。