実行環境のメンテナンスにもテストのメンテナンスにも強みがある　QAチームのリーダーが語る、mablを採用した理由と運用時の活用法

自己紹介とアペルザのプロダクト紹介

佐々木邦彦氏（以下、佐々木）：株式会社アペルザのQAチームのリーダーをやっています。アペルザはオフショアでQAチームを持っているので、オフショアの管理やマニュアルテスト、テスト自動化、ユニットテストもちょっと書いたり、簡単なリファクタなどもやっているので、SETに近い役割をやっています。

藤原大氏（以下、藤原）：ありがとうございます。プロダクトについて教えてもらえますか？

佐々木：アペルザは、メーカーや商社向けのCMSやECを提供しています。

藤原：開発の体制や流れはどうなっているかを教えてもらえますか？

佐々木：ビルドやデプロイはパイプラインで自動化できていて、あとはE2Eがmablとほかにも動いているものがあります。

藤原：（mabl以外に）Gaugeが動いている点は、Ubieさんと同じですね。ありがとうございます。それ以外だと、時間があれば探索的テストや新機能のマニュアルテストでオフショアを使っているという感じですかね。

佐々木：はい。

並列実行と実行時間の短縮をしたくてmablを採用

藤原：ありがとうございます。ではさっそく質問ですが、まずなぜmablを採用されたのかを教えてもらえますか？

佐々木：mablを採用する前は、Gaugeというフレームワークを使ったE2Eを動かしていました。それはマークダウンで書いたシナリオをSeleniumで実行してくれるというツールですね。

これをオフィスの余ったMacBook Airにセットアップして動かしていたんですが、ChromeDriverがアップデートすると動かなくなったり、OSのバージョンアップでスリープになっていたりで、なかなか実行環境が安定しませんでした。

PC1台で動かしていたので、並列でもなく朝からE2Eを流して午後1時ぐらいまでずっと動いている状態が続いていたため、並列実行したい・実行時間を短縮したくてmablを採用しています。

藤原：ありがとうございます。そうですよね。今だと、まさにリモートでやっているから、なんかのタイミングで落ちると「誰がスイッチ押しに行くねん？」問題が起きちゃう（笑）。

佐々木：「オフラインになっているんだけど、どうしよう？」みたいな状況ですね。

藤原：そうそう。僕もメルカリ時代にそういう問題がしょっちゅうありました。それで今はmablでステージのリグレッションを担当していて、Gaugeは徐々にmablに移行していっているけど、Gaugeがなくなることはたぶんないだろうな、という感じなんですよね。

佐々木：そうですね。ちょっとJavaでゴリゴリ書いちゃった部分もあるので。なかなか引っ越すのも重たいところなので、そこは残っていてもいいかなと思っています。

藤原：確かに。ここはmablが苦手という部分があるはずなので、きっとそういうかたちで残るんだろうな、という気はしますね。ありがとうございます。

テストケースの管理方法

藤原：じゃあもう1個。次の質問をすると、「運用のポイント編」です。ここらへんのノウハウの塊は、佐々木さんのチームや開発者さん、アペルザは持っていると思うので、テストケースの管理について、ぜひ教えてほしいです。

いろいろなお客さまが気にされていて、けっこう聞かれるので。テストケースをどのように自動化・マニュアル管理しているかと、作成時にE2Eのテストを作る時のポイントを教えてほしいのですが、お願いできますか？

佐々木：マニュアルテストもmablのE2Eも、両方ともスプレッドシートで管理していて。マニュアルテストはマニュアルテストで、E2EはE2Eで、別々のスプレッドシートで管理しています。今画面に出してもらっているものがそうです。

藤原：サンプルで作った資料ですね。なるほど、ありがとうございます。マニュアルテストはたぶん今までどおりの手順や項目が書かれていて、テスト自動化部分は、まさにこういう感じで管理されているんですよね。

佐々木：そうですね。

藤原：ポイントとして機能の一覧が書かれて、大項目・中項目・小項目みたいな感じで書かれているイメージがあるんですが、どういう基準でこの一覧を作りましたか？

佐々木：基本的には、広く浅くカバーしたいという思いがあって作っています。

藤原：なるほど。やはり網羅性に関しては、そこまでという感じなんですかね。

佐々木：1個1個のバリエーションについてはそこまで追わないようにしていて、いくつかあるバリエーションの中で大事なものが1つとおれば、その機能はいいかなと思っています。

藤原：ありがとうございます。あと優先度ですかね。「S、A、B、C」の部分について、どうやって決めているのかを、もうちょっと詳しく教えてもらえますか？　

佐々木：優先度と書いてあるのは、これはそのまま障害が起きた時のレベルを使っていて。Sだと、Sの障害が起きてお客さまにすごい迷惑がかかるので、インシデントのレベルをそのまま引き継いで、優先度にも使っています。

藤原：ということは、たぶんSのE2Eが落ちたら、S級のトラブルってことなんでしょうね。

