概要
こんにちは！こんばんは！
最近ダイヤのエースのアニメが好きな、delyでクラシルリワードiOSの開発に携わっているtakkyです！
クラシルリワードiOSアプリ（以下、リワードアプリ）では、デグレーションを検知して外部品質を守るために自動E2Eテストツールである、MagicPodというサービスを利用しています。リワードアプリにはQAエンジニアはいないので、開発に携わっているエンジニアが上記のツールを活用して品質を担保する必要があります。
そんな自動E2EテストツールをiOSチームメンバーで運用するにあたり、存在した課題やその課題を解決するために行ったことについて、アウトプットします。
MagicPodの導入経緯やtipsに関するテックブログを公開しているので合わせてみていただけるとうれしいです！！
リワードアプリにおける自動テストツール運用に対する課題と当時の状況
まず前提として、自動E2Eテストツールを利用することの意義やメリットについて一般的には以下があります。
自動E2Eテストツールの意義
- 手動テストにかかる時間を削減し、その分エンジニアは開発に集中することができ、開発スピードの向上に寄与できる点
- 人的ミスを防ぎ、重要なフローをテストでき品質の安定化を図ることができる点
- （利用するサービスによるが）定期的にテストを実行することができ、エンジニアが働いていない時間帯でも自動テストを実行できる点
etc...
リワードアプリでは上記のような恩恵を受けるためにMagicPod（MagicPodの詳しい機能詳細等は、こちら）を導入していましたが、導入後リワードアプリの開発を取り巻く環境が大きく変わったことでメンテナーが不在になり適切に運用されておらず、当時は以下のような状況になっていました。
- テストケースが不安定な状態が続いており、デグレーション発生が適切に判断できないケースがあった点
- テストの修正方法が統一されておらず、データに依存しすぎたテストが構築されていたため、一定期間しか成功しない修正になってしまうことがあった点
- チームメンバー全体で運用されておらず、テストケースやステップのメンテナーが属人化していた点
- リワードアプリ開発のスピードに適応したツールの運用方法が取られていなかった点
- 自動E2Eテストツールの運用方法についての知見が社内には存在していなかった点
また、テックブログ等ではQAエンジニアの方が活用事例を挙げている反面、QAエンジニア以外のエンジニアの方の活用事例があまりなかったので、手探りで運用方法を考える必要がりました。
このように、改善する前の状況としてはかなり不安定な運用を行っており、自動テストツールをうまく活用できているとは言えない状況でした。
運用改善のために行ったことと目指すべき姿について
ここからは、前述した課題を解決するために個人として行なったことやチームとして行なったことについて、解説していきます！🙌
まず運用改善をチームで行うために目指すべき姿としては、最終的に以下2つパターンでテストケースが失敗する状態がベストであると考えているため、この状態を目指すことが安定運用ができていると定義しました。
- 追加実装の影響でテストケースが古くなった結果、テスト失敗が生じること
- 実装時に考慮もれや不要な修正が混じり、デグレーションが発生して意図せずテストケースの失敗が生じること
上記は、テスト観点からは普遍的な考えですが、こちらを目指すべき姿として指定しチームで安定して運用するためには解消する必要が課題であると考え、最初にテストステップの再整備から始めました。
フレーキーなテストケースを愚直に修正し安定した状態に整備する
上記を目指す上で当時一番大きな問題点として存在したのが、テストステップで確認するUIの要素等がサーバーから返却される値を確認するようにテストが組まれている箇所が多い点にありました。
あえて固定のレスポンスを設定している箇所もありますが、定期的に返却される値が変わったり本番環境にデータを設定する前に開発環境で値を変更したりしてそのまま放置されたりする場合もあったため、単にUIに表示されている値を確認するテストステップはテストが失敗しやすい状態でした。
MagicPodの公式の自動テストを簡単にするためのアプリ実装の工夫についてからもわかるように、ステップで確認するロケータは、アプリ内で一意になるようにつけた.accessibilityidentifier（以下、id）を付与してテストケースを組むことを推奨しています。そうすることで、レスポンスが変わってしまったとしても、テストが成功するようにできるので、愚直にidを振って失敗の可能性を極限まで下げる努力をしました。
リワード(iOS)アプリでは、SwiftUIでUI実装を行うことがほとんどなので、テストしたいViewにモディファイアであるaccessibilityIdentifier(_ identifier: String) でidを付与してViewを識別することで、UIに表示されている文言に関係なくステップを組めるようにしていきました。（SwiftUIではこちら、UIKitではこちら）
テストケースの改善前と後の例
| 改善前 | 改善後 |
|---|---|
 |
 |
