テストエンジニアが機械学習してみた備忘録

広島とジト目が好きなテストエンジニアが機械学習に手を出した備忘録。

「アジャイルもテスト自動化も当たり前?! ~AIがテスト設計をする日が来るかも~」を読んで

気づけば今年もあと一ヶ月となり、気づけばブログ開設して1年が過ぎていました。機械学習を勉強しようと思って備忘録的に始めたブログですが、今年はライフイベントを色々と詰め込んでしまったため、更新が滞ってしまいました…今年度はバタバタが続きそうなので、来年度に入ったくらいからは…と思いつつはてさてどうなることやら。

さて、今日はシステムテスト自動化カンファレンス(STAC)でした。

testautomationresearch.connpass.com

機械学習を絡めたセッションが多いので、ソフトウェアテスト機械学習を取り入れられないかということで勉強始めたこともあり、是非参加したかったのですが、残念ながら補欠から繰り上がらなかったので断念*1しました。

ところでこれ、繰り上がったら絶対行こうと思ってたので「一般参加(絶対行く枠)」の補欠に入れたものの、キャンセル率高そうなのは「一般参加(キャンセルするかも枠)」なので、「一般参加(キャンセルするかも枠)」にした方が良かったのだろうか…でも「キャンセルするかも」じゃないしなぁ…っていうかそもそもこの区分けいるのだろうか…?

閑話休題

STACの話はハッシュタグや発表資料を追うとして、ちょうどソフトウェアテストのアドベントカレンダー*2にもタイムリーな話題が出ていました。

kokotatata.hatenablog.com

「ふむふむ、なるほどー」と思う部分もあり、話の大枠としては「うんうん、目指したいよね」と思う反面、ちょっともやっとしたところもありましたので、整理がてら久々に筆を取ってみようと思います。

なお、以下の内容は元記事の私なりの解釈と、拙いながらもこれまで経験したこと、学んだことベースで考えたことです。経験や知識が不足している点も多々あります*3ので、別の見方や解釈や知見のある方は是非ご指摘いただけますと幸いです。

概要

上記の記事では「素早くテスト設計やテスト結果を学習可能」なAIが存在するという仮定を置き、そのようなAIが存在する環境下で「高速、高頻度でフィードバックループを回すこと」によって、テスト実行にとどまらないテストプロセス全体の自動化が可能になる(未来が来る)と説いています。この話をもう少し自分なりに噛み砕いてみます。

「素早くテスト設計やテスト結果を学習可能なAI」とは?

ここで出てくるAIに期待されていることは「AIとテストエンジニアの共通点」の節で述べられています。雑にまとめると以下の部分についてAIに担って欲しいということと解釈しています。

テストエンジニアも探索的テストにおいて、これと似たプロセスをとる。テストエンジニアはテスト対象システムについての完璧なテスト設計を持たないところからテストを実行し、テスト対象とテスト設計について学習する。

つまり、ここで期待されるAIは「テスト対象の操作に対する挙動を入力として、実施すべきテストケースを生成するモデル」を備えているものだと考えられます。このモデルを備えたAIは「こういう挙動をするなら、こんなテストをしておいた方がいいだろう」と考えてテストを進めてくれる優秀なテストエンジニアそのものです。

優秀なテストエンジニアがいれば万事解決か?

では、そのような優秀なテストエンジニアにテスト対象とテスト環境を渡し、全て任せて座して待てば十分なテストを通したことになるでしょうか?私は以下の理由からNoだと考えています。

  • 仕様か不具合か微妙な挙動の判断はテストエンジニアだけではできない
  • 挙動ベースでテストを行うと挙動に現れにくい仕様(テスト条件)を見逃す

つまり、実際にはテストエンジニアからの質問への回答や、テストエンジニアの認識の訂正をしたりする必要があります。また、テストエンジニアに対して挙動だけでは見えにくい仕様を伝える必要も出てきます。したがって、先ほどの「こういう挙動をするなら、こんなテストをしておいた方がいいだろう」と考えてテストを進めてくれる優秀なAIが仮にできたとしても、任せっぱなしでは上手くいかないと思います。

