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

by Kohei Tai

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Copyright (C) nohana, Inc. All rights reserved. 回帰テストの手動と自動の工数比較  Copyright (C) nohana, Inc. All rights reserved. ● 自動テストは失敗時のメンテコスト含む  ● 自動テストの作成工数は除く  ● バージョンは仮  iOS  テストケース見直しのため  自動化初期はエラーになるケースが多い   期間は2年ぐらい   オフショアから内製に切り替え 

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

No content