テスト自動化を検討する際の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の重要性が低いなら、メンテナンスがあまり発生しないためデメリットは小さくなるだろう。