また単純にidを付与したものを利用するだけでなく、今後のリプレイス時にidを利用してステップを組まれていることが明示的にわかるように命名もaccessibility_id=MagicPod_Hogeのようにわかりやすいものに置き換えました。
本業がスクラムタスクをこなすことがメインの自分にとっては、テストケースにidを付与して修正する作業でリソースをかなり割かれました。
実際、テストしたい箇所にidが付与されていないことがほとんどだったので、まずソースコード上にidを付与するところから始まり、変更を加えたアプリバージョンをMagicPodにアップロードする必要があるので、かなり時間がかかりました。今思えば、思い切ってidを付与してテストケースを組む作業を愚直にこなしたことで、クリーンなテストケースが構築され毎日成功するテストケースが増え安定したので粘り強く対応してよかったです。
また、上記のような取り組みを常態化させたことでチーム内でのテストケースのメンテナンス方法も 「idを付与してテストケースを修正する」 という意識を持ってくださるメンバーも増え、メンテナーによってテストケースの組み方がバラバラになってしまう問題もある程度解決できたので、結果的に各方面にいい影響になりました。
セルフ運用でチームに馴染みやすい運用方法を模索
フレーキーなテストケースの修正を経て、テストケースがある程度成功するようになってきたので、次はチーム内でどのように運用すれば効率よく負担のない状況が作れるかを考えるフェーズに移りました。
チームメンバー全員でMagicPodを運用する前に、最適そうな運用方法を私自身がセルフチェックしてみて、どのような動き方をすれば、安定可動しつつメンバーの負担も軽減できるかを考慮しながら方針作成を行いました。
前提として、リワードiOSチームの開発スタイルは、FeatureFlagを利用したトランクベースを採用しており、1日のうちにmasterブランチに数えきれないほどの変更が加わります。また、開発環境では常に新機能が確認できる状態にするため、開発環境でテストを行なっているMagicPodでも常に新しいUIになっている前提の運用方法を取る必要がありました。（リワードアプリの開発スタイルの詳細についてはこちら）
上記を鑑みて、毎日一定のタイミングでmasterブランチのデグレーションをチェックする必要があります。リワードアプリでは、平日の午前4時に最新のmasterブランチをXcodeCloudでビルドを定期実行するので、モーニングビルドのタイミングでテストケースの一括実行を行い、出勤時に一括実行のテスト結果を確認してみることにしました。
モーニングビルドからテストケース一括実行のフロー
この一括実行を活用して、出勤時に以下のようにセルフチェックする期間を1ヶ月ほど行い、運用時に負担にならないかを確認してみました。
下図のようにセルフチェックを継続し、1人で運用していたとしても負担にならないことも確認できました！🙌
セルフチェック時のスレッド
まだチーム内でMagicPodの操作や仕組みについても浸透し切っていなかったため、チームでの運用の立ち上がり期間はひとまずモーニングビルドで午前4時時点での最新のmasterブランチでデグレーションを発生していないことを担保することに決定しました。（チームでの運用に慣れた後は、リリースブランチを切ったタイミングでも行うなどの方針を考えており、絶賛整備中です！）
デグレーションを確認するタイミングに関しては上記で決定したので、その確認フローも選定したのでそちらは次で説明します。
運用時のフローについての整備
モーンングビルド後に行われる一括実行テストでチームメンバーが行うチェックフローは以下のように設定しました。
モーニングビルドのチェックフロー
運用改善前の反省を活かして、テストケースを修正しない状態が続かないように各々実装者がオーナーシップを持っていただくため、テストケースが古くなる場合はその日中にMagicPodのテストを修正するような決まりを作成し、テストが失敗し続ける状態を防ぐような方針を取ることとしました。
毎朝一括実行を行っているテストケースは現状26ケースあり毎週担当者を変更し、1人4〜5個のテストケースをチェックするようにすることで、まずはMagicPodに慣れてもらうような状態になっています。
毎朝9時にリマインダーを設定しており、各自担当箇所の確認を行う
テックブログ執筆時で1ヶ月近くこの運用方法を行っていて、チームメンバーの負担が増えることなく、現状スムーズに運用できている状況です！👍
また、リワードアプリでは、Slack上でアプリの審査提出とリリースが完結するように自動化されており、チェックの一環で上記のように確認したMagicPodのデグレーションテストをチェックしたスレッドのURLをリリースフローに入力した上でアプリのリリースを行うように整備しました。
新たに追加したデグレーションテスト確認済みのステップ設定
上図のようにURLを入力しないとリリースフローを次に進められないようにして、こちらのように入力を強制するような仕組みにすることで、デグレーションテストを確認せずにアプリをリリースするという運用の形骸化を防ぐ役割を持たせました。
下図が実際の入力例で、こちらもすでにチーム内で運用の一部として活用できており、入力されないままリリースされることもなく運用できています！🙌
実際の運用時の例
運用ルールドキュメントの策定によるチーム運用の堅牢化
ここまではデグレーションテスト自体の整備とそれのチェックの仕組みを整備し、順調にチームに馴染んでいます。
最後に、運用ルールを明確にドキュメントに落とし込むことで、チームで運用する際の指針を作成しました。
そちらのドキュメントには、上記のチェックフローの記載と以下の方針を記載しました。
- PoC段階の機能にはテストシナリオを追加しないこと
- 2~3回同じテストケースが存在した場合、積極的に共有ステップにして、使い回ししやすくすること
- フレーキーなテストは一括実行のテストに追加しないこと
- 正常なテストケースのノイズになり割れ窓理論を許さないようにするため。
- 新たにテストシナリオを一括実行に追加する際は、2~3回連続でテストシナリオが成功することを確認した上で一括実行に追加すること
- テストケースの修正が不安なときは、積極的にレビューしてもらうこと
- テストケース上のコメントアウトや空白を活用して、テストケースの可読性/内容をわかりやすくすること
などを策定しました。
今回は上記について細かく解説はしませんが、最低限チーム内でMagicPodを運用する上での決まりを決めることで、『メンテナーによってテストの修正方法がバラバラになったり』などで運用に困ることはほとんどなくなったと考えています。このように全体方針を策定することで、MagicPod管理の属人化も防ぐことができる仕組みにしました。
運用改善後の現状とまとめ
前述したように個人・チームとして運用改善を地道にコツコツ取り組んだ結果、毎朝デグレーションチェックをチーム全員で行うことができており、運用の立ち上がりとしては上々かと思います。
テストケースの一括実行も安定しており、MagicPodのテストケース自体も適宜修正して改善できてきています。
一括実行でも全て完全にテスト成功する時もかなり高確率出ている（毎回こうありたい）
今のところ追加実装により、デグレーションが起こったケースは無いのでMagicPodでのデグレーションを検知する場面はありませんが、将来ユーザー影響に大きく影響するデグレーションが発生した時に検知できるはずです！
運用的には軌道に乗っていますが、私自身MagicPodで『やれること・やりたいこと』はまだまだいっぱいあるので、それらに関しては別の記事で追って投稿したいと思います！
QAエンジニアが不在の中でも、E2E自動テストツールの運用をプロダクトを開発しているエンジニア全員で回す運用フローを仕組み化することで、外部品質を維持・向上させる取り組みは一定安定したので。今後も、テストの自動化と運用フローの改善を継続し、より品質の高いプロダクトを提供してユーザーさんにアプリを提供していきます！！
参考記事
Discussion