MagicPodで自動化率を爆上げしたハナシ

MagicPodで自動化率を爆上げしたハナシ
2023.04.26

Copyright (C) nohana, Inc. All rights reserved.
トピック
● 自己紹介＆会社紹介
● MagicPodの導入経緯
● MagicPodでの回帰テスト自動化
● 回帰テストの手動と自動の工数比較
● 回帰テストの自動化率
● CircleCIによる定期実行
● ライブチェックの自動化
● ダッシュボード(進行中)
● MagicPodでやっていること
● 抱えている課題＆改善してほしい点
● 今後の取り組み
● 最後に

自己紹介
田井康平
● 株式会社ノハナ
○ サービスデザイン部品質管理グループ
■ QAエンジニア
● 以前はテスト専門の会社に所属
● 趣味：読書、ドライブ(スイーツ巡り)、飛行機を見ること
● プログラミングの知識はほぼなし
● Twitter: @kotatoshi

ノハナの紹介
● フォトブックアプリ、年賀状アプリの開発
通常フォトブック
毎月1冊無料でつくれるスタンダードタイプ。
高画質仕上げ、表紙デザインやギフト包装など、用途で選べ
るオプションも豊富にご用意しています。
定期的な写真のまとめや、月齢アルバムにおすすめです。
プレミアムフォトブック
高精細な写真画質仕上げの銀塩ハードカバータイプ。
レイフラット製本で迫力の見開き写真が実現、最大89枚（表
紙含む）の写真が入ります。
特別なイベントや、1年ごとの思い出の記録におすすめです。

ノハナの紹介
かざる、差し替えるに特化した「フォトカード+フレーム」
スマホで選んだ写真を、専用のましかくフレームに飾ることができ、お気に入
りの写真を気軽に差し替えて毎日楽しむことができます。

MagicPodの導入経緯
テスト観点作成
開発(2weeks) テスト(2weeks)
全体
QA テスト観点
レビュー
テストケース
作成機能テスト実行
機能テスト結果
レビュー
テストケース
レビュー
回帰テスト実行
結果レビュー
ライブチェック
開発(2weeks) リリーススプリント(1week)
全体
QA
開発＆テスト(2weeks)
テスト観点
レビュー
テスト観点ベー
スの
探索的テスト
全体
QA 回帰テスト実行
スプリント
レビュー
スプリント
レビュー
スプリント
レビュー
テスト観点
レビュー
プレQA
(探索的テスト)
テストケース作
成
機能テスト実行
テストケースレ
ビュー
リリース
リリース
リリース
⭐️スクラム開発導入前(オフショアでテストをしていたとき)
⭐️スクラム開発導入後(開発期間とテスト期間でスプリントをわけていたとき)
⭐️スクラム開発の現状

● 導入前(2017年ごろ)
○ 回帰テスト、ライブチェックともに全て手動で実施
■ 回帰テストはオフショアで実施してたこともあり
○ 回帰テストは手動で1日かかっていた
■ 短いサイクルでのリリース(スクラム開発)を進める中で早く回帰テ
ストを完了させることが重要になってきた
● 前任のQAマネージャーと自動テスト導入を検討

● 導入理由
○ プログラミング(コーディング)のスキルがいらない
■ シナリオ作成が簡単
■ 個人のスキルに依存しない
○ 価格がリーズナブル
○ サーバーなど自前で準備不要(メンテやアップデート含め)
○ 共有ステップでシナリオ間でテストを共有できる

● 導入理由
○ シークレット変数が使える
■ DBへのアクセス情報など含め
○ サポートが早い
■ メールやSlackなどで随時対応してくれる
○ 自動修復機能
■ 提案だけしてくれるので、こちら側で承認するか決められる
○ 外部ツールとの連携
■ Slackへの結果通知、Jenkinsのジョブ実行、CIからの自動実行

MagicPodでの回帰テスト自動化(活用)
● 共有ステップ
● 組み合わせのサンプル(実際の組み合わせではありません)
○ この場合だと5シナリオある
■ それぞれで個別にテストケースを作成するとそれだけでも大変
○ 仕様変更時などのたびに5つのシナリオを修正する必要がある
○ 実際のテストではもっと多いパターンもあることが多い
→ 共有ステップで対応

MagicPodでの回帰テスト自動化(活用)
● 共有ステップ
● 共有ステップ内ではデータパターンの値をもとに条件分岐を導入
○ 例：商品選択の共有ステップで、色が◯◯である場合、◯◯を選択する
● 最初に共有ステップを作る時間はかかった
○ その後は流用できるので全体工数としては少なく済んだ
共有ステップのメリット
● 使い回し可能
● 修正時に1つのシナリオ修正でOK
● 修正工数の削減

回帰テストの手動と自動の工数比較
● 自動テストは失敗時のメンテコスト含む
● 自動テストの作成工数は除く
● バージョンは仮
Android 手動で全て実施
自動テストが少し安
定してきたころ
期間は2年ぐらい
オフショアから内製
に切り替え

● 自動テストは失敗時のメンテコスト含む
● 自動テストの作成工数は除く
● バージョンは仮
iOS
テストケース見
直しのため
自動化初期はエラー
になるケースが多い
期間は2年ぐらい
オフショアから内製
に切り替え

● 全体工数が減ったタイミング
○ オフショアでの手動テストから内製での手動テストへの切り替え
○ 自動テストの増加
● 全体工数が増えたタイミング
○ テストケースの見直し
○ エラーのため手動で実施
○ エラーが大量に発生しメンテナンスが必要
■ テストケースの修正漏れ(修正箇所を全て修正してないケースなど)
■ アプリを更新すると要素が見つからなくなることなどがある

