第二回MagicPodユーザーミートアップにて発表したスライド

1. MagicPod 活用事例
QAエンジニア 米山 允章
2022年1月24日

2. アジェンダ
1. 自己紹介
2. 会社の紹介
3. メドレー × MagicPod
4. 事前に頂いたトピック
5. 今後QAとして取り組んでいきたいこと

3. 自己紹介

4. ● 米山 允章 (Yoneyama Yoshiaki)
● 所属 : 株式会社メドレー 医療プラットフォーム本部
● 2020年8月に入社
● 前職はメルカリで5年半ほど在籍
○ 前職ではXC(UI)Test, Ruby (Appium)などでUIテストを運用
● 好きなもの : お酒, 活字, コーヒー, 音楽 , ベイスターズ 等
● 最近ハマったもの https://judgment.sega.com/
自己紹介

5. 会社の紹介

6. 2009年創業。「医療ヘルスケアの未来をつくる」というミッションのもと、テクノロジーを活用した事業やプロジェクトを通じて
「納得できる医療」の実現を目指す会社。
求人サイト「ジョブメドレー」を運営する人材プラットフォーム事業、オンライン診療システム「CLINICSオンライン診療」や患
者のための医療情報サービス「MEDLEY」などを運営する医療プラットフォーム事業を展開。
人材プラットフォーム 医療プラットフォーム
株式会社メドレー

7. メドレー × MagicPod

8. MagicPodの契約状態
契約プラン : スタンダード (アプリ / ブラウザ)
(2020/8/16 入社)
2020/10 : アプリ版のトライアルを開始
2020/11 : アプリ版の契約開始 (月契約)
2020/12 : ブラウザ版のトライアルを開始
2021/1 : ブラウザ版の契約開始 (年間)

9. MagicPodを使用しているプロダクトの構成
歯科
診療所等
SaaS

10. 体制
医療機関向け 患者向け
Web
iOS
Android
PM
QA
基盤
アプリ
基盤
PM
QA
薬局向け
デザイナー
アプリ
インフラ
PM
デザイナー
歯科向け
アプリ
インフラ
PM
デザイナー

11. MagicPodの主なユースケース
① developブランチで毎朝定期実行 (git flow)
② 影響範囲が広い変更に対しては個別で実行
-リファクタリング、ミドルウェアのアップデートなど
③ Releaseブランチ生成後はRelease環境でも実行
④ リグレッションテストの追加においては、まずはMagicPodで作成し、自動化が困
難な部分のみ手動テストで対応している

12. 事前に頂いたトピック

13. - 使っているプラットフォーム(web and mobile app。クラウド環境、etc)
- 自動テストの導入背景。導入前の課題があれば
- 自動化の導入をどのようなステップで進めたか、どのようにチームに浸透させたか。
Magic Podを使い始めたばかりのユーザーさ
んに有益な情報だと思います。
- CIとつなぐこと、毎日回すことによって得られるメリット。リリース前しかテストしていないユーザーさんもまだまだおり、
CIとつなぐこと
のメリットを多くの人に認識してもらいたいと思っています。
- クラウドで自前で環境をメンテナンスしないことのメリット。ローカル
PC環境で自動化をしているユーザーさんに、クラウドのメリットを
知って欲しいと思っています。
- 自動化の運用で気をつけるべきこと
(属人化、メンテナンス、Flaky対策、など)
- 大規模なUIのリニューアルにおいて、スクリプトを作り直す経験談
- 手動と自動の使い分け。開発側でしている自動テストや
UIテスト以外のテストがあれば、どんなことをしているか。
- テストシナリオをどこで考えどこでメンテナンスしているか
(Excel?)。手動と自動のケース一元管理、結果管理
- Magic Pod内での、テスト管理方法(命名規則、ラベルつけ、等々あれば
)、UI管理方法(セクションわけ、命名規則、等々あれば
)、
共有ステップ管理方法(命名規則等々あれば)。多くのユーザーが他社例を気になるところかと思います。
- 複数人でテストをメンテナンスの運用フローや
気をつけていること、注意点
- テストデータ(DBデータ)の生成や管理方法。結構正解がない分野で、他社事例が参考になる部分です。
- テストの冪等性や独立性を保つためにどんな感じでテストを組んでいるか
(していれば)。意識できていないユーザーさんも多いよう
に感じます。
- テスト容易性のためにテスト対象アプリケーション側に手を入れたことがあれば、その工夫内容
(Web APIを提供した、要素にidを
割り当てた、など)
‐ 外部アカウント連携も含めたUIリニューアルの際、どんなことを意識・工夫されたか。
- 今後QAとして取り込んでいきたいこと(自動化以外も含む)