佐々木：そうですね。

藤原：非常にまずいですよね。これを作るときはこの優先度順に作りましたか？

佐々木：そこは優先度順に作りたいとは思っていましたが、最初はmablで作りやすいところから作っていきました。

藤原：仮に新しい機能ができた時は、どうやってここに加えていますか？

佐々木：新しい機能ができた時は、普通に行を追加して優先度を決めます。行を先につけておいて、それをいつ作るかはまた別で管理しています。

藤原：なるほど。新しい機能は、できたら必ずここに追加されるということですか？

佐々木：今はそうなっていないです。

藤原：そこが知りたいですね。

佐々木：アペルザはわりと機能を小さく作ってリリースして、ちょっと育てていくかたちをとっています。最初からガッツリ作るとまたすぐ作り直し、とまではいかないけれど、メンテナンスはしなきゃいけないので、ある程度機能が成熟してきてから作るようにしたいな、と思っています。

藤原：まずはちょっとだけやって、みたいな感じなんですよね。

佐々木：そうですね。

藤原：とてもわかりやすいです。このアペルザパターンは、けっこういろいろな会社さんも、同じような感じでやっていますね。アペルザさんの場合は、もともとGaugeがあったので、置き換えが楽な部分もたくさんありますが、マニュアルだとそもそも項目を整理するところから始めなきゃいけません。

だいたいマニュアルのテストは網羅しているので、それだとバリエーションが多すぎちゃうので、こういう大項目・中項目というすごくいい感じですね。しかもこのインシデントの大きさで分けているところは、とても参考になるなと思いました。確かに、一緒にmablとかでテストを作っている時も、「これはSかAか？」みたいな。このあたりけっこう悩んで議論しましたもんね。

佐々木：最初はしましたね。

藤原：なんかね、全部Sにしたくなるんですよね（笑）。

佐々木：そう。結局全部Sになりそうなので、そこをAとかBに落とす意識をしないと、全部Sになります。

藤原：全部Sになっちゃいますよね。とてもおもしろいと思います。

運用のポイントや既存テストのマイグレーション方法

藤原：もう1個が、やはりテストの自動化。既存のテストケースはもちろんあるとは思いますが、運用のポイントや既存のテスト。今だとGaugeだと思いますが、Gaugeからのマイグレーションなどをどうやっているか教えてもらえますか。

一応今やっていることのサンプル図はこちらで示します。

佐々木：ありがとうございます。Gaugeからのマイグレーションはそんなに積極的にやっていないです。とりあえず動いているので、急ぐ必要もないのかなと思い、少しずつやっています。mablに移す時にアカウントを整理して移したりはやっていると思います。

藤原：ありがとうございます。やはりあまりそこを積極的にやっていない、というのがきっとポイントなんですよね。ただ、私は佐々木さんと一緒に働く機会がまだあるので。これも実際の資料をもとに作っていますが、やはり本当にコツコツですよね。Sが80を超えて90超えるみたいなのに数ヶ月かかったりとか。しかも機能が増えたら下がるんですよね（笑）。

佐々木：そうなんです。

藤原：そうそう、パーセンテージが下がるから。なかなか100を目指すとかそういうことはちょっと違うなっていうのは、やはりやっていて思いますよね。

佐々木：そうですね。もちろん100パーセントを目指したいというのはありますが、リリースが毎月あるので、100パーセントは来ないかなと思いながらコツコツやっています。

藤原：なるほど。Sは100パーセントにしたいぐらいだけど、言ってみれば毎月リリースがあるから、たぶん100になることはほとんどないとは思います。やはりここも、重点的なプロダクトとか機能、もしくは育てて伸びてきたかなという時点で機能を作っていく、E2Eを作っていく感じなんですかね。

ありがとうございます。おもしろいですね。このあたりのコツコツ感はとてもいいですよね。70だったものが90になっていることをあとで振り返ったら感動しますね。

佐々木：そうですね。

藤原：だいたい今mablとGaugeの割合は、どれぐらいになっているんでしたっけ？

佐々木：今はmablがたぶん多いと思います。

藤原：きっと半分を超えている感じなんですね。

佐々木：そうですね。

E2Eテストの実行タイミング

藤原：なるほど、ありがとうございます。じゃあ次の質問にいきたいと思いますが、まだ運用のポイント編ですね。mablの場合だとクラウド上で実行できたり、ローカルで実行できたりすると思いますけど、どういうタイミングでE2Eテストを実行しているかを教えていただけますか？

こちらもサンプルが一応あるので。僕のワークスペースのサンプルをちょっといじって似たような感じに仕上げておきました。

佐々木：基本的には先ほどのスプレッドシートでレベルをつけていたので、レベルごとにPlanを作ってそこにテストを追加して実行しています。レベルSはmablの実行回数に余裕があれば毎日動かしたい、Aも動かしたい、レベルBとかだったら週に1回ぐらい動けばいい、というレベルで、実行の回数やタイミングを調整しています。