回帰テストの自動化率
Copyright (C) nohana, Inc. All rights reserved. ※1Sprintは2週間
テストケース見
直しのため

回帰テストの自動化率(Android)

回帰テストの自動化率(iOS)

回帰テストの自動化率
● 現状、期初の予定とほぼ同じ進捗で推移
● Androidはそのまま(現状、追加で自動化できる箇所なし)
● 今後も決済とiOSは自動化を進める予定
● Android＆iOSともにCIで定期実行を行っている(テスト環境)
○ デグレなどを早期検知するため
● 定期実行の安定化
● リリース前の本番環境でのテスト

CircleCIによる定期実行
● Android&iOSともに朝イチ定期実行を行っている
○ Slackに結果を通知
● デグレなどを検知することができている
● 結果の詳細はスプレッドシートに吐き出し、成功率を管理している

Android 1年3ヶ月ぐらいの推移
0%は環境起因のエラーなど
数字が全然わからないので、、

Android 今年に入ってからの推移

iOS 4ヶ月ぐらいの推移

ライブチェック(リリース前テスト)の自動化
● 回帰テスト完了後にリリース用アプリで基本機能のテストを実施
○ Android&iOSともに8割ぐらい自動化完了
○ Androidは約2年前から自動で実施
○ iOSは2023年1月からようやく自動化

ダッシュボード(進行中)
● magicpod-analyzerとBigQueryでダッシュボード作成中
○ 週2回のQAチームのもくもく会で（悪戦苦闘しながら）進行中

MagicPodでやっていること
● 通常のUI操作＆確認以外
○ シミュレーターへの画像追加
○ DBへのデータ追加やデータ取得
○ メールの文面取得
○ Jenkinsのジョブ実行

抱えている課題
● テストが安定しないことがある
○ 同じ環境やテストケースでもコケることがある
○ 確認や対応にコストがかかっている
● 条件分岐を多用するとテストケースがわかりにくくなる
● UIがどのシナリオで使われているかわからない(使用数だけはわかるけど)
○ UIが変更になった際に使用しているテストケースを見つけるのが困難

抱えている課題
● 共有ステップは便利だけど、部分実行できない
○ 共有ステップ内の特定の場所でコケることがあり、確認のため共有ステップから
コピペして実行している(全部実行したくないケース)
● iOSの実行時間が長い
○ 手動テストよりも時間がかかってしまうケースがある
○ Androidよりもシナリオ数は少ないが、倍以上かかる場合が多い
○ 同じテスト内容でも、実行時間が2時間以上変わることがある
■ 平均で2時間ぐらいかかるものだとして、1時間30分から3時間30分ぐらいと
幅が大きい

改善してほしい点(抱えてる課題に対して)
● テストが安定しないことがある
○ 要素の指定方法で解決するのかもしれないですが、定期実行で前日成功したとこ
ろが翌日失敗するなど
○ 自動修正の精度がさらに上がれば、少しは解決するかも
■ #269 単体実行でも自動修復が発動するように
● 条件分岐のセットがわかるようにしてほしい(#99 条件分岐コマンドのUX改
善)
○ Step数が多いテストケース内で複数の条件分岐が連続すると、条件分岐終わりが
どの条件に対してか探すのが大変なことがある

● UIがどのシナリオで使われているかわからない
○ 使われている数はわかるけど、どのシナリオわからない
○ 使用しているシナリオが簡単にわかると助かる
● 共有ステップの部分実行(#300 共有ステップの編集画面でも端末を操作した
い)
○ 失敗したところだけ確認したいケースがある
○ 現在は共有ステップ全てを実行するか、該当箇所をコピーして実行

● iOSの実行スピードの改善
○ 要素の指定などで改善できるものなのか？
● 実機とシミュレータでロケータが異なることがある
○ 同じシナリオでも成功と失敗になるケース(アプリ側の問題？)
■ 例えばview.ViewとTextViewで条件分岐をして対応
● 1スクショで1要素に複数のロケータを指定できたりすると便利かも
○ 同じスクショが必要になってしまう

改善してほしい点
● キャプチャしたUIの移動(#149 共有UIを整理しやすく)
○ セクションが多いと地味に面倒
○ 簡単にセクションを移動できると良さそう
● バージョンアップの対応(#250 Magic Pod Desktopのバージョンアップをも
っと快適に)
○ ZIPファイルではなく、サクッとアップデートできると助かる
■ 動作が停止してしまうことが多い

今後の取り組み
● テストの安定化
● テストケースのリファクタリング
○ 都度変更を入れているので、ごちゃごちゃになってきている
● 決済関連のテスト自動化
○ 現状は一部だけ自動化済み
● ダッシュボードの作成(進行中)

最後に
● トライアル(スタンダード)できるので、実際に試してみるのが良さそう
● 初期コストはかかるものの、メンテコストはそこまで高くない
● ノー(ロー)コードだと、属人化しないので誰でもできる
● サーバーなど環境準備やメンテが不要
● 共有ステップの活用でメンテコスト削減できる
● 自動化が難しいところは無理して自動化しないことが重要かも
今日お話しした内容の一部はブログでも公開していますので、ご覧ください！

MagicPodで自動化率を爆上げしたハナシ

MagicPodで自動化率を爆上げしたハナシ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MagicPodで自動化率を爆上げしたハナシ

Similar to MagicPodで自動化率を爆上げしたハナシ (20)

Recently uploaded

Recently uploaded (10)

MagicPodで自動化率を爆上げしたハナシ