14. MagicPodを使用しているプラットフォーム
医療機関向け 患者向け
Web
iOS
Android
PM
QA
基盤
アプリ
インフラ
PM
QA
薬局向け
デザイナー
アプリ
インフラ
PM
デザイナー
ブラウザ
iOS
Android
ブラウザ
ブラウザ
クラウド クラウド
クラウド+ローカル

15. 自動化の導入をどのようなステップで進めたか、
どのようにチームに浸透させたか
1.チームメンバ、上長へのヒアリング
2.トライアルを開始
a. 同時に他ツールも試してみる (期間の縛りもあり並行での検証は辛かった)
3.開発メンバへツールの紹介、デモ
a. 興味のあるメンバはトライアル招待
4. ブロッカーの解決 (二段階認証等) w/ 伊藤さん
5. E2Eテストのデイリー実行
a. いくつかバグを見つける
6. プラットフォームの拡張
※ UIテストの自動化にMagic Podを導入した話 も参照

16. CIとつなぐこと、毎日回すことによって得られるメリット
(個人的に考えている) テスト自動化のメリット
手動テストの工数削減 ＜ 不具合をより早く検知すること
+ いつでもリグレッションテストを回せること
出典
JASPIC SPIJapan2009 奈良隆正「ソフトウェア品質保証の方法論、技法、その変遷」

17. CIとつなぐこと、毎日回すことによって得られるメリット②
任意のブランチでいつでも実行できる

18. クラウドで自前で環境をメンテナンスしないことのメリット
① テスト自動化において、工数を取られるのは実装工数より環境構築
- 特にビルドの待ち時間がかからないのは大きい
② ローカルで環境構築すると、PCも悲鳴を上げるがクラウドだと無影響
- 私のようにChromeのタブを開きまくるタイプは特に..
③ 環境設定の状態を他メンバにも容易に同期できる
- なぜ私の環境だと動かないんだろう..というのはよくあるので

19. 自動化の運用で気をつけるべきこと(属人化、メンテナンス、Flaky対策など)
①属人化
属人化しないようにすることは非常に重要
- 個人的にも過去、担当者が移動 or 退職により廃れた自動テストを何度も見てきました
対策
1. 属人化しているようであれば、まずはその課題をチームに共有する
2. 皆さん興味はあるので、オンボーディングする
3. 機を見て、良い案件があれば実際にシナリオを作ってもらう or メンテしてもらう

20. 自動化の運用で気をつけるべきこと(属人化、メンテナンス、Flaky対策など)
② メンテナンス
テストが落ちた状態で放置しない
• 落ちているのが当たり前の状態では誰もそのテスト結果を気にしなくなる
• 本当にプロダクトの不具合により落ちている場合でも検知できなくなる
他タスクと並行して片手間でメンテできるくらいの成功率を目指す

21. 自動化の運用で気をつけるべきこと(属人化、メンテナンス、Flaky対策など)
③ Flaky対策
E2Eテストの肝
• 必ず原因はある
• 実行環境の差異, 前テストの影響, 高速で動くことの影響, 実行時間帯など問題を切り
分ける
• リトライが動くと本来失敗していた箇所がわからなくなりがちなので、リトライをオフにしてみ
るのもお勧め

