E2Eテストの信頼性と向き合ってMagicPodのヘルススコアが100に達した話

こんにちは、医療プラットフォーム本部 プロダクト開発室 QA グループ所属の小島大周 (@Daishu) です。2022 年 4 月に QA エンジニアとしてメドレーに入社しました。主に "クラウド診療支援システム CLINICS" のプロダクト開発における QA と、E2E テスト自動化を担当しています。

今回は、MagicPod という自動テストツールに半年間向き合い、テスト内容と結果の信頼性を高める改善を行った話をさせていただきます。

※ 自動テストツール全般に共通する話なので、自動テストに携わっている方々にご覧いただけると大変嬉しいです。

MagicPod

弊社は E2E テストの自動化に対して MagicPod というツールを採用しています。MagicPod の詳細は割愛しますが、導入時の話は「UIテストの自動化に MagicPod を導入した話」にありますので、ぜひご覧ください。

活用状況と背景

私が所属する医療プラットフォーム本部では、医療機関に向けて予約や問診、診察 (電子カルテ)、会計等の機能を提供する "クラウド診療支援システム CLINICS" と、患者向けにオンライン診療をはじめ、総合的な医療体験を提供する "オンライン診療・服薬指導アプリ CLINICS" を展開しています。

私は画像左側の医療機関向けのプロダクトにおいて社内で 周辺領域¹ と呼ぶ機能群 を中心としたQA・テスト自動化を担当しています。MagicPod は導入して4年目になりますが、半年前までこの周辺領域の機能に関しては、MagicPod を十分活用しきれておらず、以下のような状況でした。

• MagicPod の自動テスト実行頻度が週 1 回のみ
• 自動化したリグレッションテストが 3 件しかない (20件が推奨値)
• テスト結果が不安定で、自動テストの修正にかかる調査コストが大きい

また、MagicPod には "ヘルススコア機能" がありますが、当時のヘルススコアは 30 点と低い数字でした。これは端的に言うと「自動テストの信頼性が低い」という状態です。一方で、画像右側の CLINICS アプリ (患者向け) は MagicPod を十分活用できており、既にヘルススコアも 100 点に達していました。それゆえに、CLINICS (医療機関向け) の自動テストの改善が望まれていました。

MagicPod ヘルススコア機能

自動テストの改善について話す前に、MagicPod が提供しているヘルススコア機能について説明します。ヘルススコア機能とは、自動テストの活用度合いや成功率などを 100 点満点でスコアリングしたもので、2023 年 12 月にリリースされました。

ざっくりとした採点基準の内訳と配点は下記となっています。

注目すべきは、「テストから信頼性のあるフィードバックを早いサイクルで得られているか」を重視している点です。これは、手動テストの工数削減や、自動テストでの不具合検出数のような費用対効果を意識した指標ではなく、開発生産性への貢献を意識した指標となっています。スコアが低いということは「テストに信頼性がなく必要なフィードバックが得られていない」ことを意味しており、自動テストが開発生産性に貢献できていない状態となります。

私個人も、テストカバレッジが十分ある自動テストが統合ブランチでパスしているなら「開発ブランチで不具合を潰してマージされている」と考えますし、自動テストでは「統合ブランチが stable であることを保証する」ことが、「不具合を見つけた件数」と並んで重要と捉えています。ヘルススコア機能がリリースされたことで、こういった活動も定量的に測定できるので重宝しています。

主に3つの改善を実施しました

本題である E2E 自動テストの改善について話していきます。約半年前から本腰をいれて自動テストの信頼性向上に取り組みました。

① デイリー実行で不安定なテストを解消した

早いサイクルでフィードバックを得るには、自動テストのデイリー実行は必須です。そもそも、ウィークリー実行にしていた理由は、テスト結果が不安定なケース (以下、Flaky test) が多数あり、不具合かどうか調査するコストが大きかったからです。実際、調査してもほとんどが Flaky test で自動テスト側の不備で終わることが多く、ここに時間を割くなら開発機能の QA に使いたいという考えが当時ありました。とはいえ、Flaky test と一口に言っても突き詰めると何かしらの原因があり、発生パターンは限定的です。テスト結果を信頼できるものにするためにも、デイリー実行で Flaky test と向き合いました。

まず、デイリー実行すれば Flaky test となるパターンに遭遇できます。次に「なぜ Flaky test として失敗するのか？」を 1 件ずつ追求していくことで、見つけた "穴" を確実に塞いでいきます。そして、この活動を毎日繰り返すことで、堅牢で精度の高い自動テストを構築できました。これは信頼性のあるフィードバックを得る上でも重要な要素でした。今は「自動テストはデイリー実行で育てるもの」という考えで、日々の自動テストの結果と向き合うことができています。

② テストケースの二重メンテナンスを止めた

テストカバレッジが十分でないと、毎日自動テストを動かしても「統合ブランチが stable である」と言い切ることはできません。信頼性を高める上で、テスト対象とする機能の充実化は必須要件でした。しかし、当時のリグレッションテストの自動化フローは、手動テスト用のケースをスプレッドシートで作成した上で自動化する流れとなっており、テストケースを二重メンテナンスする形となっていました。このように本来の必要以上の工数がかかってしまうことからテストカバレッジを素早く上げづらい状況がありました。

