MagicPodは第2のQA!?「繰り返し実行される安心感」が開発速度の向上につながっている。

株式会社アルダグラム

モバイルアプリテストブラウザテスト

ユーザーインタビュー第10回は、MagicPod代表伊藤とともに株式会社アルダグラム様にお話を伺いました。
具体的な活用事例や選定の決め手など、いろいろとお話しいただきました。

株式会社アルダグラム会社概要

アルダグラムは、「Unlock Your Value.」をミッションに2019年5月に設立したスタートアップです。建設業、不動産業、製造業など、世界中のノンデスクワーク業界における現場の生産性アップを実現する「KANNA」（カンナ）を提供し、世界中の現場の価値ある能力をアンロックすることを目指しています。

POINT

手動だけでは破綻する未来が見えていた
導入の決め手は何度でも実行できること
安心感が開発速度の向上につながる
いかに開発とQAの協力関係を築くか

株式会社アルダグラム
左：小幡洋介さん（エンジニア）
右：佐野成信さん（QAチーム）

MagicPod導入の経緯

小幡さん（以下、小幡）：MagicPodの導入は2022年の2月からで、トライアルを経て3月頃から正式に契約しています。僕が入社したのは2021年の12月なのですが、開発環境についてヒアリングしたりリリースの流れを見たりする中で、このまま人の手だけでテストを続けるのは難しいと感じていました。

佐野さん（以下、佐野）：私は2021年10月に1人目のQAとしてジョインしました。KANNA（カンナ）はWebアプリとモバイルアプリ（iOS / Android）があり、リリース前に必ず手動テストを行っています。当時はリリースの前日にリグレッションテストが走り、その段階で自分やPdMの判断で要修正となると、リリースが1〜2日遅れてしまうということが起きていました。

小幡：KANNAはノンデスクワーカーの方でも使いやすいようにUI/UXを大切にしています。それを支えていたのがリリース前の手動テストでした。機能が増えればテスト項目も、かかる時間も増えていきます。バグの発見、修正が遅れればリリースに影響しますから、COOの渥美を含めて他のメンバーも先を見据えた課題感を持っていました。そこで提案したのがE2E自動テストの導入です。これが品質もリリース頻度も落とさないためのソリューションとして合意を得られたため、年明けからツールの選定に入りました。

MagicPod導入の決め手

小幡：前職ではCapybaraでE2E自動テストを動かしていたのですが、QAの方がいなかったこともあって高コストな作業だと感じていました。アルダグラムでは佐野さん含めQAのプロにテスト設計をお願いできるのは良かったものの、エンジニアリソースが潤沢とは言えない事情があり、ローコードツールが最適だと考えました。

選定にあたっていくつかツールを試せば良かったのですが、その時はMagicPodのことを知らず、もともと知っていた別のツールだけを試しました。操作性は悪くありませんでしたが料金体系の面で導入を断念し、他のツールについても調べてMagicPodを試すことにしました。

改めて整理した選定ポイントは「使いやすく運用しやすいこと」「何度でも繰り返し実行できること」「モバイルアプリのE2Eが書けること」の3つです。MagicPodを使ってみると操作できる項目が多く、生のログが見られるなど、あまりよしなにし過ぎていない感じがエンジニアにとって分かりやすいと感じました。

伊藤（MagicPod代表）︰ありがとうございます。「よしなにし過ぎていない」というのは具体的にはどういったシーンで思われたことですか？

小幡：例えば「何回かテストを回していると落ちる時がある」といった“べき等性”の無いテスト結果があった場合に、ログを見ることができると「なぜ落ちているのか」「MagicPodは何をしようとして失敗しているのか」を自分で調査することができます。もちろんMagicPodのサポートも対応してくれますが、佐野さんが困った時は自分もサポートできる安心感があります。
（※“べき等性”とはある操作を1回行っても複数回行っても結果が同じであること）

またMagicPodは実行回数が無制限ですし、モバイルアプリのテストも書けます。個人的に自動テストは何度でも繰り返し実行できるのが一番の強みだと思っていますので、それが気兼ねなくできる点は希望通りでした。

佐野︰私も実際に使ってみて、コーディングの知識がなくてもスムーズに書けるのが良いと思いました。特に良いなと思ったのが自動修復機能です。KANNAは2022年7月に英語版をリリースしたのですが、日本語と英語で文言修正が行われた際に、手動のQAではどうしても見逃してしまうところをMagicPodが「ここの文言が変わってますよ」と知らせてくれます。「ここはグローバルのエンジニアの方が修正してたんだな」と気づくことができて、第2のQAというか常にQAがいるような感覚で、本当に助かっています。

MagicPodの活用事例

佐野︰現在は1日1回、平日の早朝に定期実行しています。朝会が終わった後にSlackの通知を見てNGが返ってきていたら「どこがNGだったんだろう？」と見に行くのがルーティン化しています。

