ビジネス

年の瀬ベリサーブ座談会:テスト技術を熟知する3者が語った、AI時代だからこそテストの価値が高まるワケ(前編)

年の瀬ベリサーブ座談会:テスト技術を熟知する3者が語った、AI時代だからこそテストの価値が高まるワケ(前編)

間もなく2024年も終わりを迎える。テスト・QA業界にとってこの1年はどのような位置付けになったのだろうか。AIを中心とする技術の進化はいかに?

株式会社ベリサーブで執行役員 プロダクトソリューション事業開発部長を務める松木晋祐、研究開発部長の須原秀敏、広報・マーケティング部のテスティング・エバンジェリストである大西建児の3者が、テストの未来展望とともに熱弁を振るった。

三者三様、テストとの出会い

編集部座談会の進行は大西さんにお任せしますが、冒頭、2024年の振り返りを皆さんにしていただきたく思っています。テスト・QA業界はこう変化したとか、それぞれご意見をお願いします。

松木:AI技術が思ったより進展しなかった一方、ある面では予想よりも進んだと感じています。前者は、AGI(汎用(はんよう)人工知能)がまだ出なかったからです。私は今年出ると思っていたのですけれど、ChatGPT-5はリリースされませんでした。きっと米OpenAIの人たちも思っていますよ。想定していたよりもAIが賢くならなかった、と。

一方、AIでソフトウェアを作る、戦略を立てる、開発プロセスに組み込むといった社会実装は想定以上に進んだと考えています。AIの民主化はもう止まらなくなってきていて、来年はさらに面白くなるでしょうね。

須原:半分は同じかな。私はAGIが出ないと思っていたから。今のロジックでそのままいくのか半信半疑で、個人的にはまだ分かりません。後者に関しては、AIの社会実装が進んだことを感じているし、われわれのビジネス環境も急激に変化してきています。プログラムを書く人がいなくなるかもしれないという話が当たり前に出ている中で、われわれはどういう点で価値を生み出し続けられるかを真剣に考えなくてはなりません。

そういう意味では、来年は忙しい1年ですし、多分その状況は今後2年、3年と続いていくのではと思っています。楽しみでもあり、怖くもありますよね。

大西:思ったよりも復活していないのはコミュニティー活動です。コロナ禍が終わった後もエンジニアの交流やコミュニケーションはずっとオンラインが中心。一度信頼関係ができればオンラインでも大丈夫ですけれど、そうでなければ、今日の座談会のような深い議論はなかなかできないと思うのですよね。

ただ、物理的なコミュニティー活動の機会は戻りつつあるので、来年は人と人とのネットワーキングや技術的な交流が深まればいいなと思っています。

……ということで、本編に入りたいと思います。いくつかテーマを持ってきました。まずは「私とテスト」。テスト技法とかテスト管理とか、好きな領域が皆さんそれぞれあるはず。まず自分のことから言いますと、私は知っての通りテスト技法ってあまり好きではありません。

須原:え、知らないですよ(笑)。好きじゃないというのは。

大西:いや、もちろんテスト技法の話はできますが、好きか嫌いかというと、秋山(浩一)さんのようにテスト技法が好きとは言えないかもしれません。

松木:めちゃめちゃ興味ある。なぜ好きじゃないのですか?

大西:だって面倒くさいじゃないですか。自分がテスト設計する時に必要だからテスト技法はもちろん使いますが。最たる例は、初めて「ミューテーションテスト」を知ったとき、これは大嫌いだと思ってしまいました。なぜわざわざテストするためにバグを仕込まなきゃいけないのかと。

松木:本来の意味でのミューテーションですね。今はかなり変わって、別の方向で語られることは多くなってきましたけれど。

大西:テストにAIが適用されるもっと前の時代の話でしたから。それで、個人的に好きなのは「テストマネジメント」。テストを最初にきちんと学んだのは20代後半。だから遅かったんですよ。当時働いていたアメリカが本社のメーカーでは、ソフトウェアエンジニアリングのトレーニングを受けないとエンジニアを名乗ってはいけないから、テスト技法やテストマネジメントなども学びました。また、テスト技術者交流会に入り、「基本から学ぶソフトウェアテスト」を翻訳するプロジェクトに加わりました。そこで西(康晴)さんとも知り合うことができました。

広報・マーケティング部 テスティング・エバンジェリストの大西建児
広報・マーケティング部 テスティング・エバンジェリストの大西建児

お二人がテストの分野に興味を持ったきっかけは? 松木さん、いかがでしょうか。

松木:まだテストエンジニアやQAエンジニアという職種が成立していない時代に、いわゆる派遣のテスターとして業界に入ったのが始まりです。3カ月の契約ねと言われて、そのままその会社に13年いたのですけれど(笑)。

最初は携帯電話の打鍵のテストだけをひたすらやっていました。データベースに登録されている数万件の試験表を見ながらテストする作業。テスト設計どうこうよりは、先にバグ票の書き方を習いましたね。

大西:当時はワープロで起票していたのですか?

松木:もうさすがにPCですね。ただ、今のようなバグトラッキングシステムはなくて、「バグナッツ」という独自のバグ管理システムを使っていました。テスト設計に興味を持ったきっかけが、この数万件のテストをやりながら「このテスト、意味あるのかな」「さっきやったよね、この手順」などと疑問を抱くようになったことですね。

大西:テストしていたのは携帯電話のアプリ、それとも携帯電話自体の機能ですか?

松木:ブラウザですね。ネットフロントに対して求められるHTTPやSSL。証明書はこのように表示しなさいといったテストですね。SSLv2とv3の通信が切り替わるときのテストとか。そうしたテスト手順がすさまじく長くて、100個くらいありました。

テストケースに疑問をずっと持ちつつ、そのうちに、そもそもテストはどうやって作るのかを考え始めました。ただ、社内で聞いても誰も分からなかったので、「JaSSTソフトウェアテストシンポジウム」などの社外のコミュニティーに参加するようになりました。そこで大西さんや秋山さん、西さんに出会い、いろいろな方に教わりながら、「なるほど、やはりあのテストは駄目だったんだ」と気付いたわけです。その後、テスト設計やテスト分析を本格的に学んだ感じですね。

好きなテストの分野は「テスト自動化」。理由があって、テストの実行が瞬時に終われば、テスト設計の方に注目が集まると思っているからです。テストは実行している時間が長過ぎるから、このテストがそもそも上手に作られているのかという点にあまり目がいかないのですよ。けれど、テスト実行が自動化されて、一瞬で終わるようになれば初めて、「このテスト、全然バグが出ない」「このテストは粗くない」など、テスト設計に人々の関心が向くはずです。

大西:では、続いて須原さん。

須原:私とテストですか。学生時代は土木工学科で自然言語処理を研究していました。テストに興味を持ったのは、ベリサーブに入ってから。職業として選んだだけなので、別に元々テストに興味があったわけでも、好きだったわけでもないです。

最初、自動車業界関連の現場に入って、テスト設計に携わったのですが、再現性のなさに違和感を持ちました。どうにかしてテスト設計を機械化できないかと思いながら、ずっと手作業で行っていました。そこが私にとってつらみでした。

大西:社会人になったのに、どうして自分はこんなことをやらなきゃいけないのだろう、ということですか?

須原:そうは思っていないです。必要な作業だなと思っていたので。でも、無駄も結構ありましたね。

大西:ベリサーブの中で誰かから教わった経験はありますか? 

須原:当時は手厚い教育もなかったので、私は社外から学んだ感じですかね。それこそJaSSTとか。社内でその時は教えてくださる人がいなかったのですけれど、今になって工藤(邦博)さんなどとの絡みができて、レジェンドはすごいなと驚いています。その人たちなりにきちんと説明可能性を頭の中で構築していますから。それらを体系化し、会社としての知見にする活動を今やっているところです。

質問に戻ると、私は「再現性」や「エンジニアリング」に興味があります。自分が関わっているテストの世界で、これを実現したいと思っています。

大西:テスト技法で好きなものはありますか?

須原:「MBT」(Model Based Testing:モデルベースドテスト)とかは、世の中一般のテスト設計技法というよりも、個別で作っている設計技法ですが、そこら辺が好きですね。