22. 大規模なUIのリニューアルにおいて、スクリプトを作り直す経験談
実績: 2週間程 / 1プラットフォーム
• 自前でE2Eテストを用意している場合と比較すると、作り直しも遥かに早い
• 内部構成の変更に依存せず、新たな環境構築も不要。UIベースでシナリオを用意できるため
• ただ理想的には開発と並行してE2Eテストを用意したい所..
• 共有ステップでカバーできている割合が高いほど作り直しも早い
• (地味に) リニューアルの開発工程において、既存アプリへのデグレ確認でも活躍した

23. 手動と自動の使い分け
開発側でしている自動テストやUIテスト以外のテストがあれば、どんなことをしているか。
自動化に向いていないテストは手動
• SMSやPush通知、ビデオ通話、QRの読み取りなどは手動で確認している
• UIの確認のみはビデオ通話やQR読み取り画面も自動テストに含めている
• メールは自動テストに含めている
• リニューアルなど、新規機能はまずは手動で確認している
• リグレッションテストのフェーズで自動化する
• 全てのテストを自動化したいという理想と現実の境目をしっかりとわきまえる, 説明できることは大事
• 一部コードベースでもテストを書いているが基本的にはこれから
• アプリは現状E2Eテストの比重が大きい
• 開発側でも実装後には手動でテストを行っている

24. テストシナリオをどこで考えどこでメンテナンスしているか
手動と自動のケース一元管理、結果管理
① まずは手動で行っていたリグレッションテストをベースに自動化
• リグレッションテストはSpreadSheetで管理
② その後に追加したシナリオはMagicPodのみで管理している
• チームメンバは皆、MagicPodを参照できる
• テスト結果はslackに通知している

25. Magic Pod内でのテスト、UI、共有ステップ管理方法
(セクションわけ、命名規則、等々あれば)
● 基本的に各プロジェクトのオーナーがよしなに命名
● 明確なルールは特に設けていない (他メンバでも見れば分かる状態であれば良いかなと..)

26. 複数人でテストをメンテナンスの運用フローや気をつけていること、注意点
● テスト内容・観点はベースとなるマスタを用意する
● オーナーは必ずレビューに入る
● イレギュラーな対応 (テストケースから目的が読めない部分) にはコメントを入れる
●
●
●
●
●
●
●
● テストデータは一元管理する（コンフルに纏めてリンクを貼っている)
● 追加したいテストがあればとりあえずIssue化しておく

27. テストデータ(DBデータ)の生成や管理方法
● 他のテストの影響を受けないよう、UIテスト用のデータ(医療機関など)を用意する
● 特定の状態のテストデータを用意する (=データの仕込みまで自動化しない)
○ 1件だけ予約が未了のユーザ
○ クレカの有効期限が切れているユーザ
○ 家族アカウントで初診完了しているユーザ etc
● 新規登録系のテストは、必ず退会で終えてループできる状態にしておく
● オーナー不在でもメンテできるよう、テストデータはID/PWまでドキュメントに書いておく

28. 今後QAとして取り込んでいきたいこと

29. 今後QAとして取り込んでいきたいこと(自動化以外も含む)
● (引き続き) 開発者が設計に入る前に不具合の元をなるべく多く摘出したい
○ 不具合発見フェーズがリグレッションテストでは少し遅いので
● テストピラミッドの最適化
○ 量だけでなく質的にも
○ 特にAPIテストを充実できれば問題特定の調査にも活用できる
● マージ前のテストでも自動テストを活用しやすくする
● テストの安定化に繋がるのであれば各要素にID付与も検討したい(プロダクトに一部手を入
れる)
● 手動テストは極限まで最小化したい
● 開発側へのテスト観点のシェア (早い段階で不具合を検知してもらえるように）
(個人的な野望)
● もっと自らプロダクトにPRを出して改善していけるようにしたい

30. ご静聴ありがとうございました！
交流タイムに皆さんの事例もお聞きしたいです！