手動テスト用のケースは、自動化後に触る機会がほとんどないにも関わらず、仕様変更などで自動テストに手を加えるたびにメンテナンスコストが発生します。もちろん、仕様キャッチアップ等の特定シーンで役立つ事はありますが、常にではありません。こういった運用コストの課題もあり、テストケースの二重メンテナンスはしない方針 に切り替えました。

現在は下記フローで MagicPod のテスト実装のみ行なっています。

この方針により、約半年で CLINICS の周辺領域に含まれる機能のテストカバレッジを 100% まで拡充できました。一方で、手動テスト用のケースがないことで「テストケースを使った仕様キャッチアップができない、そもそもどんな自動テストがあるのか外から見えづらい」とった課題が生まれましたが、MagicPod がテスト実行時に取得するキャプチャを用いた仕様書や、機能一覧と自動化したテストケースをマッピングした資料を用意することで対応しています。この取り組みについては、別途またご紹介できればと思います。

③ 先行して共有ステップを作成した

この改善が最も成果に結びつきました。共有ステップとは MagicPod の標準機能で、テストステップを汎用的なステップ (関数化) として流用できるものです。一般的に、複数のテストで同一のステップがある場合、共有ステップを作成されると思いますが、私は現時点で同一ステップがなくても、先行投資的に共有ステップを作成する方針で実装を進めました。これにより、早い段階で共有ステップを拡充できました。

現在は、共有ステップをパズルのように組み上げる、実際のコーディングに近い実装スタイルを確立できました。実装スピードは格段に上がり、再発防止等で確認項目を追加する場合は 10 分ほど、ゼロから大きめの E2E テストを実装する場合でも 1-2 時間ほどで作成できます。

実装スピードの向上はテストカバレッジを上げる上でも役立ちましたが、他のテストで動作保証できた共有ステップを使い回すことで「デイリー実行で自動テストを育てる前から安定したテストを作りやすい」という点も大きかったです。

改善した結果どうなったか

一番の成果は、前日にマージされた Pull Request の不具合検出が毎朝行えるようになり、冒頭紹介した「テストから信頼性のあるフィードバックを早いサイクルで得られる」点が達成できたことです。また、テストカバレッジも十分あるので「統合ブランチが stable である」ことが保証でき、機能開発や QA しやすい状況づくり (=開発生産性) にもコミットできていると思います。

障害発生時には、MagicPod で再発防止策の自動テストを作るという手段を QA エンジニアだけで完結できるようになりました。これまで QA 側で対応できることは手動のリグレッションテストを追加する方法が多かったですが、自動テストで再発を抑止するという解決手段を QA エンジニアが持てることは運用コスト的にも大きいです。

これらの改善を通して、開発エンジニアの方々からの自動テストに対する信頼感が高まってきた、と感じることも増えてきました。

また先日にはMagicPod 社のミートアップイベントに登壇する機会もいただきました。登壇時に利用したスライドは下記です。共有ステップの Tips や安定した Xpath ロケータを取得する方法などを紹介しているので、既に MagicPod を利用されている方はぜひご覧ください。

今後やりたいこと

上述した改善により、CLINICS (医療機関向け) の周辺領域における MagicPod のヘルススコアは 30 点から 100 点まで上げることができました。現在は、自動テストの新規追加や変更を加えた際にスコアが変動しないか注視しながら改善を継続しており、デイリー実行する自動テストの安定稼働と拡張の両立ができています。

今後もこのプロセスを崩さず、CLINICS の基幹領域² に対してもテストカバレッジを広げていきたいと考えています。まずは、基幹領域の中でE2Eで確認すべき機能の洗い出し、次に洗い出した機能の自動化タスクを個人にアサインできる体制づくりを検討しています。そのためにも、オンボーディングやレビュー体制、コーディングルール等の仕組みづくりもセットで考えていきます。

また、CLINICS に携わる開発の方々は実装しながらテストコードを書く素晴らしい文化がありますが、MagicPod の自動テストと一部重複して確認している箇所があります。テスト対象は重複しつつも、テスト粒度の方針を定めて自動テスト全体の最適化にも取り組んでいく予定です。

おわりに

私が所属する医療プラットフォームの QA チームはいわゆる完全内製型で少数体制です。しかし、MagicPod の実装の容易さ、メンテナンスコストの低さにより少数でも複数のプロダクトを広範囲でカバーできています。組織体制にも大きく貢献できる MagicPod は素晴らしいツールです。この場をお借りして改めて感謝申し上げたいと思います。いつもありがとうございます。

メドレーは、現在 QA エンジニアを募集しています。医療分野における高い品質目標と、いち早くお客様に価値提供するという課題の両立に対して、QA エンジニアだからできる解決策の打ち手を一緒に考えてコミットしていける方と是非お会いしたいです。

https://open.talentio.com/r/1/c/medley/pages/88835