大西:MBTという名前が付く前からUML(Unified Modeling Language:統一モデリング言語)を使ってU2TPみたいなモデルでテスト設計することはありました。ただし実際にはステートマシンだけ、あるいはアクティビティチャートだけでテスト設計が容易にできるかというと、できなくはないのですが、範囲が絞られてしまう。システムテストなどでは使えない。当時湯本(剛)さんとも話したことがあるのですが、ステイトマシンとシーケンサーとアクティビティチャート。要は時間軸を取り扱っているものを2つのモデルからテスト生成できないか、といったことです。

須原:まさにそれはキーワードです。単機能テストだったらいけるけれど、システムテストはできない。だから、状態遷移図とシーケンス図を組み合わせて作るといったことをやらないと、ベリサーブ社員が納得できるMBTにはならないと感じています。

自然言語でテスト自動化を可能に

大西:お二人はテスト自動化やテストツールの領域でいろいろと知見を持たれているじゃないですか。今のツールができること、今後ツールはこう進化していくというお話もしていただきたいです。夢や希望のある領域と、そうでない領域の両方を伺えれば面白いのではと思うのですが、いかがでしょう。

松木:夢のある領域だと「Playable!Mobile」と「VEST」ですね。

モバイルゲーム開発のQA工程を生成AIで自動化するPlayable!Mobileは、ベリサーブで開発し、子会社のアイキューブワンで提供しています。今年の「東京ゲームショウ」にも出展しました。基本的にはゲームをターゲットとして、ゲームの画面と、その画面の構成情報に基づいて、自然言語でテストが実行できるツールです。

執行役員 プロダクトソリューション事業開発部長の松木晋祐
執行役員 プロダクトソリューション事業開発部長の松木晋祐

これの何が面白いのかというと、今までテスト自動化はプログラミングが必須だったんですね。何らかのスクリプトを必ず書かねばならないのが、テスト自動化を進めるときの一つのハードルになっていました。かつ、テスト自動化のためにスクリプティングやプログラミングをすると、決まった動きしかしなくなってしまいます。そうすると、作ったテストが無駄にならないよう、製品の仕様などに合わせてずっとプログラムを変更しなければなりません。この2つのつらさがありました。

ところが、自然言語で「ログインして、ガチャを回してください」といった指示をすれば、製品がどう変わろうが、画面を見ながら「ああ、ガチャを押すはボタンこれですね」とLLM(Large Language Models:大規模言語モデル)が判断してくれる。テスト自動化を作るつらさとメンテナンスするつらさの両方が一度に解決できるのです。

大西:既存のツールとの違いを教えてほしいです。RPA(Robotic Process Automation)を使ったツールやキーワード駆動型のツールなどと比較して、Playable!Mobileを使うとユーザーは何がうれしいのですか?

松木:まず、ゲームに特化しているところです。ゲームのUIは、プラットフォームの標準のGUIパーツなどは使われないですね。ですから、OSの部品をフックしてたたくのがゲームのテストでは非常にやりにくい。一般的なテスト自動化ツールを当てても、多分UI部品は何一つ取れないのですよ。

大西:なるほど。

松木:Playable!Mobileはとにかく画面から取ってくるので、エンドトゥーエンドに最も近いです。ユーザーがパッと画面を見て、ガチャのボタンが有るか無いかを判断する形ですね。

後、ゲームテストの分野は、プログラミングに触れたことのないアルバイトや学生が多いのですが、そういう人たちでも自然言語でテストが自動化できるようになると、非常に効率が良くなります。

「テストの未来は明るい」と確信する理由

須原:VESTは社内向けのツールです。仕様書を入力すると対話形式でAIのエージェントとコミュニケーションを取りつつ、テストケースを出すところまで一緒にやってくれます。

その裏にあるロジックにMBTを採用していて。裏でモデルをAIが生成してくれて、そこからルールベースでテストケースを作るような動きになっています。

研究開発部長の須原秀敏
研究開発部長の須原秀敏

