1〜2人日費やしていた回帰テストが3時間に。ノハナが自動化率を70%まで上げることができた秘訣とは
株式会社ノハナ
ユーザーインタビュー第5回は、MagicPod代表伊藤とともに株式会社ノハナ様にお話を伺いました。
具体的な活用事例や選定の決め手など、いろいろとお話しいただきました。
株式会社ノハナ 会社概要
「1組でも多くの家族に笑顔を届ける」というミッションをもとに、子育て中のパパママがスマホから簡単にフォトブックが作れる「ノハナ」と年賀状が作れる「ノハナ年賀状」を提供しています。
POINT
- 1〜2人日費やしていた回帰テストが3時間に
- サポートの早さ・対応力が安心感につながる
- 自動化率向上の鍵はエンジニアの理解と協力
- ノハナの自動化にMagicPodは必要不可欠だった
![](https://magicpod.com/acms-media/001/202205/mode3_w1500-_MG_8933.jpg)
![](https://magicpod.com/acms-media/001/202205/mode3_w1500-_MG_9093.jpg)
株式会社ノハナ サービスデザイン部 品質保証グループ
左:武田 義之さん(マネージャー)
右:田井 康平さん
MagicPod導入の経緯
武田さん(以下、武田):私がノハナに入社したのは2015年なのですが、もともと業務委託でQAを担当していました。プロジェクトが終わるタイミングで社長の大森から「残ってほしい」というお誘いを頂き、私自身も「これからもノハナの開発に携わっていきたい」という想いがあり、入社しました。
ノハナではアプリをリリースする際に変更した部分のテストに加えて、変更が他の部分に影響していないか回帰テストを実施しています。テストケースは300件ほどあり、手動でやっていた当時はリリースのたびに1〜2人日を費やしていました。
複数端末で実施するのにもすごく時間を消費してしまいますので、時間がかかりすぎているという課題感はずっと持っていました。ただ、自動化したいと思っても「プログラミングはできないし、環境構築もよくわからないし……」とズルズル時間だけが過ぎていました。
そんな時に伊藤さんのブログを読んでMagicPodの存在を知り、「これだ!」と思って触り始めたのが2017年のことです。今後入ってくるメンバーもプログラミングの知識や経験があるとは限りませんので「Appiumでテストコードを書く」という選択肢は考えにくく、ノーコードやローコードで書けるようなツールがいいと考えていました。
その頃ちょうどQAでベトナムオフショアの活用を始めたタイミングで、時間の余裕ができたこともあって本格的な導入に動きました。Slackの個別チャンネルを作らせていただいたり、伊藤さんに来社していただいたりしたこともありました。問い合わせをすればすぐにレスポンスしてくださいますし、「こういった機能を追加していただきたいです」とお伝えすればすぐに実装されて、当時とても助かったことを覚えています。
※編集部注:現在はQAメンバーがもう一人増え、オフショアから内製に戻されているそうです。
田井さん(以下、田井):実際MagicPodはプログラミングがほとんどできない私でも扱えるのがすごく良いですし、サポートが早くて質問にもすぐ対応してもらえるのも助かっています。MagicPodさんにしてみればとても簡単な質問ばかりかもしれませんが、プログラミングの知識が無いとエラーが出ても何が起きているのか分からないことが多々ありますので、いつでも相談すればサポートしてもらえるという安心感があるのは有難いです。
![](https://magicpod.com/acms-media/001/202205/mode3_w1500-_MG_8906.jpg)
MagicPodの活用事例
武田:現在は毎日早朝にdevelopブランチのアプリに対して回帰テスト相当のテストをクラウド環境で実施しています。リリース前は実機で確認するため、releaseブランチのアプリに対して回帰テスト相当のテストをローカル環境で実施し、3時間程度で完了しています。
以前はGoogle Apps Scriptで「Magic Hand」というオリジナルのSlack Appを開発して独自のSlash Commandからテスト実行をリクエストしていたのですが、現在はBitriseから実行するような形にしています。ローカルの実行はブラウザから手動です。
毎朝4時ぐらいに回帰テストが実行され、出社する頃には結果がSlackに通知されていますので、全部パスしていたら「よし!」と思って仕事に入り、エラーが出ていたら確認から始めるような仕事の流れになっています。
田井:リリース前の回帰テストで不具合が見つかることはあまりありませんが、毎朝定期実行しているテストでは見つかることがあります。例えば、画面が正しく描画されず、単純にロードに時間がかかっているのかと思ったら、前日の変更が良くなかったのが分かったといったことが何度かありました。
武田:リリースのたびに1〜2人日費やしていたものが自動化され、手動で行う作業も含めて3時間程度になっていますので、MagicPodの導入でかなり改善が進みました。回帰テストのカバー率は2017年にテストケース全体の5%ほどだったのですが、2019年に20%に達し、現在はAndroidが先行して69%ほどになっています。
田井:エンジニアがライブラリのアップデートをしやすくなったのも導入して良かったところです。以前はちょっとしたアップデートでも「どこに影響が出るかわからない」ということでQAにテストの依頼が来ていたのですが、今は問題があれば定期実行のテストで検知できます。エンジニアから「安心してアップデートできるようになった」と言われました。
![](https://magicpod.com/acms-media/001/202205/mode3_w1500-_MG_9031.jpg)
回帰テスト自動化率70%の秘訣
武田:ノハナが自動化率70%弱まで進めることができたのは、エンジニアの協力があったからです。すみ分けとしてメンテナンスはQAチームが行っていますが、その中でどうしてもできない部分、厳しい部分が出てきますのでエンジニアとの協調は不可欠です。
田井:エンジニアや興味ある方向けにMagicPodの勉強会を開いて、基本的な機能を紹介したり、実際に触ってもらったりしたこともあります。
武田:テスト結果はエンジニアの目にも入るSlackチャンネルに通知されています。それに対してエンジニアが何か先行してアクションを起こすことはありませんが、MagicPodが動いていることは常に意識してくれていると思います。相談した時の協力が円滑になりますので、社内での理解を深めておくことは大切です。
また、現在ノハナでは2週間スプリントで開発をしていますが、開発チームの振り返り(スプリントレビュー)とは別に、QAチーム3人での振り返りも実施しています。そこでは自動テストの成功率や、どのシナリオが不安定なのかを分析して、次のスプリントに向けた改善を考えています。Androidは自動化率70%弱まできましたが、これ以上は難しい部分もあります。最近はまだ進んでいないiOSの改善に注力しています。
最後に
武田:自動化を検討されている方にお伝えしたいのは、「最初からいろいろ作り込み過ぎない」ということです。まずは一つの機能、一つのシナリオを作り、それをきちんと動く状態にして徐々に広げていくのがいいのではないかと思います。自動化が目的になってしまうのは実体験の反省でもあります。何のために自動化するのかしっかりメンバーと認識合わせをして徐々に広げていくことで、少ない失敗で自動化を進められると思います。
ノハナの自動化にとってMagicPodは必要不可欠なツールです。出会っていなければ、いつまでも「自動化したいなあ……」と悶々としていて、現在のような状態には至っていなかったと思います。
株式会社ノハナ 提供サービス
![](https://magicpod.com/acms-media/001/202205/mode3_w2000-_MG_9176.jpg)