藤原：なるほど。実行タイミングとして、テストケース自体にもいろいろラベリングをしていて、レベルSであるとかログインみたいなカテゴリの話とか、あと本番向け、ローカル向けのラベルをつけていたり。

あとはmablの場合だとPlanというものでテストを束ねて定期実行する、いわゆるJenkinsのJobみたいな使い方ができるので、アペルザの場合だとS・A・Bみたいな感じでシンプルにPlanが並んでいる感じですよね。

佐々木：そうですね。

藤原：ということは、新規で機能が追加されたときとかは、運用としては単純に「でき上がったらここに追加する。以上」って感じなんですか。

佐々木：そうですね。特に最初にレベルは決めちゃっているので、迷うことなくどのPlanに入れればいいのかというのは決まってきます。

藤原：なるほど。「Sに入れたら自動的に毎日実行され、Bに入れたら週に1回」なんですね。デプロイ時はどうされているんですか？　例えばStageデプロイとかDevデプロイの時は、何かホックして自動でやったりしているんですか？

佐々木：そこはまだパイプラインに組み込んでいないので、Stageにデプロイしたら手で全部のPlanを実行するようにしています。アペルザだとStagingへのデプロイは本番リリースのリハーサルも兼ねているので、手順書を作ってリハーサルでStagingにデプロイして、そのあとにE2Eを流す流れになっています。

藤原：なるほど。そのあたりも今後は自動化していこう、みたいな感じなんですかね。

佐々木：そうですね。

テスト自動化による恩恵

藤原：とてもおもしろいと思います。運用編の話の最後です。「テスト自動化による恩恵」も、改めて佐々木さんにもうかがってみたいんですが、こちらについて思うところあれば解説してもらえますでしょうか？　

佐々木：やはり環境を用意しなくていいことが、もう本当に一番だと思います。ChromeDriverとかIEのWebDriverとかそのあたり設定するだけでも大変なので、設定の手間がないというのはすごい恩恵だと思っています。あと、オフィスで動かしているとPCが落ちていることもないし、並列実行できるということがすごく強みだと思っています。

藤原：なるほど。実行環境のメンテ面。まずはSaaSならではですね。テストコードのメンテナンス作成とかはどうですか？

佐々木：だいぶ楽になっていると思います。Javaで作っていた時は、作っている時はやはり楽しいのでどんどん作れるんですが、3ヶ月とか半年後ぐらいに失敗すると、「なんで失敗しているんだっけ？」みたいな（笑）。

藤原：思い出すのに……（笑）。

佐々木：思い出すことが大変だし、直すのもちょっと億劫になるんですけど、mabl Trainerはやはり使いやすいです。あとはmablの実行結果はスナップショットを取ってあって、なぜで失敗したかがわかりやすいので、すごくいいなと思っています。

藤原：ずばりメンテナンスのコツとはどういうものなんでしょうか。ヒアリングのときに話していましたが、E2Eは動かし続けるのが大切と。

佐々木：そうですね。やはりちょっと忙しいと放置してしまいます。僕たちも、今でも放置しちゃう時はあるんですけど、放置しちゃうともう誰もメンテナンスができなくなっちゃうので、やはりずっと失敗しながらも動いているのが大事だなと思っています。1つのテストを短く保つというのと、あれもこれも欲張らないでシンプルなものだけにすることが、メンテナンスが楽になるポイントかなと思っています。

藤原：なるほど、楽にはなってメンテナンスにコストがかかるのは当然だけど、やはりメンテナンスコストはなくならない部分ではあるので、動かし続けながらどんどん磨いていくかたちでしょうか？

佐々木：そうですね。

藤原：ありがとうございます。それ以外だと、あとは並列実行も言っていましたし、Visual Change（画面差分）で、いろいろなもの、リンク切れとかもキャッチできるとかも大きいよね、と。あと僕が印象的だったのは、インフラが変わる時に壊れていないテストに強いとお話ししていたと思いますが、もうちょっと詳しくお聞きできますか？

佐々木：アペルザはAWSを使っているんですが、EC2上でDockerを起動していたものをこの間ECS Fargateにインフラを移行したんですが、そういうときの疎通確認にも広く浅く作っているので、使えると思っていましたし、実際に使えていました。あとは、データベースのバージョンアップをした時に、疎通確認に使ったり。

藤原：E2Eならではの部分ですよね。「見た目や機能は変わっていないけど、裏側が変わっている」問題とか「表側は同じだけど、実はReactになっている」みたいなところとかは、けっこう強みですよね。オートヒールもけっこう動いたりするし。

立ち上げ編でお話いただいた増原さんが、自動テストでリリース前の不安が安心に変わったと言っていたんですよね。このあたりをもうちょっとお話しいただけますか？

佐々木：そうですね。やはりリグレッションは心配だと思うんですけど、そこで大事なところは、mablがカバーしてくれていると思うだけでも、わりと安心感につながっているかなとは思っています。