実際、テストケースを入力して、対話形式で、「どんなテストを作りたいですか」とヒアリングしてくれるのですけれど、どういうテスト戦略を立てるかについても裏側のロジックがかなり重要になってきます。そこについては、正直まだ誰もが納得するような戦略を立てるまでは至っていません。ただ、テスト戦略が立った後のモデル生成と、そこからのテストケース生成に関しては、かなりの割合で自動化できるような形になればと思っています。

言いたいことは、上流工程はベリサーブの役割として今後も残るかなと思うのですけれど、テストケース生成とか、テスト実装とか、後の方のプロセスについては、一定の割合で自動化されるようになると見ています。

大西:テスト分析はあくまでも支援レベルで、頭を使って分析までできていれば、設計やテストケースのトレーサビリティの確保は、自動生成してくれるわけですね。

松木:めちゃくちゃ話題は飛ぶのですが、今後5年、10年で、ある分野に関しては、わざわざアプリを作る必要がなくなるのではと考えています。例えば今、うちの会社は財務諸表を出すために、財務会計アプリを使いながら頑張っていると思いますが、極論すると、「データはここにあります」「当社の今月の決算を出してください」ってChatGPTに指示すれば、即座に財務諸表が出てくる世界はそう遠くない。そうなると、「財務会計アプリはいりますか?」となるでしょう。

恐らく多くの領域でそういうことが起きてくる。そうなった時に、もしかしたらベリサーブが持っている資産の中で一番面白いのが「TREES」という社内専用の独自システムかもしれない。これは過去対応したテスト観点を抽象化、構造化したノウハウとしてデータベース登録したサービスです。ずっと須原さんがメンテナンスされてきて、今も相当数が積み上がっていると思うのですけれど。

須原:もう5年以上ですね。5万件くらいのテスト観点があります。

松木:いずれAIにどんなテストをしてほしいかを指示するだけで、基本的に彼らの中で考えてテストしてくれるようになるとは思うのですよね。そうなった時には、どんなシステムにはどんなテストをすればいいかというデータをためておくことが非常に重要。それに対してはTREESや、意外と「QualityForward」も有効です。こうしたデータがあれば、テスト分析の仕事はきっと残る。テスト分析までは残るのですが、テストの詳細設計以下は完全自動化される可能性が高いと思っています。

私はテストの未来は明るいと考えています。IT業界で最後まで立っているのは、「何を作るか決める人」と「テストする人」の二人かもしれない。

もの作りはもうAIが全部やります。ただ、AIが作ったものを無批判に受け入れることに関して、まだ人類には早いと思うのですね。ちょっと怖いじゃないですか。「本当にこれ、うちの会社で使えるのだっけ?」とか確認したいじゃないですか。

後は、こういうものを作りましょうとAIに指示を出した人が、われわれの意図をきちんと酌んでくれているのかも不安ですよね。指示を出しているのが人間だから。ですから、受け入れテストは今後非常に重要になっていくはずです。逆に受け入れテストだけになってしまうかもしれません。

大西:受け入れテストもAIがやるのですか?

松木:受け入れテストは、テストエンジニアが指示を出して、AIにやらせる。恐らくこれは5年、10年で実現すると思います。ソフトバンクグループCEOの孫(正義)さんはもっと早いと言っていますけれど。

大西:シンギュラリティはもっと早いと語っておられますね。

松木:まとめると、もはやアプリはなくなるかもしれないけれど、顧客や社会がAIに対して、何をやらせたがっているのかを、われわれが深い解像度で理解しなければいけません。そして、それが社会実装された時に何を確認すれば、目標が達成できたと言えるのか。そこを明確にすべく、より一段高い物差しを発明する力を養っていかないと駄目です。

大西:誰がですか?

松木:ベリサーブが。他にやる人はいないから。つまり、テストがどう実現されたかを確認する役割ですね。かつ、われわれはデータと道具をすでに持っています。近い将来、そういう仕事にきっと変わっていくので、感性をより研ぎ澄ましていく必要があると感じています。

後編に続く

SNSシェア

この記事は面白かったですか?

今後の改善の参考にさせていただきます!

Search Articles By The Cast出演者/執筆者から記事を探す

Search Articless By The Categoryカテゴリから記事を探す

Ranking

ランキング

もっと見る