MagicPodの導入効果をレビューでご紹介(kotatoshi-株式会社ノハナ)
株式会社ノハナ / kotatoshi
チームリーダー / QAエンジニア / 従業員規模: 10名以下 / エンジニア組織: 10名以下
利用プラン | ツールの利用規模 | ツールの利用開始時期 |
---|---|---|
モバイルアプリテストのスタンダートプラン | 10名以下 | 2017年4月 |
利用プラン | モバイルアプリテストのスタンダートプラン |
---|---|
ツールの利用規模 | 10名以下 |
ツールの利用開始時期 | 2017年4月 |
導入の背景・解決したかった問題
導入背景
- オフショアでリグレッションテストをしていたときは、AndroidとiOSで並行実施でも長いと数人で1日ぐらいかかっていました。
- スプリント期間内の短いサイクルでのリリースを進める中で、できるだけ早くリグレッションテストテストを完了させることが必要になりました。手動でのスピードアップには限界を感じ、自動テストツールの導入を検討しました。
比較検討したサービス
Autify
選定理由
MagicPodが以下の点を満たしていたため採用しました。
- リーズナブル
- 自前で環境準備が不要(クラウド端末も使える)である
- ノーコード(ローコード)でテストケースを生成できる
- UIから要素を見つけ出してくれる
- 当時は他の自動化ツールもあまりなく、日本語のツールかつAndroidとiOSをサポートしていたため(AutifyはiOSかAndroidどちらからだった)
導入時の苦労・悩み
前任のQAマネージャーと一緒に既存のテストケースを自動テスト用に改修し、自動化を進めていきました。その中でも自動化が比較的簡単なテストケースから導入していき、徐々にカバレッジを増やしていきました。現在はAndroid&iOSともにテストケース数全体の70%前後となっています。ただ、自動化が難しいテストもあり、無理せずに手動のままとしているものもあります。
導入に向けた社内への説明
上長・チームへの説明
- ドキュメントを作成し、リグレッションテストの工数を削減できることを説明
- 自動化率が低いときはコストのほうがかかる可能性があるが、自動化が進むにつれて、費用対効果が増えることを説明
費用対効果の算出
メンテナンスコストの懸念については説明に苦労しました。リグレッションテストを2週に1回両OSで行う必要があること、ステージング環境での定期実行や本番での定期実行を今後行うことで、コストは回収できると説明しました。
活用方法
よく使う機能
リグレッションテスト、ステージング環境での定期実行、本番環境での定期実行
- テスト一括実行
- 毎朝テスト環境でAndroid・iOSのリグレッションテストを回している
- 1時間ごとに本番環境でもテストを回すことで、本番環境にて不具合がないかを確認している
- 共有ステップ
- 画面ごとに共有ステップとして登録し、データパターンを各シナリオごとに設定し、共有ステップを組み合わせてテストコードを作成
- 共有ステップ内ではデータパターンの値をもとに条件分岐を入れている
- 詳細はこちらに記載しています。https://blog.nohana.co.jp/article/magicpod-2022q3
- 画像の差分機能
- 本番環境におけるテストにおいてサーバーが落ちているとプレビューが出ないのでここで差分が出る状態のためこちらを確認している
ツールの良い点
- リーズナブルであること
- サポートが早い
- 外部ツールとの連携(APIコマンド、Jenkinsのジョブ実行など)
- AIによる自動修正
- 画像差分確認
- magicpod-analyzer(サードパーティーツール)でデータを分析用に出力し、ダッシュボードを構築可能
- リグレッションテストのスピードアップ
- ステージングや本番環境での定期実行によるデグレやエンバグの早期検知
ツールの課題点
- テストが安定しないことがある
- 同じ環境やテストケースでもコケることがある
- 確認や対応にコストがかかっている
- 条件分岐を多用するとテストケースがわかりにくくなる
- UIの使用数はわかるが、UIがどのシナリオで使われているかわからない
- UIが変更になった際に使用しているテストケースを見つけるのが困難
- 共有ステップは便利だが、部分実行ができない
- 共有ステップ内の特定の場所でコケることがあり、全部を実行したくないケースの場合は、確認のため共有ステップからコピペして実行している
- iOSの実行時間が長い
- 手動テストよりも時間がかかってしまうケースがある
- Androidよりもシナリオ数は少ないが、倍以上かかる場合が多い
- 同じテスト内容でも、実行時間が2時間以上変わることがある
- 平均で2時間ぐらいかかるものだとして、1時間30分から3時間30分くらいと幅が大きい
その他
- 同じテストコードでも成功・失敗となるので、完全な自動テストとはならないこともあります
- 既存のテストケースをそのままMagicPodに導入するのは難しいかもしれません
- 自動で動くように待機時間を入れたり、ステップを追加したり、不要なステップは削除したりする必要はあると思います
ツールを検討されている方へ
色々なツールをトライアルで実際に試してみるのが良いと思います。自動化が難しいところはメンテコストがかかったりして結局コスト増になるかもしれないので、無理して自動化しないことが重要かもしれません。
株式会社ノハナ / kotatoshi
チームリーダー / QAエンジニア / 従業員規模: 10名以下 / エンジニア組織: 10名以下
組み込み系、ネットワークシステム、PC用ソフトウェア、データベースシステム、スマホアプリなどのQAエンジニアとして18年ほど経験を積む。株式会社ノハナでは、テスト計画から実行まで、仕様検討などにも参加。
よく見られているレビュー
株式会社ノハナ / kotatoshi
チームリーダー / QAエンジニア / 従業員規模: 10名以下 / エンジニア組織: 10名以下
組み込み系、ネットワークシステム、PC用...
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法