2024年7月24日、 SHIFTが手がけるエンジニアコミュニティ「SHIFT EVOLVE」より、「生成AIはどうテストを変えるのか(AI Test Lab vol.1)」と題されたオンラインイベントが開催されました。
「人がつくった要件に対して人が開発し、テストをする」という、従来は当たり前だと思っていたことが、生成AIの登場と活用の広がりとともに大きく変わりつつあります。
テストは、生成AIにどこまで置き換えられるようになるのか。
今回は、ツールベンダーとテストベンダー、自動品質保証エンジニアの3名による取り組みが紹介された後、最後に「生成AIはどうテストを変えるのか」というテーマでパネルディスカッションが実施されました。
※SHIFT EVOLVEとは?
「無駄をなくしたスマートな社会の実現」を目指すSHIFTグループが主催する技術イベントグループ。 エンジニアコミュニティから技術をEVOLVEしていこう、という想いで運営し、メンバー登録者数は3,200人を超える(2024年9月時点)。開催予定のイベントは以下よりチェック。 https://shiftevolve.connpass.com/
-
伊藤 望
株式会社MagicPod CEOAIテスト自動化プラットフォーム「MagicPod」のCEO。「日本Seleniumユーザーコミュニティ」設立、「Selenium実践入門」執筆、国際カンファレンス講演、「SeleniumConf」日本初開催など、長年テスト自動化の普及に努めてきた、日本におけるテスト自動化の第一人者。趣味は自動化・仕組化。
-
坂下 聡
日本電気株式会社 ソフトウェア&システムエンジニアリング統括部 プロフェッショナル1993年入社。システムコンサルティングやインフラ構築、テスト自動化ツールの開発や導入を経て、現在はテスト全般のソリューション提供とテスト自動化技術の普及活動を担当。
-
石井 優
株式会社SHIFT CATエヴァンジェリスト倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入および大規模基幹システム移行への参画を経験し、2015年SHIFT入社。CAT開発チーム内でユーザーサポートとして、ユーザーと開発メンバーのブリッジを行いユーザーの課題分析や新機能提案などを日々実施している。
目次
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 by.石井 優(SHIFT)
石井が所属するSHIFTのサービスプラットフォームグループでは、統合型ソフトウェアテスト管理ツール「CAT(COMPUTER AIDED TEST)」や、テスト設計支援ツール「TD (TEST DESIGNER)」の自社開発や、それらを活用したAI技術の活用推進、社内の基盤開発などを進めています。
特にTDでは、現在「TD AI Assistant」の開発を進めており、これまでSHIFTが溜めてきたテストケースや標準テスト観点などのナレッジにAIの力を組みあわせることで、よりはやく精度の高いテストケースの設計を可能にするための取り組みを進めています。
AI導入による具体的な提供価値とターゲット、解決されるペインは、上の投影資料にある通りです。
そもそもTDは、以下のスライドにある通りテスト設計の段階を分割し、レビューと設計の効率を両立することを目指して構築されています。
ここに対してTD AI Assistantでは、分解された各ステップに対してAIが支援する仕組みになっています。
ポイントは、AIに丸投げするのではなく、AIが品質保証エンジニアの業務を支援するような形での業務フローが想定されている点にあります。
「AIに渡すためには『ここの行間をうまく読んでよ』ではダメで、細かく指示をセットする必要があります。生成AI時代ではインプットとなる仕様を最初に整えておくことが大事であり、そこが我々が現在感じているハードルの一つです」(石井)
テストケースの自動生成に生成AIの導入を試みた話 by.坂下 聡氏(NEC)
日本電気株式会社(以下、NEC)でテストソリューション、テスト自動化の推進を担当している坂下氏からは、既存の設計書(Excel形式)からテスト仕様書を作成し、テストスクリプトを出力するテストケースの自動生成ツールの一部に、生成AIが活用できないかを検討した2023年12月時点での取り組みが紹介されました。
NECでは以前から、上のスライドに描かれているようなテストケース自動生成ツールが使われていたのですが、主に日本語の処理において課題がある状況でした。
今回の取り組みは、この日本語処理に対して生成AIが活用できないか、という話。
実際に既存の設計書(Excel形式)を読み込ませてChatGPT-4でテストケースを作成したところ、以下の特徴/可能性などがわかってきたといいます。
これらに加えて、例えばログイン有無の条件分岐が解釈できないので書き方を考えたり、入力チェックのチェック項目は全部バラバラに記載したりといった試行錯誤を経てChatGPT活用に再チャレンジしたところ、決まったキーワードなどによるフォーマットで指示をするだけで、ある程度のものがアウトプットされるようになったといいます。
以上の経験から、「AI-Readyなデータ」の準備こそが、生成AI活用促進の鍵だと坂下氏は説明します。
そのうえで現時点の生成AIが向いているのは、ドメイン知識を必要としない一般的なシステムのテストケースの設計・作成や、知識を特定のフォーマットに整理したうえで実施するようなテストシナリオ。
一方で論理的思考や人間の直感が必要になるようなアドホックテストや探索的テストなどのケースには不向きであることを示しました。
最後に、今後のテストプロセスにおける生成AIの期待について、以下のスライドを投影しながらコメントしました。
「特にテスト計画のところは、品質計画やテスト戦略などの部分も含めて立てていくことを考えていくと、まだまだこれからの世界かなという印象があります」(坂下氏)
E2Eテスト自動化プラットフォームにおけるAIの活用 by.伊藤 望氏(MagicPod)
自動テストツール歴15年の伊藤氏が提供しているのが、Web&モバイルアプリのE2Eテスト自動化SaaS「MagicPod」です。こちらのプロダクトでは、以下3つの機能でAIを活用しているといいます。
- 人間に読みやすい画面要素名
- 自動修復(アプリケーションの画面構成が変わってテストが失敗した場合に、AIがテスト側を適切に修正してテストを継続する機能)
- 生成AI
今回のテーマである3つ目の生成AI機能では、「テストケースの要約」、「変更コメントの生成」、そして「ランダムIDの検出」の3点について生成AIの活用が検討され、前者2つについてはMagicPodへの機能実装が進められました。
例えば変更コメントの生成機能をみてみると、変更前と変更後のスクリプトをそれぞれMagicPodのAPIを使って人間が読めるテキストへと変換し、それらを使って以下のプロントをChatGPTに渡すことで、割と実用的に活用できるアウトプットになったといいます。
一方で最後の「ランダムIDの検出」は、最終的にボツになった事例です。
検証の流れとしては、HTMLからすべてのidとclassをひたすら抜き出し、そのなかのどれがランダムIDかどうかを生成AIに渡して判断してもらうという、シンプルなものになります。
渡したプロンプトは以下の通りです。
こちらの検証の結果、生成AIは多くのランダムIDを検出でき、検出されたものはほぼ正しくランダムIDだったものの、一方で検出漏れが頻繁に発生し、さらに30個のIDを検出するのに6秒もかかるという状況だったとのことで、MagicPodに組み込むのはいまのところむずかしそうだと判断しました。
「ただし、最近のChatGPTはかなりレスポンスがはやいので、また結果は違ってくるかと思います。
また、リアルタイムではなく自動修復のときにやれればいいといったアプローチもあると思うので、今後またチャレンジしたいと思っています」(伊藤氏)
パネルディスカッション「生成AIはどうテストを変えるのか」
最後に、登壇者3名を交えたパネルディスカッションが展開されました。ここでは、各ディスカッショントピックにおいて特に印象深かった発言をピックアップしてお伝えします。
質問:AIがテストを設計する未来についてどう思われますか?
伊藤:AIが本当に全部を変えてくれるみたいな日もくるのでしょうが、テスト設計って裏側にあるモデリングの話や、それこそ人がもつ常識など、いろんなことを知っていないとダメだと思っています。
プログラムを書くのと同じぐらい本質的に人間じゃないとできないことだと思うので、テスト仕様書が本当に自動でつくれるようになったときは、たぶん仕様書もプログラムも全部つくれるようになっていて、エンジニアも概ね失業というかロールが変わっているみたいな状況かなと思います。
テストだけ先に全部自動化みたいなことにはならないのではと思っています。
質問:AIでE2Eテストのコストは限りなくゼロに近づくのでしょうか?
伊藤:本当にゼロになっているときというのは、ほかのいろんなITコストもゼロになっているときだと思います。
その前提にはなりますが、MagicPodを開発していて思うのは、製品の仕様書から全部つくって、テストも全部やってくれるみたいな世界は少し大変だなと思いますが、人間が手動テストで普段使っているテストケースだけを読み、あとはそこの自然言語で書いているやつを使ってE2Eテストができたらいいなとは、けっこう思ったりしています。
もう少しChatGPTなどが賢くなればできる側面もあるのかなと思っているので、当然ゼロにはなりませんが、減ってはいくと思います。
坂下:ユニットテストを書くのがめんどくさい、っていうSEの方ってけっこう多いんですよね。大変なので。
その部分にAIを使うことで、いわゆる品質を担保しながらタイプミスなども減らせると思うので、レビューにも注力できると。
それに連携する形で開発コードも自動的に生成できてくるような形になって行くことを踏まえると、まずはユニットテストのところが一番効率的に進められるのかなと感じます。
質問:AIがつくったテストの信憑性についてはどうお考えでしょうか?
石井:実際にTD AI Assistantを再評価したときに、テストの信憑性を評価するのってむずかしいね、っていう声が出ていました。
というのも、実際に検証するとなると、そのロジックを頭のなかで考えて、それがこの状態であっているのか否かを、仕様とつきあわせながら考えないといけません。
それがけっこうつらいなっていうのが、TD AI Assistantの課題であり、そこを乗り越えていくのはけっこう大変だなと思っています。
もうちょっと上位の、例えばテスト観点を出してもらうとか、テスト戦略をいっしょに考えてもらうとかっていう方が自然なのかなと思っています。
伊藤:AIが書いたものを人間がチェックする未来ではなく、人間が書いたものをAIがチェックする未来であってほしいですけどね、個人的には。むずかしいところですが…。
質問:AIの普及によってテストは増えますか?それとも減りますか?
伊藤:つくるコストが低いので、どうやっても増えることは増えると思います。増えるところまで増えきって、これではいけないとなって間引く、という話がやってくるんじゃないですかね。
石井:パーキンソンの法則で考えると、どこまでやるのっていうのをちゃんと定義しないと、いつまでたっても増えつづける一方だなって思いました。
坂下:例えば増えるのをよしとして、増えたおかげでいままでリグレッションとかでテストの範囲が届かなかったところを自動でやるっていうところで品質を均一に担保していくっていう考え方をすれば、増えたら増えたなりの効果が出るという話になるかなと思います。
パネルディスカッションの他パートや、動画全編をご覧になりたい方はこちら
―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。「AI Test Lab」と銘打ったシリーズは今回がはじめてでした。Vol.2以降もぜひお楽しみに。
3,000人を超えるエンジニアコミュニティ SHIFT EVOLVEをチェック
(※本記事の内容および取材対象者の所属は、取材当時のものです)