テスト自動化を検討する際の3つの分岐点
生成AIが登場し、自動テストが着実に普及してきた。自動テストと手動テストのバランスについての最適解を導くにはどうしたらいいかと多くの開発現場で議論になっていることだろう。本稿でもそれがテーマではあるが、GENZ 竹花和裕氏は「最初に結論から言いますが、自動・手動の最適バランスは残念ながらありません」と言い切る。
とはいえ、ここで終了ではない。ここでは最適バランスをとるためのポイントについて深掘りしていこう。自動化を検討する際の分岐点となるのが「単体テスト vs システムテスト」「手動テスト vs 自動テスト」「人 vs AI」の3つだ。
自動化が有効なのはどんな場合？ 単体テストとシステムテストの違いから考える
近年ではテスト駆動開発や開発フレームワークの進化で単体テストの自動化が進んでいる。テストにかかるコスト削減のために自動化したいという要望がありつつも、E2Eのシステムテストにおいては、まだ手動が多いのが実情だ。
その理由は、自動化してもなおコストがかかることが挙げられる。例えばUIを操作するために（単体に比べると）時間がかかる。またネットワークを経由するため、タイムアウトエラーなどテストが安定しないこともある。バグが発生するとデバッグに時間がかかる、UIの変更に弱い、テストコード自体に不具合が混入してしまう可能性もある。
ここで竹花氏は「システムテストの自動化では、3回以上同じテストを繰り返すなら有効」と目安を示す。逆に言えば3回未満であれば自動テストの構築コストやメンテナンスコストで赤字になる可能性もある。そのため「自動テストはなるべく単体テストで行うのが望ましい。もしシステムテストを自動化するなら、システムテストでなければならない箇所に絞る」と竹花氏。
とはいえ「単体テスト」の範囲をどうとらえるか。組織や担当者により、ポリシーや解釈が異なるところだ。その点、竹花氏は「システムをどこまで見るかというレンジの問題もありますが、単体テスト・結合テストだと認識がふわっとしていますので定量的に測れるテストサイズで考えるのがおすすめです」と話す。テストサイズというのはGoogle社内から広まった自動テストにおける分類手法で、Small、Medium、Large、Enormousで分類する。
Smallとは単一のプロセスで実行できるものを対象とする。そのためファイルシステムや外部リソースは使わない。テスト実行時間は最長で1分以内を目安とする（目標は1ms未満）。Mediumはローカル環境で実行できるものを対象とする。コンテナを利用した場合はローカルとなるので、外部リソースも許容する。テスト実行時間は最長で5分以内とする（目標は1秒未満）。これ以上のものはLarge以上と考える。
Smallだとテスト時間が短く、手軽であることがメリットだが、一方で本番環境までが遠いというデメリットがある。単一プロセスのため、外部リソースとの間の部分はモックなど、本番とは異なる環境でテストすることになる。すると、本番で不具合が出てしまうリスクもある。逆にLargeになると本番環境に近くなるが、テスト時間がかかることや手間がかかることになる。
あらためて自動化のポイントとして竹花氏は「なるべく単体テストを自動化するのが理想」と言う。テスト実行が安定し、コーディング後にすぐテストできて、結果もすぐ分かるので開発のしやすさにもつながる。ただしレガシーシステムでは言語やフレームワークの問題でテストが組み込めない、あるいは組み込んだら問題が起きる可能性もあるので、そういう場合は無理して組み込まないほうがいいだろう。
またシステムテストだとメンテナンスに時間がかかるのがデメリットだと述べたが、UIの変更がない、またはUXの重要性が低いなら、メンテナンスがあまり発生しないためデメリットは小さくなるだろう。
残念な自動テスト「あるある」から見えること
今度は手動テストと自動テストの比較をしていこう。自動テストのメリットは人間ではないので疲労がなく、夜間や休日でも、指示通りにテストを実施できるのがメリットだ。
裏返すと、指示がないと自動テストは実施できない。そのためテストの仕様や期待値が明確でないと指示ができないため、自動テストをコード化できないことになる。また人間なら仕様が変更されたら気を利かせて柔軟に対応できるかもしれないが、自動テストではそうはいかない。
さらに自動テストのバッチ処理では不具合があると、そこで止まってしまうことがある。竹花氏は自身の体験として「テストを大量に実施したいので、自動テストをセットしてから退社した。翌朝出勤するころにはテストが終わっていると思いきや、ログを見ると開始直後にエラーで止まっていてがっかりしたことがある」と話していた。あるあるではないだろうか。
人間ではなく機械なので当然ではあるが、自動テストではテスト箇所しか見ない。人間ならテストを実施する過程で、テスト対象ではないデザインやレスポンスの問題に気づくことができる。例えばスクロールがカクついたとか、使いにくさなどだ。
柔軟性に欠けるという点では、他にもある。スケジュールが押し迫っている時に人間なら目的や優先度に応じて取捨選択ができるが、自動テストでは人間のような臨機応変さはない。
こうした点を踏まえて、自動テストに全振りしようとしてもテスト漏れのリスクや柔軟性に欠ける部分もあるため難しいという判断になる。加えて自動テストを構築するコストや自動テストそのものに不具合が混入する可能性も考慮しておく必要がある。
とはいえ全部手動もよくない。竹花氏は「効率を高めるための自動化であることを忘れず、どこを手動で、どこを自動でテストするかを事前に決めておくといいでしょう。小さな自動化でも役に立ちますので、まずはミニマムなところから自動化をはじめるといいと思います」と話す。
生成AIでテストはどこまで自動化できるのか
言うまでもないが、近年のAI進化は著しい。生成AIといえばOpenAIのChatGPTの知名度が高いが、コードを扱うならAnthropicのClaudeも定評がある。
竹花氏はサンプルとして自社サイト「G-SAT（自動化ソリューション）」を対象に自動テストのためのPythonコードを生成AIに書かせてみた。竹花氏は「雑な指示でもいいテストを書いてくれたものの、品質担保に十分かというと疑問が残ります」と話す。
ソフトウェアテストで大事なことは（正確にはテスト分析やテスト設計と呼ばれる部分になるが、ここでは割愛）、いきなりテストを書くのではなく、何のためのテストか、どうやってテストするかを事前にきちんと検討するプロセスを踏むことだ。
そこでChatGPTに「テストの観点を教えて」と質問すると、UIテストでは「レスポンシブデザイン：各デバイスでレイアウトや表示が正常か」「リンクやボタンの動作：各ボタンが正しく機能し、ページ遷移が正常か」、機能テストでは「お問い合わせフォーム：フォームが送信でき、入力エラーの処理が正常か」、セキュリティテストでは「SSL証明書の確認：HTTP接続の設定が正常か」と回答できた。
そのまま「テスト設計をして」と依頼すると「テストケース1：各ページやセクションの表示確認。期待結果：画像やテキスト、ボタンが正しい位置に配置されている」などと回答した。さらに「テストケース（テスト計画）を書いて」と頼むと目的・手順・期待結果をきれいにまとめてくれた。今の生成AIはここまでできる実力を備えてきている。
竹花氏としては「これは僕らテストエンジニアが要らなくなるのではと震えるところですが、ただし十分かどうかの判断が必要です」と話す。正答を知る竹花氏だからこそ生成AIのアウトプットが正しいと判断できたものの、生成AIの提案が正しいか判断する必要があるということだ。また、いくら正しくてもスケジュールに制限があるなら、優先度の判断も必要になる。これはローコードやノーコードのサービスでも同様だ。AIであればハルシネーションのリスクも考慮しておく必要がある。
そのためテストでAIを使うのであれば「ブレストのように、アイデアの土台としてリストアップしてもらう。あるいは壁打ちのように、人間が考えた内容に対してフィードバックをもらうような使い方がいいのではないか」と竹花氏は言う。
最後に竹花氏はハサミとカッターに例えて次のように述べた。「目的は同じですが、状況により使い方は異なります。また安全性の観点もあります。カッターのほうが使いやすい状況でも、小さな子どもが使うならハサミを使わせることがあります。自動テストも同様で、状況に合わせて積み上げていくことがいいでしょう」
