こんにちは、MagicPodでセールスをしている猪狩(いかり)です。

前回に続き、7月28日に開催されたLaunchable様との共催セミナーの様子をレポートしていきます！Jenkinsプロジェクトの創始者でもあり、数多くの最先端ソフトウェア開発現場で活躍されてきたLaunchableの川口 耕介さんとの対談もあり、イベント公開当初から開催が待ちきれないと多くのお声をいただいておりました。

目次

1. イベント概要（前編）

2. 川口 耕介さんがLaunchableでめざすもの （前編）

3. 伊藤 望がMagicPodでめざすもの

4. 両CEOが語るソフトウェアテスト開発最前線

3. 伊藤 望がMagicPodでめざすもの

E2Eテストをもっと簡単に自動化できるように

たくさんあるテストの中でMagicPodが取り組むのはE2Eテストの自動化です。

「E2Eテストを具体的に言いますと、（テスト）ピラミッドの中で、「ユニットテスト」という部品をテストするものがあって、もう少しまとまった単位をテストする「結合テスト」というものがあって、その上で全部通しで行う「E2Eテスト」というものがあります。E2Eテストは、Webサイトやアプリなどの画面から操作するものが多いですね」

さらに、従来型のツールだと難しい課題が多く、MagicPodではそれらを解決することに取り組んでいます。

「（従来型の自動化ツールは）セットアップが大変。なんとかセットアップしたけど、コーディングしていかないといけないので、書くのが大変。なんとかコーディングができても、画面が変わったり、IDやテキストが変わると動かなくなるので、メンテナンスが大変。（それらの課題に対して）MagicPodだと、クラウドなのでセットアップが簡単。コーディングについても、画面からノーコードでテストが作れるのでテスト作成が簡単。メンテナンスについても、「自動修復」という機能で、画面が変わった時に、実際はこの要素はここが変わったからこれをタップすればいいんじゃないかとか、MagicPodのAIが修復してくれて、人間がこれで問題ないと結果をアクセプトすればメンテナンスが完了します」

MagicPodが実現したいこと

　では、MagicPodがユーザー様の業務フロー改善にどう貢献していきたいか、大きく分けて２つあります。

　　・開発生産性向上に寄与
　　　問題の早期発見で、記憶が鮮明なうちにバグを修正でき、原因の切り分けもシンプルになる

　　・継続的デリバリーの実現を支援
　　　コード変更後の早期テスト実行で、好きなタイミングで本番環境にデプロイできるようになる　

4. 両CEOが語るソフトウェアテスト開発最前線

続いて、本イベントのタイトルでもある「ソフトウェアテスト開発最前線」について、川口さんと伊藤の対談を見ていきます。まずはシリコンバレーで最先端の開発に現在も取り組まれている川口さんにお話を聞いてみました。

川口さん「テストの実行結果を直接人間が見るのではなく、その間にワンクッション挟むというのが進んだプロジェクトチームでは取り組まれているように見受けられます。例えば、フレーキーテストが一番よくあるパターンで、いちいち人間が結果を見ていると量が増えてキリがないので、一回テストが失敗しても人間に直接知らせないで、自動で再実行をかけてエラーが再現するかとか、直前にデプロイされたバージョンでもう一度同じテストを走らせてそこでフレーキネスが確認されるか、のような形で、本当にテストがおかしいとかコードがおかしいと確認が取れるまで、人間に情報を上げないという取り組みが、全般的に行われていると思っています。あるいは、バイセクティングのような形で自動で障害を切り分けてから人間に教える、というようなこともある」

伊藤「失敗していても全部はケアできなくなるというか」

川口さん「それもよくあるパターンですよね。多すぎる以外にも、この失敗は修正依頼中だから無視していいんだ、とかもありますし」

伊藤「ユニットテストコードとかで、　（アプリケーション側の）コードが変わったからユニットテストも動かなくなってとかもあるんですけど、そのような死んでるコードを直してあげる、みたいなことは考えていたりするんですか」

