HacobuのモバイルアプリチームでMagicPodを導入して使ってみた！

ツール導入前の課題

以下に関して課題感があり、E2Eテスト自動化によって解決できないかと考えていた

• マスタ関連の機能改修をする場合、影響範囲が膨大になりテストスコープの切り分けミスが多発している。
• 機能改修の際に、テストをしていない機能（影響範囲外と考えられる機能）にデグレが起きていないことを証明できないので開発＆QAがともに不安。
• 機能改修の際に、テストした画面だったとしてもデグレに気づかないことがある。
• ライブラリのバージョンアップなどの際に、既存機能全体に影響があるので正常系を一通り実施する必要があり、毎回手動で実行するのは工数もかかるし担当者が異なると実施内容が安定しない。

どのような状態を目指していたか

学習コストができるだけない状態で自動化を導入しリグレッションテストを行える状態。

• ツールのコスト
• モバイルアプリの検証ができるかどうか
• 運用のしやすさ

【テスト自動化のコスト】

• 「実行回数無制限」となるため、長期間安定して品質の担保を行う上では決定的な優位性を持つ
• 料金体系もシンプルで低コスト

【モバイルアプリに対応しているかどうか】

• 対応している
• SP端末のOSVer.についても広く対応している

【運用のしやすさ】

• 実行回数無制限のため気軽に試せる
• 一括実行の設定などもしやすい

どのような成果が得られたか

本格的な運用はこれからとなりますが、それ以前の段階で既に以下の成果が出ています。

• 自動化の運用についての学習
  • 自動化の環境構築についての学習実行回数が無制限であるため、テストケースを作成して気軽に実行することができます。
• 自動化に対する意識づけ
  • MagicPodで自動化できるかどうかというようなことを要件をレビューする段階で意識できるようになりました。

• CI/CD連携など、開発よりの知識が必要になってくること
• スクラムの中でテストを実装していくのがなかなかまとまった時間が取れず難しい
• テスト対象の選定、どこまでテストするかの見極め
• 導入以降に発生した障害をどこまで取り込んでいくかの見極め
• 要素の指定方法や変数の命名等を初期で決めておかないとテストケースが属人化する

• ノーコードでの作成は可能だが、コードの知識がない状態でケースを作成すると保守性の低いテストケースが残ってしまうのでコードについても学習していくことが望ましい
  • MagidPod上のテストでパラメータをハードコードしてしまうと、仕様変更にともなうテストケース修正の際にテストケース自体のテストを行う必要がある
  • 不要な分岐を作ることでテストの意図が分かりづらくなる

ロケーション指定について、FEの経験があるとより適切なロケーション指定ができるようになるため、FEメンバーと情報共有しながら活用していきたいと考えています。