小幡︰毎日手動で全部のテストをするのは不可能なので、MagicPodの存在は大きいです。テックブログでも紹介しましたが、いま目指している自動E2Eテストを活用した開発フローがこちらのチャートです。

既存機能のシステムが意図通りに動作するかE2Eで担保し、新機能のテストとUX観点のテストは手動で行います。全てのテストがOKだったら本番にリリースし、新機能のE2E自動テストを追加します。これによって機能が増えても本質的な部分にフォーカスした手動テストができるようになると考えています。

佐野︰もともと全てのQAは手動で行っていましたが、現在6〜7割ほどがE2E自動テストで行えるようになりました。現在行っているQAテストを全て手動で行ったら7時間以上かかると思いますが、MagicPodを導入したことでその工数を3〜4時間ほどに短縮できています。

E2Eがうまく走ればリグレッション前の定期実行で結果が見られますので、早めに「ここを修正してください」と開発に伝えることができます。これによって探索的なテストをする時間も取れています。「リリース前日にリスケする」ということが減ったのは本当に良かったと思います。

小幡︰やはり何回も実行できるMagicPodに助けられていて、網羅的にテストが走っている安心感は開発速度の向上にもつながっていると思います。今後はモバイルアプリのテストも追加していく予定です。モバイルの挙動はどうしても端末によって差異が出ますが、MagicPodならさまざまな端末でテスト実行できます。リリース前に特定の端末でのみ起こるバグにも気づけるようになると考えています。

いかに開発とQAの協力関係を築くか

伊藤︰先ほどべき等性の話が出ましたが、何回同じテストを実行しても同じ結果が得られるようにロケーターを書き換えるといった工夫も意識して行われているのでしょうか？

小幡︰KANNAはフロントエンドをReactで書いているのですが、最初はdata-testidを入れていなかったので要素（ボタンなど）の自動検出に不安定なところがありました。そこでエンジニア全員が協力してコードにdata-testidを追加して回りました。現在はとても安定しています。

佐野︰エンジニアの方は「こういった形で整理すれば安定化するよ」と自分が思いつかない方法を提案してくれます。そういった協力があったからこそ、導入からスムーズに動けたと思います。

伊藤︰やはりエンジニアチームが協力してくれるとやりやすいですね。小幡さんが両方を見ているからでしょうか？

小幡︰それもあると思います。間に立って双方が効率的に動けるやり方を考えるのが好きなんです。あとは前職でE2Eをコードベースで書いていたので、大変さを知っているのも大きいと思います。壊れた時にどこを直せばいいかは、普段E2Eのコードを見ていないとわかりません。だからこそQAの方とは「うまくいかないところのサポートはエンジニアがやる」といった役割分担でいくのが良いと思っています。

弊社のエンジニアたちはみんな協力的で必要性を説明すれば分かってくれますし、佐野さんも「data-testidで要素特定してください」と言えばわかってくださる方なので、どちらもコミュニケーションコストがすごく低かった気がします。

伊藤︰よくQAの方からエンジニアの協力を得るために苦心されている話を聞きますので、協力関係が築けているのが素晴らしいと思います。アルダグラム全体の文化と言えるのでしょうか？

小幡︰そうだと思います。ノンデスクワーカーに向けたサービスをつくっていますので、みんな使いやすいUI/UXをすごく意識しています。ですから僕が入社する前から、「高い品質で書いていこう」「そのための工数は惜しまない」という意識が高かったんだと思います。そういった文化はCOOの渥美の温度感がすごく高いところから生まれているとも思います。今でもいろいろな仕事と並行して、ほとんどのQAにCOO自ら参加しています。

佐野︰今までジョインしたサービスの中で、これほどCOOが直接見ることはありませんでした。上がそういう意識だからこそ、みんなの意識も高いんだと思います。

最後に

小幡：E2Eテストは高い品質を保つためにとても重要ですが、必ずしも人手で行うのがベストとは限りません。自動化できる部分は自動化することで、人の手でしかテストできない部分をより深くテストできるようになったり、リリースの頻度を増やすことができるようになったりします。

MagicPodは実行回数が無制限なので、自動テストの強みを最大限に生かせるツールです。その上、ただ自動化されるだけでなく自動修復機能のように、人の目によるチェックよりも変更に気づきやすくなるという利点もあります。自動と手動をうまく組み合わせることで、より良い製品をつくっていけると思います。

佐野︰MagicPodは非エンジニアの自分でもすごく使いやすいです。ただ、私が導入を率先してもdata-testidの整備のようにうまく進まない部分があったと思います。いかにエンジニアの方を巻き込んでやっていくかがプロジェクトの成功につながる大きな要素になります。アルダグラムではチーム一丸となってやれたことで、半年もかからずテストケースの半分近くを網羅できました。QAの方だけで1人悩まず、社内を巻き込みながら進めていけると良いと思います。