川口さん「そういうのも、まさにLLMみたいな新しい技術が出てきて、それで対処できないの？みたいなことを多くの人が試しているように感じますね」

伊藤「ChatGPTとかでも、どうE2Eテストに適用するかみたいなディスカッションはあって、Seleniumのコードとかサイト与えたら書けた、ってなるんですけど、プロンプトに頑張って指示している時間で画面から選択して（テストを）作れるよなという懸念はあって、落ちた時に直すみたいなセルフヒーリングってちょっとしたことなんですけど、わざわざブラウザ開いてそこまで再生してみたいなのってすごく面倒くさいんですよね。そこの部分とかで、ChatGPTとかがすごく効果的なんじゃないかと思ったりはしていて」

川口さん「そうですね。（その方面の開発については）色んなチームで楽しい実験をしていると思いますよ。ここ数ヶ月のうちに知見が上がってきて、サクセスパターンみたいなものが確立されてくるんじゃないですかね」

伊藤「テストを作る、っていう大元の部分はすぐには変わらないんですけど、周辺部分はちょっとずつ改善されていくんじゃないかと思います」

川口さん「実際に、テストの原因究明とかとても時間かかるじゃないですか。素っ気ない一行のエラーメッセージを見ても、経験が長い人はこのエラーが出た時は裏のここが死んでるんだよ、って知っている、みたいなことをもっと上手くやっていきたいなと」

伊藤「E2Eテストでいうと、死んだけどその前にボタン押し損ねているとか、前の画面でチェックボックスが入っていなかったからエラーとか、結構あるんですよね。だから、エラーになった時に前回の成功時を見比べて、この辺も怪しいよとか、追加のインサイトを出せるとより早くなるなと思いますね」

続いてブラウザテストの最先端についてお話が移りました。川口さんのご質問に伊藤がお答えしています。

川口さん「（ブラウザテストについては）僕の頭の中ではSelenium, Cypressくらいで止まっていて、裏ではどういう風になっているんだっけのか、仕組みが前進しているのかが興味があって」

伊藤「そうですね、裏はそれほど大きく革命はされていない気がしますね。まずSeleniumとかも、昔はSeleniumプロジェクトの人たたちが全部頑張って書いてましたけど、今はブラウザプロジェクトの人たちが各自やるようになって、ChromeでいうとChromeDevToolとかのプロトコルが裏にあってSeleniumはそれを使っているし、Puppeteerや最近出てきたPlaywrightもそこを使ってやっているので、本質的には変わらないですね。逆にCypressは、あまりそこのインフラは使っていないはずで、クリックとかもDevToolに投げるのではなくて、JavaScriptのクリックイベントを呼んでしまうみたいな」

川口さん「へー」

伊藤「ブラウザ毎の実装はどのブラウザでも同じようにできるので楽なんですけど、その代わり、JavaScriptのアラートとかクロスドメインとか、JSで触っているが故にハマる問題とかがあるんですよね」

川口さん「僕はてっきり裏のイノベーションがあって、それをCypressが上手く使ったから流行ったと思っていたんですがそうじゃないんですね」

伊藤「そうですね。むしろ、Seleniumって初代はJavaScriptでやっていたんですよね。で、やっぱりアラートとかクロスドメインの問題があって、ブラウザ側にネイティブに処理を仕込むという風になっていったんですけど、それをやって良いこともいっぱいあったんですけど、その結果、副作用でインストール面倒くさいということも出てきて。Cypressとかは、ある意味、Seleniumの人から見ると先祖返りしているわけです。それでも、支持されているというのが興味深いですね。すごく手軽に使えるようになって支持されているっていうのは、95％くらい出来ていれば手軽さの方が重要であるみたいな」

川口さん「なるほどね。要はバランスということか」

（以上）

川口さんと伊藤さんの対談の一部を抜粋いたしました。この続きは、ぜひ動画 (YouTube) でご覧ください。