テストをスケールさせるために必要なこと
藤原大氏（以下、藤原）：もう1個、たぶんこのイベントの事前準備でヒアリングをした時にお話ししてもらったネタで、すごく印象的でしたが、「テストを作成したあとにこういう型を作っていくのが大切」だというお話をされていました。これについてもうちょっと教えてもらえますか？
増原賢秀氏（以下、増原）：型というより、テストをスケールするためには、「何をテストするんですっけ？」とか「どう作るんですっけ？」とか、そのあたりがある程度決まっていると、自分以外のQAもそうだし、開発者やBizDev、Bizの方が作ったり見たりする時に迷いがないかなというのがあります。そういうのを整備する必要がある、みたいな話でしたっけ？
藤原：そうですね。あとは「テストの自動化は後回しにしない」という話もされていましたね。
増原：そうですね。ちょうど今週も1個、僕が今mablを入れているプロジェクトで、ステージングにデプロイされて、mablがコケていて「対応します」と伝えました。そこからリリースができましたが、そういうのは事前に「mabl落ちたら教えてよ」というコミュニケーションのフローというか型なども決めとかなきゃいけませんし、周知などもしておかないといけません。
藤原：なるほど。確かにそうですよね。あとは「安定化にコストに割く」と言っていましたね。リグレッションテストができているという状態を目指して、先ほど話されていたみたいに、何をE2Eテストすべきかが決まっていて、デプロイ前にはもう終わっている状態を作る。こういう型を作るような話もされていました。
増原：これはそのサービスに求められるレベルにもよると思いますが、今担当しているプロジェクトで言えば、リリース前にそこが担保されていないとマズい認識なので、そこを整備しないといけません。
でも、プロジェクトの中でいくつかシナリオを用意して新規で追加しなきゃいけないようなこともあるわけです。そういう時にどういうテストを作るかというと、先ほど最初にテストを1個作った時の話で、それっぽいものはQAエンジニアも作れると思う。しかし、ビジネス的にそれでいいのかというインプットはBizの人は必要なので。じゃあテストを今後も足していく時に、それをいくつもインプットする必要があるよね、ということを決めておく必要があるということですかね。
テスト自動化による恩恵
藤原：ありがとうございます。とてもわかりやすいです。最後1つだけ聞いて、あとは質問の回答をしようと思っているんですが、ずばり今の立ち上げ時点で、テスト自動化による恩恵は何だと思いますか？
増原：今Ubieに来てmablの導入プロジェクト1ヶ月ちょいぐらいですけど、やはり効率的にチェックできるところです。
藤原：それがmablの仕事ですからね。
増原：そうですね。それが最大の恩恵な気がするなぁ。
藤原：逆にmablのようなツールが得意なことは、何だと思いますか？
増原：得意なのは、自動化周りをやったことある人ならわかると思いますが、画面を使って操作して、それを繰り返して実行できるというか。それをサーバー上でブラウザを並列して実行できるとか。mablのメリットはたぶんそこだと思います。一方で、ブラウザ操作周り以外のことはあまり得意じゃないので、「それ以外はそもそもやらせないようにしましょう」と思いますね。
あとやはりバリエーションをどう実装するかにもよるけれど、バリエーションのテストみたいなのはそもそもやらないほうがいいし、「ほかの方法で担保できるならそのほうがいいんじゃないの？」とも思います。
藤原：なるほど。ありがとうございます。とてもおもしろいですね。本当に「得意なことをやらせる。以上」っていう感じですね。増原さんは、もう割り切っているというか、わかりきっているという感じなんですよね。
増原：うーん。長く使っているからだと思いますが、あんまりそもそも期待とかないし（笑）。やはりmablの最大のメリットというか、僕が買っているところは、「安定した実行環境」と「簡単にテストが作れる作成環境」だと思っています。安定しているし、ChromeDriverのバージョンアップもしなくていいし、実行環境のメンテもしなくていいし、そのあたりかと。
テスト自動化の立ち上げを伝えるのは難しい
藤原：なるほど。ちょっと時間もまだあるのでおうかがいしようかと思うんですけれども、1個目のコメントもおもしろいですね。「テスト自動化の立ち上げ、うまく動いてもらえるように伝えることは本当難しい」という方もいるんですが、テストの立ち上げを伝えるのはやはりやはり難しいですかね。
増原：自分はmablがあると何ができるかを知った状態で今やっているので、あまり躓いたというのは、今回の場合はないのかもしれないですが。確かに伝えるのは難しいかもしれない。でも、つらいことはつらいと言っちゃっていいんじゃないでしょうか？（笑）
藤原：確かに（笑）。
増原：絶対最初で成功するかというと、そうでもないと思うので。
藤原：そうですね。先ほどの話にちょっと戻りますが、スクラムのイベントで共有するとか本当に地道なところからやっていますもんね。BizDevを交えて何ができるか話すとか、できたことを話すとかタスク化するみたいな。けっこう地味な感じだと思いますけど、そういうのをコツコツやる感じなのかなという気もしますね。
増原：やり続けていれば、そのうち成功します。
質疑応答
藤原：ありがとうございます。「自動化して実行するテスト環境は、自動テスト専用環境ですか？」という質問です。
増原：現状の環境だとノーですね。開発者の動作確認も兼ねている場所なので、E2E用環境ではないです。
藤原：Devも使っている感じなんですね。
増原：なので、mabl内である程度環境、まあQA、ステージングみたいなプランを作って実行すると思いますが、QA環境のところは真っ赤っかみたいなところがあります。つまり、ずっと落ちているという状況が続くこともあります。
藤原：ありがとうございます。佐々木さんのところの自動化環境はどうでしたっけ？
佐々木邦彦 氏（以下、佐々木）：僕はテスト、ステージジングと本番環境があって、ステージングはQAでも使って。
藤原：きっとmablとかも、ステージングに向けているということですよね。両者とも専用ではないんですよね。
増原：専用じゃないですね。
佐々木：専用じゃないですが、ログインユーザーとかはメアドの先頭に「E2E」とつけてわかりやすくするようにするような、ちょっとした工夫はしています。
藤原：ありがとうございます。もう1個似たような質問なんですけど、「バリエーションを増やすのはけっこう大変。例えば事前のデータ準備はどうやっていますか？」という内容です。
「例えばECシステムだと、本人確認済みユーザー、本人確認前ユーザー、ショップ開設済みユーザーとかバリエーションがありますよね」という具体的な話をされているんですが、事前にデータはどうされているんですか？ 専用環境じゃないということもあると思いますけど、増原さんはいかがですか？ 増原：今は事前にユーザーとかデータを準備しないシナリオしかないです（笑）。
藤原：しないシナリオね。
増原：ログインとかそういうことはしなくてもいいやつなんですけど、それって大変ですよねー。
藤原：そうですよ。たぶん毎回やらなきゃダメみたいな感じなんですよね。
増原：どこでの経験とは言いませんが、やはりデータの準備やマスター、本番から週1データシンクして育てたアカウントが飛ぶとか、そういうのもよくあると思うので（笑）。
藤原：確かに。あるあるですね（笑）。バリエーションは入力値の組み合わせやデータ、ユーザー権限とかだと思います。
増原：mablは作ったテストの数で課金は増えないので、mablだったらデータを作るシナリオを作ったほうがいいかもしれない。
藤原：そうですね。確かに、それをやられている方ももちろんいます。ただ、それでコケると全部落ちるという悩ましい問題もあります。
増原：それ前提だとね。
藤原：そうそう（笑）。だから1個ずつ作るのがやはり一番便利なんですけれど。佐々木さんはどうですか。アペルザの場合、まさにEコマースがあるので「本人確認済みユーザー」とか聞き覚えのある感じがするんですけれども、どうされています？
佐々木：ありますね。そこは手作業で作って、それをずっと使っています。幸いデータが飛んだとか前提条件が壊れたというのはなく、何年か使っている感じです。
藤原：アペルザの場合はアカウントを本当にうまく切り分けていますよね。
佐々木：そうですね。1つのテストに1つのユーザーというかたちで今作っています。
藤原：あとは新規作成系は毎回作っているし、既存のものであれば使い回せるし、きっとデータ作成まではまだ手を出していないですよね。
佐々木：そうですね。
藤原：ただ、今後そういうところもAPIとか使えるようになってきたので、たぶん運用編のところでお話ししてもらえるかなと思っています。
最後にもう1個質問です。「デスクトップアプリの活用で、開発者のローカルで実行できるように、開発者支援のニュアンスの強い自動テストの使い方をしていますか？」。これ「誰がやるねん？」みたいな感じですかね。増原さんはいかがですか。
増原：やはりQA環境やステージング環境は、少ないインテグレーション環境で、そこにデプロイされて、初めてテストがぶっ壊れているのがわかることはやはりつらいなと日々思っていて。やはり開発者の手元で実行してもらっています。でも、たぶんmablはそうしてもらうのが一番と思っていて、こういうローカル実行の環境も用意していると思うので、そちらを広めていきたいとは思っています。
