W3Cの仕様と向き合うフロントエンドエンジニアが語る、E2Eテスト自動化
Autify Podcast、エピソードを追加しました
ソフトウェアテスト、スタートアップなどにフォーカスしてさまざまなTipsや、事例などをお伝えするラジオ番組、Autify Podcastを公開しています。
今回は、Autifyのフロントエンドエンジニア 守屋さんと、テスト自動化スペシャリスト 末村さんのトークです。Autifyのテストシナリオを作成するのに欠かせない、“Autifyレコーダー”の開発の裏側や、日々の取り組みについてお話しています。
ご意見、感想はTwitterでメンションしてください。
https://twitter.com/AutifyJapan
ここからは書き起こし記事です。
末村: Autify Podcast始まります。
守屋: イェーイ
末村: ちゃんと「イェーイ」って言ってくださってありがとうございます。今日はAutifyのフロントエンドエンジニアの守屋さんに来ていただいてます。守屋さんよろしくお願いします。
守屋: はい、守屋です。末村さん、よろしくお願いします。
末村: よろしくお願いします。ちょっと最初に、簡単に自己紹介をしてもらってもいいでしょうか。
守屋: はい、守屋と言います。元々はWebの受託でいろいろ開発をやっていて。
いろいろ開発をやっていたんですけれども、社長の近澤さんとは古い知り合いで、近澤さんがAutifyをどんどん開発していくぞというふうになった時に、近澤さんから一緒に作らないかと声を掛けていただいて、Autifyに参加したという感じです。
末村: ありがとうございます。
守屋: Autifyではフロントエンドエンジニアなのでフロント面の開発一式の他に、あとは実際のテストの実行のところだとか、あとは要素を見つけるアルゴリズムのところだとか、HTMLに近しいところ全般を開発しているという感じでやっています。
末村: ありがとうございます。僕が守屋さんと初めてお会いしたのが、確か面接の時で、フロントエンド周りをやってますということだったので、何かこんな時期に。こんな時期にと言うか、当時は、確か外注の方も含めてでも3人とか4人しかエンジニアいなかった頃だと思うんですけど。
守屋: そうですね。
末村: そのくらいの時期にもうフロントエンドエンジニアがいるんだ、すごいなと思ったら、いざ入社してみたら守屋さんが全てをやっていたので、すごいびっくりしたのを覚えています。
守屋: あはは(笑)
末村: フロントエンドの幅が広すぎた。
守屋: そうですね。言っちゃえば、ほぼ全てフロントエンドに関係はしているので(笑)
末村: そうなんです。なので、我々エンドツーエンドテスト（以下、「E2Eテスト」）のソリューションを提供しているので、今までE2EテストってE2Eテストだよねっていうような理解でいたんですが、実際インターフェースになるのは結局UIのところなので、確かにUIの知見がものすごくいるよな、という感じはあって。
守屋: そうですね。
末村: それを守屋さんの動きを見て、なるほど、と納得がいった感じでございました。
守屋: はい。
末村: 守屋さんを今日お呼びしたのは、Autifyの中の面白い人たちを是非、社外にも紹介していきたいなという気持ちもありつつ、守屋さんは実はAutifyのエンジニアリングブログの記事第1号だったんですが、そこですごくディープな、文字入力をするだけでもブラウザの互換性を考えると、とてつもなくディープな世界に入っていってしまうよという。
守屋: そうですね。正確に言うと、文字を入力する前にテキストフィールドを空にするのが、すごく大変という話でした。
末村: そうでしたね(笑)
守屋: はい(笑)
末村: そう。だから、何かそこら辺の死ぬほど面白い話が、守屋さんから聞けたり出来ないかなという感じだったんですが(笑)
守屋: はい(笑)
末村: 何か、特別思い出に残ってる闇とかはありますか。
守屋: そうですね。闇で言うと、もちろんブログに書いたテキストフィールドをクリアするまでの道のりっていうのは、あれはとても印象深かったので、わざわざ記事にまでしてっていうのがあったんですけれども。 そこと少し関係があるところとして、Autifyでテストを実行する部分を作っている時に、何が1番ユニークかっていうと、どんなページをテストするか分からないんですよ。
テストを実行する対象のページが、どんな技術で作られているかとか、どれぐらい古くからメンテナンスされているものなのか、それともすごいモダンな構成で作られているのかっていうのが何も分からない状態で。 相手がどんなページであっても、ちゃんと操作を完結出来るようなものを作らなきゃいけないっていう課題があって、それがものすごくユニークな体験になっているっていうのがありますね。
なので、1番記憶に残っているのは、文字列をクリアするところっていうのはあるんですけど、結構、1個1個面白いっていうものがたくさん並んでいる印象が近いです。
末村: ありがとうございます。いや、本当にそうですよね。
僕がすごく印象に残っているのは、あるユーザーのサイトで、古いバージョンのprototype.jsを使っていると、うちのテスト実行がこけるという話があって。
それも守屋さんがブラウザのネイティブのArray.reduceを上書きしているみたいなのを見つけてきて、無限にこういうのと戦う感じになるのに、この人はニコニコしているなぁと(笑)
守屋: そうですね(笑)。 まさかテクノロジーとしては割と新しいのを触ってAutifyでいろいろ開発をやっていくぞという気持ちだったんですけど、まさかここで古いバージョンのprototype.jsと出会って、そいつとなんとかやっていかなきゃいけないんだっていうのがあったので、あれはとても面白かったものではありますね。
特に、僕は割とReactとかが出てくるもっと前、それこそjQueryを使って複雑なものを作るとしんどいよねとか言っていたような時代からJavaScriptを触っていたので、その頃のすごく懐かしい記憶が、今1番新しいプロダクトを作っている時に役に立つっていうのが、すごく嬉しかったっていうのはありますね。
末村: なるほど。ちょっと分かります。 僕、フロントエンドそこまで強くないっていうか、ちゃんと正直に言うと弱いんですけど。
弱いというか、全てにおいて弱いんですけど。
守屋: そんなことないじゃないですか(笑)
末村: 何かこう、今少しでも出来ているのは、多少jQueryおじさん的なことをやっていた時期があって、そこら辺のその時の思い出でなんとなく出来てるなという感じはあって、すごく今のお話が納得いきますね。
守屋: そうですね。 なので、その古いprototype.jsをアーカイブから引っ張り出してきてソースを読んで、こんなことやってるからこうやって避けなきゃいけないなっていうのをやったその次に、Reactの文字の入力をどうやるんだっけって言ってReactのソースを読みに行って、細かいブラウザごとの挙動の違いみたいなのを調べてしていると、すごいこう、幅広い時代をいったりきたりするような感じがあるというのが、すごく面白いですね。
末村: いや、ほんとそうですよね(笑)
守屋: いいですか。結構長くなっちゃうかもしれないですけど、ここのところで。
末村: 大丈夫です、大丈夫です。
守屋: そういう幅広いテクノロジーをサポートしなきゃいけないっていうのでいうと、例えばXHTMLみたいなのもまた出てくるんですね。
というのは、Autifyのテスト実行部分のモジュールでは結構JavaScriptを使っていて、かつページ内のHTMLの要素に対していろんなことをやるっていうのがあるんですけど。
実は、HTMLにはJavaScriptでHTMLの要素にアクセスする時に、HTMLElementというのと、Elementっていう2つのものが存在しているんですね。
ほとんどの要素は、HTMLElementなんですよ。
HTMLElementのAPIを使って、いろいろ要素の位置とか大きさを取ってきたりとか、クリックをしたりだとかいろんなことが出来るんですけど。
対象の要素がSVGだったりすると、なのでつまり、対象の要素がXMLの要素だと、HTMLElementではなくてElementになるんですね。 Elementは、いくつかHTMLElementが持っているAPIを持っていなくて、エラーが出るというようなことがあるので。
なので対象、何か特定のページでうまく動かないって調べてみた時に、そのページがXHTMLで作られていて、XHTMLのネームスペースが宣言されていると、ここのところがうまく動かないと。
そういう課題も出てきたりするっていうのがありますね。
すいません、何かいきなりすごい技術的な話をどんどんしちゃってるんですけど(笑)
末村: いや、今回めちゃくちゃ人選びますね(笑)
守屋: そうですね(笑)。分かってくれる人が聴いてくれると、すごく嬉しいなというのがありますね。
末村: これ分かってくれる人がいたら、すぐにオファーを出しに行きたい気持ちですね(笑)
守屋: そうですね、来てもらいたいですね。全部「分かる分かる」って言ってくれる人がいたら、是非来て一緒に戦っていこうというのを、お願いしたい感じですね。
末村: いや、本当にそう思います。ちなみに、HTMLElementみたいなところはつい最近僕も引っかかって。
守屋: はい。
末村: AMPのサイトでHTMLElementが上書きされてて動かないみたいなやつがあって。そういうのも守屋さんに相談するとピンポイントで、「これは上書きされちゃってますね。お行儀が悪いね」みたいなことを言われて、すごく楽しいです。
守屋: あれも面白かったですね。あの辺を見ていると、何でAMPのページがユーザーにJavaScriptの実行を許可してないのかっていうのが分かるなというか。
末村: なるほど、確かに。
守屋: ああいうふうにGoogleの側で好き勝手なことをやって、ユーザーのJSと互換性が取れない可能性が高いからJavaScript実行出来ません、で一律で切ってるんだなっていうのが、なるほどと。ストンといったんですけど。
とはいえ、うちはJavaScriptを実行しなきゃいけないので、何とかソースを読み解いて動くようにするっていうのが発生する感じですね。
末村: そうですね、面白い(笑)。ちょっと話を変えたいんですけど。
守屋: はい。
末村: 守屋さんはAutifyで大きい仕事を山のようにやってきてると思うんですが。たぶん1番大きいのって、レコーダーだと思うんですが。
守屋: そうですね。レコーダーは大きいですね、はい。
末村: ですよね。一応補足しておくと、Autifyはテストを、ユーザーがブラウザ上で操作したものを記録することでテストシナリオを作るんですが、その記録するという部分を担っているChrome ExtensionのことをAutifyレコーダーというふうに呼んでいて。そこのメインで開発したのが守屋さん。
守屋: はい、そうです。
末村: そこら辺の話も結構聞きたいなと思っていて、Chromeの話とかいろいろ、もしあればぜひ聴きたいんですけど。
守屋: そうですね。Autifyのレコーダーは、うちでフルスクラッチで作ったわけではないというか。 元々、Record & Replay を行うときに1番有名なものとしては、Selenium IDEっていうChrome Extension。
元々はFirefoxのExtensionだったんですけど、Selenium IDEというExtensionがオープンソースで存在していたんですね。
かつ、Selenium IDEをさらに機能を盛り込んだSideeXという、また別のChrome Extensionがあったんですけども、そちらもオープンソースで提供されていたので、1番最初に開発するときはそのSideeXをベースに、さらにAutifyの機能を盛り込んでいくという順番で開発を行っています。
ただ、SideeXはすごく、そちらも機能がとても多いものなので、ソースの数が、ソースコードの量がかなり膨大なものになっているんですね。
なので、まずそれをちゃんと読み解くのが大変だったというのはあるんですけど。
それを読み解きつつ、かつうちにとって、うちが使わない機能を取り除きたい、と。
取り除きたいんだけど、一部のソースをパッと消しただけだとよく分からないエラーが出てきて動かなくなるみたいなこともあるので、結局頭から尻尾まで全部読んだ上で、少しずつその内容をうちが使うものに向けて変えていくというプロセスが、最初にあった感じですね。
末村: なるほど。さっき言っていた、いろんなアプリケーションに対応しないといけないみたいなところで、実行の他にレコーダー特有のものとかあったりしますかね。
守屋: あります、あります。このレコーダーもテストの実行のところと同じで、どんなWebサイトで実行されるか分からないJavaScriptを作らなきゃいけないと。
かつ、基本的にページでディスパッチされたイベントを拾ってきて、ユーザーがこんな操作を行ったっていうのを解釈して保存していく流れになっているんですけれども、対象のアプリケーションがどういう作り方をしているか分からないし、もちろんそのアプリケーションを作っている人は、それがさらに別のレコーダーでレコードされるなんてことは全く考えてないので、みんな、当たり前なんですけど好きに作るんですね。
そうなってくると、例えばなんですけど、対象のページでひとつあったのは、例えば入力フィールドにフォーカスをするとかブラーをするみたいなのって、そういう操作を行うとイベントが、フォーカスイベントとかブラーイベントみたいなものが飛んでくるんですけど、Autifyレコーダーはそのイベントを拾ってここの入力フィールドをフォーカスしたなとか、ブラーしたタイミングで値が変わってたらテキストを変えたんだなみたいなふうに解釈をして、コマンドをレコードしていくわけなんですけど。
レコーディングがうまくいかないっていうページがあって調査してみると、そこのページがブラウザがディスパッチするのと違う自分たちのブラーイベントとか自分たちのフォーカスイベントみたいなものをディスパッチしていて、それがこちらの想定と全く違うタイミングでディスパッチされているので、レコーダーがよく分からないことになっちゃう。
そういうページがあったりするので、ちゃんと飛んできたイベントが、これ本当にブラウザから飛ん出来たものなのっていうのも、一旦全部確認をして。
なので、普通に開発するときは疑わなくてもいいところも全部疑った上で、これで大丈夫かっていうのを確認した上でレコードしていかなきゃいけない、っていうのがひとつ難しいところであったりはしますね。
他にも言うと、対象のアプリケーションが、例えばプロダクション環境でテストをしたいみたいなケースを考えると、普通のテスト環境では入れないような外部サービスとか、外部のモジュールみたいなものが読み込まれているケースっていうのも多くて。
1度経験した中で1番すごかったのは、ページが表示をされて、その少し後にページの中身を全部書き換えるっていうライブラリが入っていたことがあるんですね。 そこの書き換え方もなかなかアグレッシブで、これはまたかなり技術的な話になっちゃうんですけども。
ページの読み込みが終わった後に、ドキュメント要素を open して replace して close するみたいな操作を行っていたんですね。 そうすると何が起こるかというと、全てのイベントリスナーが飛んじゃうっていうことが起こるんですね。 これはwindowオブジェクトにつけたイベントから何から全部どこかにいっちゃう。
なんだけど、それに気づく手段がないみたいなことが起きることがあって。
なので、これもそんなことやめてくれよって言いたいのはこちらも山々なんですけど、それをこちらから言うことは出来ないので、何とかしてそういう現象が起きた時に、ちゃんとまた復旧してレコーディング続けられるように何とかすると。
みたいなものも作業として入っていたりします。
末村: ありましたね、そんなの。すごくよく覚えています。
守屋: はい。
末村: その話を聞いた時に、こんなの絶対無理やろうと思っていたら、次の日ぐらいに守屋さんが出来るのでいつぐらいに必要か教えてくださいみたいなのを言っていて、いやぁ、すごいな(笑)
守屋: あはは(笑)。何かこう、知恵比べみたいな感じになってくるんですよね。
向こうがこっちの想定していなかったことをやった時に、それでもこちらがレコードし続けられるために何が出来るのかっていうのを、これまで読んだことなかったW3Cの仕様とかいろいろにらめっこしながら、この方法だったらいけるかもしれないっていって試してみるというのを、繰り返す感じでやっています。
末村: なるほど。
守屋: はい。
末村: さっき話を聞いて思い出したんですけど、レコーダーじゃなくて実行の方の話なんですけど。
守屋: はい。
末村: 守屋さん、フロントエンドエンジニアだと聞いていたのに幅広すぎるっていう話の中で、WebDriverの仕様を、W3Cのspecificationを守屋さんが読んでいるのがすごい面白くて(笑)
守屋: そうですか？(笑)
末村: あれ、これフロントエンドエンジニアの範疇だったっけ、みたいな(笑)
守屋: Autifyのフロントエンドエンジニアの範疇ですね。
末村: 結局そうなんですよね。それもそうだし、僕もやっぱりそこら辺ちゃんと読んだことなかったので、そういうのをちゃんと読んでるエンジニアがここにいるんだな、すごいなっていう気持ちに溢れていて。 それからちゃんと心を入れ替えて読むようになったんですけれども、僕も。
守屋: WebDriverのW3Cの仕様は、読んでいて結構面白いですよね、あれは。
末村: あれは面白いですよね。
守屋: すごく、元々SeleniumのところからW3Cに仕様が移行した経緯があって、かつSeleniumの歴史的経緯とか遺産がたくさんあるので、それをどうにかこうにか仕様のところと整合性をつけるというか、何とかそこを上手く統合しようっていう、苦闘の跡がいろいろ見て取れて、読んでてすごく面白いっていうのがありますね。
末村: 分かります、分かります。仕様、楽しいですよね、結構ね。
守屋: うん。
末村: 全然関係ないんですけど、あれ何だったっけな。Basic認証の仕様、HTTP AuthenticationのRFC、何種類かあるんですよ。
松浦さん、弊社CTOの松浦さんとBasic認証の話をしていた時に、このRFCによるとこれこれこうだからこれは違うんじゃないのって俺がツッコミを入れたら、松浦さんから、これは古いやつだから最新はこれだよっていう話をされて、変遷がすごいあるんだなって(笑)
守屋: あはは(笑)。本当にRFCは量が半端じゃないし、ひとつひとつのドキュメントがめちゃくちゃ長いから、あれ大変ですよね(笑)
末村: 大変です、大変です。本当に。でも、既存のプロトコルをちゃんと理解するのに仕様を読むのは当然大切なんだよなっていう、当たり前のことを。
すごく当たり前のことを、俺は嚙みしめました。
守屋: あれは。でも、こんなに仕様を読んで、こんなに実プロダクトにダイレクトに反映をしていけるプロダクトっていうのも、僕の経験としては結構珍しいなっていうのがあって。
末村: 珍しいですよね、分かります。
守屋: 大体プロダクト開発している時って、うちのユーザーにとってこの機能が届けられるっていうのがもちろんゴールになるんですけど、Autifyを作っている時って、こういう挙動は可能性としてあり得るのかとか、見たこともない動きをしているものが、これは変な作り方をしているのか、自分が知らない機能がどこかに存在しているのかみたいなのを確認する必要があるので。
いちいちちゃんと仕様にあたって、これはこうだからこうとかこういう可能性もあり得るからこうしなきゃいけないとか、そういうのがダイレクトにプロダクト開発にフィードバックされていくっていうのが、すごい面白いなと思ってますね。
末村: 分かります、分かります。すごい、よく分かります(笑)
守屋: こういう、さっき言ったそのドキュメントが入れ変えられちゃうとかブラーのイベントが、みたいなものって、修正している時に1番思うのって、これもし自分がそのプロダクトを開発している立場で、うちの会社のプロダクト、E2Eテストやってみようっていってこのエラーで落ちたら、自分の会社のプロダクトをテストするためにこの問題を解決するの無理だなっていうの、すごい思うんですよ(笑)
そんなのやってる暇があったら機能開発やった方が絶対いいし、自分のユーザーにとって嬉しいだろうっていうのがあるので。
ただその点Autifyでやってると、この問題をうちで1回解決しておけば、同じ問題に直面する全部のお客さんが、その問題に遭遇しなくて済むことになるので。
すごいマイナーなケースだったり、すごいエッジケースでしか起こらない、かつ解決が難しいような問題っていうのを、ちゃんと1個1個解決をしていく。 かつ、それがちゃんとプロダクトの価値に反映されていくっていうのは、なかなかAutifyならではだな、と。 Autifyならではで面白いなと思いつつ、E2Eテストの闇ってこんなに深いものかっていうのを、すごく思うところではありますね。
末村: いや、本当にそうですね(笑)。そこら辺の話を、何だろう。守屋さんから隣に座ってチョロチョロ聞いていた結果が、昨年僕がビズリーチさんで登壇した時のクロスブラウザテストのスライドに凝縮されていて。 これを聴いている方に是非お詫び申し上げたいんですが、あれの元ネタは守屋さんです(笑)。
守屋: そうです、一部そうですね。でもたぶん、起動するまでが大変みたいなところが、末村さんが調査してたところですよね。
末村: あれはそうですね、あれはでも。
守屋: 面白かったです(笑)
末村: 登壇するために調べていたもんなんで、あれ(笑)
守屋: はい(笑)
末村: 一応、話をする前にいろいろ裏付けを取っておこうと思って調べていたら、そもそもIEが動かないみたいなやつが、全てあそこに凝縮されているので(笑)
守屋: あれはめちゃくちゃ面白かったですね。なので、あれまだ見たことない人がいたら是非お勧めをします。E2Eテストの闇の話を聴けるかと思ったら、E2Eテストが始まらないっていう、すごい面白いスライドになってますね。
末村: ありました、ありました(笑)。何か、そういうコメントを”はてぶ” でももらったような気がする。
守屋: うん。
末村: ちなみに守屋さん、元々Webの受託開発をやっていたと思うんですけど。
今はE2Eテストのプラットフォームを作ることをしていて、元々受託やっていた時に、E2Eテストをそもそもやっていたりとか、こういうのがあったらいいのにな、みたいなのって何か思ったりしたのはありました？
守屋: そうですね。僕のやっていた受託開発って、本当にアプリケーションではなくって、どちらかというと広告よりのキャンペーンサイトだとか。
こんな新商品が出るからっていって、1ヶ月、2ヶ月の間だけ開かれて、アニメーションでボンボンいろんなものが動いたりだとか。 あとは、時代的にTwitterキャンペーンで、Twitter連携して、何かつぶやくとページで何かが起こってみたいな、そういうものをよく作ってたので、もともとあまり長期間メンテナンスするっていうものは作っていなかったんですね。
なので、テストについても例えばお客さんに納品する前に1個1個リンク切れがないか確認するとか、そういうものをやっていたっていう感じですね。 なので、その時は全然E2Eテストみたいなイメージは持ってなかったですね。
末村: ふぅん。
守屋: はい。ただWebの受託をやっていた時に一時期モバイルアプリを作っていた時期もあって、iOSとAndroidの開発をやっていたんですけど。
そこでは、iOSもAndroidもテストのためのライブラリが結構充実していて、それがオフィシャルに提供されているテストツールで、かなり簡単にクリックして、クリックじゃないか。 ここをタップして、ここにテキスト入力して、どうこうしてっていうのを作るだけで、かなり簡単にアプリのE2Eテストは作れたんですけど。
実際に作って回してはいたんですけど、やっぱり割と少人数の開発だったので、作ってもそのテストのメンテナンスが大変だったっていうのがすごくあって。
メンテナンスに割いている労力があんまり見合っていない気がするだったり、機能を開発してた方が皆が喜ぶっていうのがあったので、結局そこはすごく簡単なテストだけ作って、あまり充実させていなかったっていう過去はありましたね。
末村: なるほど。
守屋: その時に直面していたのは、テストの作り方として Record & Replay 的なものがあるんですよ。
シミュレーター上でアプリを立ち上げて、それを操作するとテストコードが生成されて、それをそのままテストでも回せるっていうのがあったんですけど、それだと生成されるソースコードが割と汚いというか、パッと見た時に何をやってるか全然分からないっていうのがあったので。
それで生成をして動いて、わぁ面白い、というところまでは行ったんですけど、それをじゃあ実際メンテナンス出来る形にまで手で整えていこうというところまで、労力を割くことが出来なかったっていうのはありましたね。
末村: なるほど。ちょっと話が戻っちゃうんですけど、受託で1回納品してればいいからみたいな話で、やっぱり結構うちのサービス自体がアジャイルチームというか、息の長いプロダクトに対するアプローチというような感じは前からしていて。
もっと、なんだろう。ライフサイクルの短いプロダクトに対するアプローチって、何かあるのかなみたいなのを、結構思いますね。
守屋: そうですね、本当にそうですね。それが簡単に作れたら絶対役に立つんですよね。
末村: うん。
守屋: やってない理由は、作ったりメンテナンスするのが大変で、サイクルが短いと、労力に対して得られるものが見合わないからやらないだけで。
それが、簡単に作れて簡単にメンテナンス出来るんだったら、絶対皆やるものだと思います。
末村: うん、そうですね。
守屋: うん。本当欲しいですよね。受託で開発やってた時の自分にも、そういうツール、それこそAutify、プレゼントしてあげたいみたいなところはありますね(笑)
末村: いやぁ、そうですね(笑)
守屋: これポチポチやったら、あとはもう実行って押したら全部通ってくれるんだよって言ったら、わぁ、ありがたいって言ってくれるだろうなって気持ちがあるんで。
そういう気持ちはあります。
末村: 確かに、確かに。そうですよね、話繋がってるかわかんないんですけど。
守屋: はい。
末村: ライフサイクルが長いものも短いものもっていうようなところで、ライフサイクルが長くても、ものすごくアップデートの頻度が高かったりみたいなので、シナリオ自体がそもそも破綻しちゃったりとかっていうケースは、やっぱりありそうな気はするので。
簡単に、すごく簡単に、あるいは自動的にシナリオが作られるみたいな未来があると、やっぱりそこら辺は楽になるんだろうなという感じはありますね。
守屋: そうですね。今のRecord & Replayでも、もちろんコードを書くよりはだいぶ楽ではあるんですけど、本当は自動で作られると嬉しいよねとか、何かそういうのはありますよね。
末村: そうなんですよね。何かこう、結局いろいろ網羅するのが大変っていうところではあるので。
守屋: うんうん。
末村: いろんなものを網羅して、みたいなのを勝手にやってくれると嬉しいなという気持ちは、やっぱりあるよなと、今聞いてて思いました。
守屋: ほんとそうですよね。網羅をするっていう仕事は、人間のやることじゃないなというか。 本当は自動でやってくれるのが1番いいよな、と思っていたりはしますね。
末村: そうなんですよね、本当に。何だろう、今結構テスト界隈というか、僕の周りだけかもしれないですけど、アツイのは、テストケースをきちんと網羅するっていうのは、やっぱり結局組み合わせ爆発になっちゃったり。
守屋: うんうん。
末村: あるいは、その中から有効なテストケースを選択するみたいなところが、相応のスキルがないと難しかったりみたいなところを。
いろいろあると思うんですけど、そこら辺から形式手法に興味を持つ人が、結構最近多いなという印象があって。
僕、なんか話を始めたんですけどそんなに詳しくなくって(笑)
守屋: (笑)
末村: そこら辺、結構ある程度仕様の矛盾を検査するためのものっていうぐらいの理解でいるんですけど。
守屋: うんうん。
末村: すごくライフサイクルが短くて、そもそも仕様みたいなのがなくて、あるいはきちんと考えて、要は形式手法とかもある程度ライフサイクルが長いものに対してのアプローチだと思うんですよね。
守屋: そうですよね。
末村: 分かんないですよ。その道の人に聞かれると、結構突っ込みどころが多いのかもしれないですけど。
守屋: ちょっと怖いですね、僕も全然詳しくないので(笑)
末村: 怖いですね、ドキドキする(笑)。ライフサイクルがすごく短いものに、どこまで有効か分かんないけれど、組み合わせをザーッと流してテストするみたいなアプローチは、結局やっぱり必要そうな感じはすごくしていて。
守屋: そうですね。組み合わせのところで言うと、何て言うのかな。
本当に形式手法で全てのパターンをチェックしようと思うと、まず始めとしては自分のアプリケーションの仕様っていうのを形式手法の言葉に置き変えて、全てのパターンを網羅出来るような形に翻訳をする必要があるっていうのがあると思うんですけど。 個人的に思ってるところとしては、アプリケーションの仕様って共通のものがすごく多いじゃないですか。
例えば1番あるのは、ユーザー登録する時にパスワードがこれぐらい複雑じゃなきゃいけないですよとか、何文字以上何文字未満とか。 ほとんどすべてのアプリケーションで、そんなに独自なことをやらない場所ってたくさんあって。 かつ、そういうところが結構大事な機能だったりするじゃないですか。
末村: うんうん。
守屋: なので、そういうところに関しては、自分のアプリケーションの仕様を厳密に定義するというよりは、よくあるベストプラクティス的な仕様の中から、うちはこういう方向を取りたいっていうのを選んだら自動的にその観点でテストをしてくれて、その仕様に沿った実装が出来ているか確認が出来る、みたいなことが出来るといいんだろうなっていうのを、フワっと思っていたりはしますね。
末村: なるほど。確かにそれはいいですね、いい感じの未来がありますね。
その辺のある程度枯れているユースケースに対するものって、そもそも実装がOSSで提供されていたり、すごく著名なプロプライエタリなライブラリがあったりして、そっちの方で既にテストがされているみたいなこともちょっと思ったりするんですけど。
守屋: はい。それもあるとは思うんですけど。
末村: 何か、そういうのじゃなくって？
守屋: はい。ユーザー登録のところとかは、確かにオープンソースのところとかで出来ると思うんですけど、もうちょっと違う仕様のところ、パッと例が出てこないな。
さっきの話とすごい矛盾しそう。カスタムの挙動入れたい時にとかって言ったら、さっきと話と違うやんってなりそうなんだけども。
末村:(笑)
守屋: そうですね。確かに、ライブラリの元々提供している機能に沿った、そのままの機能しか使わないっていうのであれば、それはそれで安全で、その通りにやればいいと思うんですけども。
時々ライブラリの挙動ほとんどいいんだけれどもここだけちょっと変えたいとか、うちここのところだけちょっと挙動違うんだよなっていって、ちょっとカスタムしたりするような時ってあるじゃないですか。
そうした時に、カスタムの仕方が、特にオープンソースのよく出来たライブラリを使ってたりする時って、正しくない場所をいじっちゃって挙動が予期せぬところで挙動が変わっちゃってるみたいなことも十分あり得ると思うんですね。
そうした時に、それがライブラリのデフォルトの挙動じゃなかったとしても、イメージとしてはブロックの組み合わせみたいなもので仕様が表現出来ないかなと思っていて。
例えば、ユーザー登録であれば何文字以上でかつ記号はこれが入っていなきゃいけない。
かつ、一般的にこれは記号とみなされてるけど、これうちのサービスのアイディア使って欲しくないとか。
そういう細かい仕様のところとかも、それを本当に厳密に表現しようと思うと、なかなか大変になってくると思うんですけど。
それを、どこかである程度網羅性を持った仕様の表現っていうののライブラリみたいなものがあって、それの組み合わせで自分のところの仕様を表現出来るようになったりすると、すごい素敵だなと。 かつ、本当に100%網羅出来る表現を自分で書くっていうことが出来る人って、すごい少ないと思うんですよ。
末村: うんうん。
守屋: なので、それを全ての人に求めるのはやっぱり酷で。
やっぱり、よくあるパターンみたいなものがある程度網羅されているものを、それをちょっとピックアップして組み合わせて、ピックアップして組み合わせることで、何かの表現が作れるみたいな形の方が、ふさわしいんだろうなと思っているところですね。
末村: なるほど、何か結構理解出来ました。結局、やっぱり組み合わせとかカスタマイズとか、そこら辺のですよね。E2Eで見たいところというか。
守屋: そうですね、何か、そう。なので、これってちょっと、同じ考え方なのでちょっと話ずれるんですけど、E2EテストでAutifyでテストを作る時にも、1個、人によってスキルのばらつきが出るところがあるというか。
Record & Replayでテストが作れる時に、ものすごく楽にはなるんですね。
要素を選択するときにロケーターを手で書かなくていいとか、全部のステップにスクリーンショットがついていてテストの流れが分かりやすいとかっていうのはあるんですけど。
実際に、例えばアサーションを作るといった時に、このページが正しく挙動をしているということを確認出来るアサーションって何だ、っていうのを考えるのってなかなか難しくて。
末村: うんうん。
守屋: そこを、1番単純な方法としては、片っ端から要素をアサートすることで、全部正しいということを確認するっていうことは、可能は可能なんですけど、そうするとテストでやりたかったところと関係なかったことで失敗しちゃって、結局メンテナンスするのがしんどくなっちゃって、メンテナンスしないみたいなことになり得るので。
出来るだけアサーションは少ない方がいいけど、減らしすぎて本来テストしたかったことがテスト出来なくなっちゃうと、それはそれで本末転倒になってしまう、というところがあるので。
理想的にはそこって、テスターさんの持っている、ある種アートのところだと思ってるんですね。 そのページに対して最も効率的なアサーションの作り方、効率的かつ効果的なアサーションの作り方を見抜いて、それを作って回していくっていうのが、アートの部分だと思うんですけど。
今、そういうすごい高いレベルのアサーションを作れる人っていうのは、やっぱり限られていて。
出来るだけ多くの人が効率的にテストを作れる未来っていうのはどういうふうに作れるかなっていうのを考えると、そういうアートの部分を、さっき言ったみたいな共有ライブラリ的なところに蓄積をして、それを皆が使えるように。
例えば、このアプリケーションに対してはこういうパターンが、こういうパターンのアサーションがいいよねみたいな、ある程度プリセットされたものでテストを作っていけるようになれると、皆が効率的にバグを発見出来る未来が出来るんじゃないかなというのを、思ってたりしますね。
末村: ありがとうございます。
守屋: すごい、長い話になっちゃった。すいません(笑)
末村: いやぁ、こういうのはいいですね。聞いているだけですごく楽しいですね。リスナーの方にもご満足いただけると信じております。
守屋: だと嬉しいです(笑)
末村: じゃあ、だいたいこのぐらいで、たぶん取れ高OKだと思うんですけど。
守屋: OKですかね。うまく言えてんのかな、ものすごい不安だな(笑)
末村: いやいや、大丈夫です、大丈夫です。問題ないですよ。普段の俺のやつを聴いてる方からすると。 普段の俺のやつ。俺ひとりで喋ってるやつとかを聴いてる方からすると、今回はすごくいい、という感じになると。
守屋: いや、末村さんすごいだって喋り上手いじゃないですか。
末村さんいろいろ登壇されているんで、いつも陰ながら聞いていて、「末村さん話うめぇなぁ」っていうのを、いつも聞いて思ってたりしてます(笑)
末村: そんなことないです、そんなことないです。16分の1の確率で、上手い言葉が出てくるみたいな、そういうbotなので。
守屋: 末村さんガチャが回ってるんですね(笑)
末村: そうそう、そうなんですよ。ガチャって考えると結構高いな。10連に2回当たったら。
じゃあ、今日はそんな感じで。守屋さんから何か最後ひと言。リスナーの方に是非みたいなことはありますか。
守屋: はい、リスナーの方に是非(笑)
末村: あるいは、Autifyのここがいいよ。
守屋: ええと、ちょっと待ってください。ちょっと考えさせてくださいね。Autifyのここがいいよ。
末村: プロダクトでもいいし、何だろう、会社の採用に繋がるようなことでも。
守屋: そうだな、何言えばいいんだろう。
どういうの言えばいいんだろう、どういうの言えばいいですか？ここがいいよ(笑)
末村: じゃあ、おすすめの漫画、アニメ、ゲームでもいいですよ。
守屋: おすすめの漫画、おすすめの漫画。おすすめの漫画か…。おすすめの漫画でいうと、最近チェンソーマンが1番面白いですね。
末村: やっぱりチェンソーマンなんですね。
守屋: チェンソーマンは、めちゃめちゃ面白いですね、あれは。
はい、読めば読むほどどんどん面白くなってくので、本当に作者の方にありがとうございますと思いながら。 こんな面白い漫画を週間で書いてくれてありがとうございますと思いながら、新刊を待ち望みにしているというような感じですね。
末村: 本当に、われわれは藤本タツキ先生に足を向けて寝られないですね。
守屋: 本当ですね。いや、本当に面白いので。しかもどんどん面白いので。感謝の気持ちを持ちながら読んでます(笑)
末村: 本当に。
守屋: あと、そうですね。おすすめのゲームでいうとちょっと古いんですけど、最近ピクミン3で遊んでいてですね。
ピクミン3は、あれはチームで開発をしている時にすごくいいなと思うんですけど。 あのゲームってこう、何ていうか。ほとんどマネジメントゲームなんですよ、ピクミン3って。
どういうことかというと、異なるタレントを持ったピクミンたちがたくさんいて、いろんな障害物があるステージが広がっていた時に、どうやって最大のスループットを実現するかっていうのを考えながらやると、めちゃめちゃ面白くって。
だからこの、水に入れるピクミンがこれぐらいの数いて、水の中にこんな物がこれぐらいあって、他のピクミンがこれぐらいいて、それで限られた時間があった時に、どうやったら1番たくさんフルーツを宇宙船に持って帰ることが出来るのかなっていうのを計画しながらやっていくと、とてもエキサイティングなゲームだなというのがあって超面白いです。
末村: ははは(笑)
守屋: 最近、あれですね。5月に子供がずっと家にいたので、なんとか子供と時間を潰せる方法を考えようっていうので古いゲームを引っ張り出してきた時に、ピクミンが子供に刺さったので、それを横で子供に見せながらピクミンを遊んでたりするんですけど。
そうすると、こうやってチームで開発している時に遊ぶと、改めてめちゃめちゃ面白いなというのがあって、それが最近の発見でした。
末村: なるほど。話が弾むようだったら第2回もって思ってたんですけど、これはあれですね。エンタメ特別編みたいなものをやった方がいいです。
守屋: ははは(笑)。いや、もうピクミン3の話でもいいですよ。ピクミン3の話でもいいですけど(笑)
末村: それやるにあたっては、俺がピクミン3をやってこなきゃいけないわけじゃないですか(笑)
守屋: そうですね。あれはでも、是非やるととても鍛えられる感じがあるので、面白いですよ(笑)
末村: 分かりました、了解です(笑)
守屋: もしくは自分で遊ばなくっても、それこそRTA動画とかを見ているだけでも、すごい限られたリソースを使ってこの時間の中でこんなアウトプットが出せるのかっていって、見てて気持ちがよかったりするので、そういうのもおすすめですね。
末村: ピクミンがRTAあるんだ(笑)
守屋: いや、ピクミンはあれはRTAにすごい向いてるゲームなので、めちゃめちゃ面白いですよ、はい。
末村: 僕のおすすめのRTA動画は、リングフィット アドベンチャーです。
守屋: あれはもうリアルの、リアルなやつですね、本当に(笑)
あれまだ動画を見てないんだよな。かなり過酷なやつですよね。
末村: 過酷です。何か、特別編に回してもいいんですけど、運動強度が1から30まで選べて、1でやるやつと30でやるやつあって、30でやるやつが本当に地獄。
守屋: ははは(笑)。自分実際やったことないんであれなんですけど、体によさそう。いいのか？ 体に悪い。
末村: いや。全ステージプレイすると45時間ぐらいあるんですけど。
守屋: はい(笑)
末村: 45時間ノンストップでやった人がいて、ちょっと全部見きれてないんですけど。最初の方でいろいろこう、プレイ中に補給する食材とかを用意するんですけど、全部流動食なんですよ。
守屋: やばいっすね(笑)。あんまり体によくない感じがしてきましたね。
末村: ウィダーインゼリーとか、そうそう。すごいドキドキしますね。あれをやれと言われたら、絶対にやれないなと。
守屋: そうですね、トイレとかどうするんだろうとか、事故が起こったらどうするんだろうって、ちょっと思ったんですけど、あんまりあれですね(笑) 公の場で話さない方がいい話になりそうですね。
末村: そうですね。いや、本当にそう思います(笑)。じゃあ、楽しい感じになったところで、一旦ここで締めたいと思います。今日はありがとうございました。
守屋: はい、ありがとうございました。
末村: はい、また次回もお楽しみに。
守屋: はい、お楽しみに。ありがとうございます。
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。
.jpg)
.jpg)