モデルの分割

「こういう挙動をするなら、こんなテストをしておいた方がいいだろう」は、「こういう挙動をするなら、○○な仕様なんだろうな」と「○○な仕様なら、こんなテストをしておいた方がいいだろう」に分けられます。この「○○な仕様」の部分を訂正したり、直接入力したりする必要があるということが前節で述べたことです。そこで、AIが備えるべきモデルは以下の2つに分割できます。

  • テスト対象の「操作に対する挙動」を入力として、テスト対象の「仕様」を出力するモデル
  • テスト対象の「仕様」を入力として、実施すべき「テストケース」を生成するモデル

前者を「テストベース生成器」、後者を「テストケース生成器」と呼称してみます*4*5。テストケース生成器の出力が自明なようにも見えますが、一応ある挙動から複数の挙動を類推して情報量が増えているイメージです。

なお、元々の「テスト対象の操作に対する挙動を入力として、実施すべきテストケースを生成するモデル」だと、上記の「仕様」の部分が学習の過程でブラックボックス化され、人間では訂正や追加ができなくなると思います。

元記事に対してもやっとしているところ

1回のテスト実行(アクション)が終了しテスト結果が出たら、そのテスト結果をテスト要求分析にフィードバックし学習する。次のテスト実行ではそれにもとづいて改善されたテスト設計を使いテストを実行する。

元記事では「テスト結果を用いてテスト設計を直す」と謳っていますが、これまで私が考えてきた流れだと、テストエンジニア(AI)だけではテスト設計の改良に必要なフィードバックを十分に得られないため、テスト結果単体ではテスト設計にフィードバックしてテスト内容を修正できることはないと思います*6。故に、テストプロセスの完全な自動化には、それと対となるプログラムの実装者側のAI化も必要であり、それはもう自動テストどころか自動開発の世界だよなぁ…と思うわけです。

最後に

もちろんこの領域の自動化に否定的でも悲観的なわけでもないです。「こんな動きするけど仕様なん?」とか「こういう仕様と理解してテスト設計するやでー」と提示してくれて、「いやいや、ちゃうねん、こうやねん」って伝えたら即座にテストケースを修正してくれるようなAIがあるという世界自体はすごくカッコイイ未来だなとも思います*7

繰り返しになりますが、上記の内容は元記事の私なりの解釈と、拙いながらもこれまで経験したこと、学んだことベースで考えたことです。経験や知識が不足している点も多々ありますので、別の見方や解釈や知見があるよという方は、是非ご指摘いただけますと幸いです*8

*1:ちなみに、一般参加(絶対行く枠)の最後に入ってますが、何故か当日の13:40頃に繰り上がりました。さすがに既に始まってるし、関西から駆けつけるのは無理…せめて前日なら…

*2:今年は1と2と小ネタがあるみたいですね。2はまだ空きがあるので何か書いてみようかな…

*3:そもそも元記事を書いた方は、自分なんかよりはるかに実力も実績もある方ですしね。

*4:いずれも回帰問題に該当すると思うので、テストケース回帰器とかテストベース予測器とかつけようかとも思いましたが、直感的ではないのでやめておきます。そもそもテストの世界では「回帰テスト」という厄介な呼称がありますし…

*5:呼称したところでこの投稿内でこれ以降に使う機会がなかった…

*6:そもそもテスト結果は「期待値通り動いたか?」であって、仕様が正しくテストが安定しているという前提であれば、「PASSなら問題なし、FAILの場合は要修正」というだけで設計への反映は起こり得ないのでは、と思います。(むしろFlakyなテストの方が結果を見る価値はありそう。)

*7:んなもんどうやって作るんやという話はもちろんありますが。

*8:むしろ教えてくださいえらい人…!