【参加メモ】AI時代のソフトウェアテストの現在と未来 #genai_autify_launchable

本日2024年3月5日(火)の昼間に開催された、『AI時代のソフトウェアテストの現在と未来』というイベントがとてもよかったので、特に印象深かったポイントについて共有したいと思います。

イベントの詳細はこちらで。 autifyjapan.connpass.com

登壇者はタワーズ・クエストの和田卓人 @t_wada さん、Launchableの川口耕介 @kohsukekawa さん、Autifyの近澤良 @chikathreesix さんのお三方。ファシリテーターは、近澤さんと同じくAutifyの、末村拓也 @tsueeemura さんです。

宣伝タイム

Launchableは、「テストの失敗をよりインテリジェントに扱う」ことを目指している。
たとえば、テストのFlakinessの判定や対処にできるだけ人を介在させないとか、過去の実行結果を見て再実行要否の判断をするといったもの。
Autifyは、E2Eテストの2つのペインポイントである実装と保守を、ノーコードで行う。画面変更にも自動的に追随できる。

質問1. AIを活用した開発プロセスのあるべき姿

「ソフトウェア開発における生成AIの活用といえばまずコード生成が挙がるが、生成AIは要件定義でも強みがありそう」という川口さんのご指摘に対して、近澤さんも「要件定義など上段をしっかり作ると、良いアウトプットができる」とおっしゃっていました。
基本設計→詳細設計→プログラミングと、設計ドキュメントを十全に作り上げてから実装の始まる従来の開発から、「包括的なドキュメントよりも動くソフトウェアを」を旨とするアジャイル開発へのシフトが起こりましたが、今後は「動くソフトウェアを素早く作るためのドキュメントを」というパラダイムも来るのかなーと感じます。

生成AIによって生成されたモノの質の担保について、「何をもって正しいかは人間が判断する」とした和田さんのご意見が印象的でした*1。AIはあくまでも「自分が書くとこうなる」とわかっているものを作ることは楽にしてくれるけれど、「どう書けばいいかわからない」ものは、質を評価できないと。これはプロダクトコードもテストコードも同じ。
「プロダクトコードとテストコード両方を書く場合、プログラマーは頭のモードを切り替えて自分との会話をするが、LLMにこの対話をさせるパイプラインをデザインできないか」という川口さんのアイデアに対し、「両方をAIに生成させると、両方が等しく誤るリスクがある」とおっしゃっていました。ただ、「要件・仕様ドキュメント」「プロダクトコード」「テストコード」のトリオのうち2つを人間が作り、残りの1つを生成させると、高い精度が得られる傾向があるというお話をされていました。
何となくRAID5の分散パリティを思わせるようでもあり、またある意味「たがいに冗長」である2つをしっかり作ることで、残りの1つが間違える確率を減らしているようにも思え、ワクワクする知見でした。

質問2. テストにおけるLLMの活用

近澤さん、川口さんともに、今後はテキストベースのログだけでなく、マルチモーダルAIでスクリーンショットをチェックし、従来はベテランの直感頼りだった異常検知もできるようになるだろうとおっしゃっていました。
「才能のあるテストエンジニアの力を民主化し、スケールさせる」という表現も面白かった。

質問3. 人間に残されるタスク

たとえば運転は、自動運転に代替され始めている。そうなると、「運転する」こと自体は重要ではなく、「どこに行くか」を考えられることが重要というのが、San FranciscoでWeimoの自動車を目の当たりにしている近澤さんのご意見でした。「何を作るか」は人間が考えるということですね。
一方川口さんは、いわゆる「上流」の仕事も、ユーザやマーケットの観察などある意味で機械的・言語処理的なものであり、生き残るかどうかには懐疑的とのご意見。

ファシリテーターの末村さんは、ベテランのエンジニアが行っていることの例として、「どのタイミングでどういうテストを行うべきか」といったテスト戦略の立案や、新しいテスト技術の開発*2といったものがあり、こういった作業は代替されないのでは？と問いかけを行っていました。

前者について和田さんは、従来のテスト戦略の暗黙の前提になっている点を見直す必要が出てくるというお話をされていました。
これまでのテスト戦略は、テストを行う主体が人間であることを前提とし、そのうえで最適な方法を模索しています。単純な例だと、「パラメータの全組み合わせを手動で実行している時間はないから、リスクに応じてカバレッジ基準を落とそう」といったものです。
テスト自動化によりそれも変わってきてはいますが、生成AIがそれに拍車をかける。よって、今まで前提としてきたもののうち、依然として有効なものがどれで、すでに無効になっているものがどれかを見極める必要がある、ということです。

4. レガシーコードの技術的負債に対するAIの活用

巨大なコードベースで、テスト容易性・理解容易性・変更容易性がすべて低いような状況において、「リファクタリング前後のサンプル」を少数与えることで、残りのレガシーコードも「以下同文」としてすべてリファクタリングすることができるのではないか」という和田さんのお話が面白かったです。
また、数万行オーダーのコードを生成AIが一気に理解できるようになれば、コードから仕様ドキュメントの生成も容易になり、「誰も全体を把握していない」「超ベテランしか把握していない」という状態から抜け出せるというお話もありました。夢が広がる話です。