Coding Agent時代のテスト実装で、シフトレフトの発想が効く話

はじめに

Coding Agentを使って自動テストを書いたことがある、あるいはこれから書こうとしている人は多いと思います。
実際、テストの実装そのものはかなりAIに任せられるようになってきました。

ただ、そこで一つ悩ましいのが、テストの品質判断に必要なドメイン知識を、いつ自分の頭に入れるのかという問題です。
AIが設計から実装まで進められるようになっても、「何が正しいテストなのか」を判断するのは人間です。従来は作業の中で自然に得られていたその理解を、どこで作るのかを考える必要があります。

私は、この判断に必要な理解は、なるべく前倒しで作っておいた方がよいと考えています。従来の自動テストと、Coding Agentを前提にした自動テストでは、人間が対象機能を理解するタイミングが変わるからです。

従来の自動テストでは、作業の中で理解が深まっていた

自動テストは、ざっくり言うと次のような流れで作ることが多いと思います。

1. テスト観点を設定する
2. 観点に合わせて前提条件と期待結果を作る
3. 前提条件から期待結果に至る手順を設計する
4. 期待結果に合わせて検証を設計する
5. テストを実装する

何を確認したいかを決め、それに合わせて手順と検証を組み立て、最後にコードに落とす流れです。
従来の自動テストでは、この過程を人間が自分で進めるので、観点を考え、手順を組み立てる中で、自然とテスト対象への理解が深まり、ドメイン知識が蓄積されます。

一方で、Coding Agentを使う場合、この一連の流れのかなりの部分をAIに任せられます。
しかし、最終的にその成果物が妥当かどうかを判断するのは人間です。
ここで問題になるのが、人手での作業では自然に得られていたドメイン知識を、どこで獲得するのかということです。

AIにテスト観点の設計から実装、レビューまで一気に進めさせて、その横で人間が並走しながら理解を深め、気になるところで止めて修正する、というやり方もできなくはありません。
ただ、自分の感覚ではこれはあまり効率がよくありません。このやり方は、実質的に設計を後ろ倒しにしていることになり、修正する場合も手間がかかります。
それよりも、先に理解と観点を固めておいた方が、あとから確認すべきポイントを絞りやすいと感じています。

そのため私は、テストの品質判断に必要なドメイン知識は、できるだけ最初にまとめて頭に入れてしまうようにしています。
先にテスト対象を理解し、どこを確認したいのかを自分の中で持ったうえで、その後の具体化や実装をAIに任せる方が、最終的なレビューもしやすいからです。

自分は「先に観点を固める」形で進めている

私は、次のような流れで自動テストを実装しています。

1. 自分でテストの観点を設定する
2. AIにテスト観点をレビューさせる
3. 1,2を数回ループしてテスト観点を決める
4. AIにテストケースを実装させ、レビューと改善のループを回させる
5. 自分で実装されたテストをレビューする
6. AIに意図と違うテストケースを修正させる

この進め方の中で一番重要だと思っているのは、1の自分でテストの観点を設定するところです。
テスト観点を自分で設定する過程で、それ以降の工程でAIの出力を判断するために必要なドメイン知識が頭に入ります。

もちろん、テストの観点がすでに固まっていて、それを横展開するだけの場合もあります。
その場合は、必要な知識がすでに頭に入っている状態なので、最初から全部AIにやらせた方が早いことも多いと思います。

人間がテスト観点を考えるときにやっていることは、突き詰めるとシンプルです。
テスト対象を理解し、何を確認したいかを挙げ、その中から本当に必要なものを残していく。
その結果として、テスト観点が固まっていきます。

ここで重要なのは、出来上がったテストそのものよりも、機能に向き合う時間だと考えています。

AIは、固まった観点をもとにテストケースを広げたり、実装に落としたりするのが得意ですし、0からテスト観点を作ることも十分可能です。
ただし、出力をどこまで採用するかを判断するには、人間側の製品理解が必要です。

自分は、AIが出力したテストのレビューで判断材料を探し始めるのはあまりよくないと考えています。 AIに最初から観点設定まで任せると、結局そのあとで人間がテスト対象を分析し直すことになりやすいです。また、AIが出力した観点を出発点にすると、AIの生成結果のバイアスがかかった状態でテストを考えることになる点も懸念があります。

だからこそ、観点の部分は人が握った上で、その後の具体化や実装を任せる分離が重要だと考えています。

AI時代に効くシフトレフト

シフトレフトは、ざっくり言えば、問題を後ろの工程で見つけるよりも、前の工程で品質を作り込もうという考え方です。
AIを使ったテスト実装でも、これに近いことが重要だと今の時点では考えています。

AIが大量に成果物を出せるからこそ、最後に人間がすべてを理解しながら確認するやり方は、これまで以上に重くなります。 だからこそ、先にテストの観点を作ることで、AIの成果物をレビューするためのドメイン知識を形作り、その後の具体化や実装をAIに任せる進め方がバランスが良いと考えています。

これは、後ろの工程で問題を見つけるよりも、前の工程で品質を作り込むという意味で、シフトレフトの発想とよく重なります。 Coding Agent時代のテスト実装では、「どこからAIに任せるか」だけでなく、「どこまでは人が先に握っておくか」を考えることが、これまで以上に大事になっているのだと思います。

おわりに

Coding Agentを使えば、自動テストの具体化や実装はかなり任せられます。一方で、テストの品質判断に必要なドメイン知識をどこで手に入れるかをフローに組み込む必要があります。

Coding Agent時代のテスト実装では、どこからAIに任せるかだけでなく、どこまで人が先に握っておくかを考えることが新たな課題です。

AIに任せる範囲が広がるほど、最初にどこまで人が理解しておく必要があるのかが重要になるのだと思います。 自分は、あとからレビューしながら理解を作るよりも、最初にテスト対象に向き合って観点を固め、そのうえでAIに実装を任せる方が進めやすいと感じています。