2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
テスト自動化 運用編(全1記事)
リンクをコピー
記事をブックマーク
佐々木邦彦氏(以下、佐々木):株式会社アペルザのQAチームのリーダーをやっています。アペルザはオフショアでQAチームを持っているので、オフショアの管理やマニュアルテスト、テスト自動化、ユニットテストもちょっと書いたり、簡単なリファクタなどもやっているので、SETに近い役割をやっています。
藤原大氏(以下、藤原):ありがとうございます。プロダクトについて教えてもらえますか?
佐々木:アペルザは、メーカーや商社向けのCMSやECを提供しています。
藤原:開発の体制や流れはどうなっているかを教えてもらえますか?
佐々木:ビルドやデプロイはパイプラインで自動化できていて、あとはE2Eがmablとほかにも動いているものがあります。
藤原:(mabl以外に)Gaugeが動いている点は、Ubieさんと同じですね。ありがとうございます。それ以外だと、時間があれば探索的テストや新機能のマニュアルテストでオフショアを使っているという感じですかね。
佐々木:はい。
藤原:ありがとうございます。ではさっそく質問ですが、まずなぜ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がたぶん多いと思います。
藤原:きっと半分を超えている感じなんですね。
佐々木:そうですね。
藤原:なるほど、ありがとうございます。じゃあ次の質問にいきたいと思いますが、まだ運用のポイント編ですね。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がカバーしてくれていると思うだけでも、わりと安心感につながっているかなとは思っています。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには