2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

MagicPodを使って本番環境で定期実行してみた

Last updated at Posted at 2023-11-07

はじめに

こんにちは。QAエンジニアをしている田井です。

以前の記事でステージング環境で自動化を進めている話をしましたが、今回は本番環境で定期実行をしているお話をします。

目的

弊社のアプリはフォトブックを作るアプリなのですが、本番環境でアクセスが集中すると、プレビューが表示されなかったり、決済でエラーになることがあります。
エンジニアが導入したアラートなどでも検知できるのですが、QAとして何かできないかと考え、MagicPodで定期実行をすれば目的を達成できるのではということになり、進めることにしました。

ただし、新たに準備工数やメンテナンスコストがかかることはしたくなかったので、ステージングで使っている回帰テストケースを流用することにしました。

ステージングでは多くのシナリオを運用していますが、本番環境では最低限の動作確認をすることとしたので、通常のユーザーが使うであろうログインから、写真のアップロード、注文までのフローを1時間毎に行うセット(タグ管理)を作りました。

実装

テストケースはステージングの回帰テストをそのまま使っています。タグをつけて実施内容を選定しました。
プレビューが表示されない場合、決済エラーなどの確認は、画像差分の機能を使いました。

ただ、既存のシナリオはキャプチャを保存して目視で確認をしていたので、完全に自動化されていなかった問題があり、この画像差分の機能を使うことで、目視でも確認も不要となり完全な自動化に成功しました。

スクリーンショット 2023-11-06 19.24.52.png

この画像差分機能はとても便利で、許容不一致率というのを設定できます。この数値が低いほど細かい差分でも検知してくれます。

スクリーンショット 2023-11-06 19.45.22.png

これにより、プレビューに想定した画像が表示されてない場合、決済でエラーが表示されてしまう場合に検知できるようになりました。
ただ、課題が出てきて、デフォルトだと許容不一致率がとても低いので、失敗してしまうケースが多々ありました。
下のキャプチャは画像差分を表示した状態なのですが、画面自体は同じなので問題ありませんが、本当に少しのズレがあるために、失敗となっていました。
プレビューが表示できない場合にエラーが表示されることを検知するためなので、許容不一致率を少し甘めに設定しています(エラー時の画像は全く違う画像になるため)。

スクリーンショット 2023-11-06 19.35.44.png

許容不一致率をどのぐらいにするかは、実際にどういう目的で確認を行うか、どのぐらいの精度を求めるかにもよると思います。

実行

そして、肝心の実行フェーズです!
今回の一番重要な考慮点として、非エンジニアでもメンテナンスしやすい設計にしようとしました。
アプリについては、CIで自動ビルドなども可能だと思うのですが、リリースされたタイミング(大体2週に1回)で手動でアップロードしています。

スクリーンショット 2023-11-06 19.16.19.jpg

環境は実機ではなくクラウド環境を使っています。また、実行タイミングもAPIを叩けば実行できると思いますが、MagicPodの一括実行のスケジュール機能を使っています。

今は午前6時から午後8時までの合計12回を1時間毎に実行しています。午前10時ごろまで実行してないのは、ステージング環境でAndroidとiOSの定期実行が行われているためです(契約しているプランが同時に2つまでしか動かせないため)。

スクリーンショット 2023-11-06 19.27.46.png

上記のように12個実行スケジュールを入れているのですが、例えば「○時から○時まで○時間ごと」とか細かく設定できると管理しやすいかなと思いました。

実行した感想

実行結果はSlackに通知するようにしています。
こちらもMagicPodの標準機能を使っています。ただし、全ての結果を朝から夜まで通知すると、1日12回もSlackに来るので、失敗した時だけ来るようにしました。ここもどの結果を通知するか、どのチャンネルに通知するかなど設定できるので便利です!

指定したチャンネルに通知が来なければ問題ないと判断しています。
失敗通知は成功と失敗の数やどのシナリオがなぜ失敗したかもわかるので、便利ですね。
念のため、失敗した場所をQAメンバーが実際にアプリを操作して問題ないかを確認しています。

スクリーンショット 2023-11-06 19.52.44.jpg

今の所、手動で実施すると問題ないケースしかなく、インシデントは発見できていませんが、それはそれで良いことかなと思います。

最後に

本番環境でのエラーを検知するために今回は定期実行をしてみましたが、APIの知識などが乏しい自分にとってMagicPodの管理画面で色々と設定できるのは便利だと改めて感じました。
そして、そういうところが、MagicPodを使いたいと思える場所でもあると感じました。

今後も定期的に実行していきたいと思っていますが、課題としては、MagicPod側の準備で失敗したり、エミュレーターの準備ができないことがたまにあることです。
そういうケースでも失敗の通知が来るので、手動で確認をせざる終えないですが、この辺りの失敗が減ると、さらに効率的に使えそうです!

また、先ほど話題にもしましたが、定期実行を想定した設定(例えば「○時から○時まで○時間ごと」とか)ができるようになると、とても便利になるのではと思いました。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?