この記事は弥生 Advent Calendar 2024の3日目のエントリーです。

こんにちは！弥生で会計NextというサービスのQAエンジニアをしているはるたです。担当している会計Nextというサービスは、新規でサービスを開発して、先日リリースをしたサービスになります。

開発期間中からMagicPodを使ってE2Eテストの自動化を行うという取り組みをしてきました。今回はどのようなきっかけで自動化を進めることにしたのか、どのようなことをやったのかをお伝えしたいと思います。

はじめに

本題に入る前に、現状のE2Eテストの実行状況をお伝えします。基本的な操作を中心に実行しています。今でこそ、運用ができていますが、これまでなかなか難しいこともありました。

環境	用途	実行頻度	テストケース数
テスト環境1	機能開発時のテスト環境	2回/1日	5
テスト環境2	障害対応や小規模な改善など保守用のテスト環境。基本的に本番と同等のアプリケーションが動いている	1回/1日	3
本番環境	サービスが稼働している環境	2回/1日	3

E2Eテストの自動化を始めることにしたきっかけ

会計Nextの開発は一度にすべての機能を作るのではなくて、開発→テスト→リリースのサイクルを何回か繰り返す形で進めてきました。

最初のころのサイクルで、テスト期間中に、テスト環境にデプロイされたアプリケーションがログインできなくなった、ということが何回か起きていました。そのほかも以前は○○ができていたのに、できなくなった、ということがありました。理由は、アプリケーションに問題があったというときもあれば、デプロイ手順の問題のときもあったりと様々です。

今後プロダクトを成長させていくフェーズに入っていく中で、なんとか改善したいと思いました。アプリケーションの変更頻度が多くなるため、同様にデグレードの問題が起きる可能性があります。手動で操作してみて気づくというやり方では、問題が起きてから気づいて対応するまで時間がかかってしまうと思いました。デグレードが起きた時に早く気づいて、エンジニアメンバーにフィードバックするという仕組みが作れないかと考え始めました。

当時の状況と課題

自動化を始めるにあたっての課題は2つありました。

仮に自動化をしたとして、画面の変更に合わせた自動化したテストケースのメンテナンスは大変そう
- これから大幅に機能追加・変更をしていく予定が見えていました。画面も増えるし、画面要素も変わる予定でした。一度作ったテストケースを画面の変更に合わせてメンテナンスを行う時間はそれなりにかかるであろうことが予想できました。
自動化に取り組む時間が確保できない
- 当時はQAエンジニアは自分1人でした。自動化も重要なテーマではありましたが、これから作っていく要件や仕様の理解とテストの検討、障害管理ルールの作成と定着、QAチーム立ち上げに向けた採用活動と受入など、やりたいことは無限にあります。開発メンバーも同じような状況で時間の確保は難しい状況でした。

本当に達成したいことは何か

上記の「メンテナンスが大変そう」という課題と「時間が確保できない」という課題は、頑張ってどうにかするものではないと考えました。自動化の仕組みを作るというのは継続的な取り組みになります。短期的にパワーをかけて対応するものではなくて、継続することを前提に考えたほうが良いと思いました。そのためには、最低限達成したいことは何か、現実的にはどのくらい時間を使えるのか、を整理して、方針を考えることにしました。以下は当時考えた時の私のメモです。

今後の開発計画を見越した時に、どのぐらいの時間だったら、自動化に使っていけそうか →週に2～3時間なら続けて時間を捻出できそう
→だったら、週に2～3時間でできる範囲でやろう

最低達成したいことは何か
→テスト環境でログインができなくなっていることの検知だけでもできればうれしい

そのためには何が必要か
→定期実行が行われている必要がある。さらに、早期に検知してフィードバックができるようにしたい

これから画面がどんどん変わっていくけど、その中でもメンテナンスが継続できる必要がある
→メンテナンスを継続するにはどうしたらよいか？
→実行するテストケースの数は絞る。広げない。

手順も短く、期待結果の確認もそんなに厳しくやらない

次の画面に遷移すればOKぐらいの感覚で

作り変えることになっても何とかなるぐらいのボリューム

運のよいことに、他のチームがMagicPodの導入を検討しているという話を聞きました。自分でテストコードを実装して定期実行の仕組みを作るより、短い時間でやりたいことが実現できそうと感じたため、MagicPodを使って、上記で決めた方針で進めてみることにしました。

１つだけテストケースを作り、定期実行ができるようにする

まず、ログインしてホーム画面を表示するテストケースを作成しました。ログインして、ホーム画面に遷移するだけです。

ログインする
ホーム画面に遷移することを確認する

これぐらいなら自動化せずとも手動でテストしても変わらないのでは？と思ってしまうほどの簡単なテストケースです。もっとちゃんとしたテストケースを作りたい気持ちを抑えて、まずは最小限の範囲を定期実行する仕組みを作る、という方針を変えずに進めました。

定期実行を行う仕組みについては、 MagicPodの一括実行機能を使って、1日1回定期実行するようにしました。専用のSlackチャネルを作って実行結果が通知されるようにしました。これで最低限やりたいことは達成できました。しばらくはテストが失敗したりと結果が安定しなかったので、都度修正しつつ、定期実行の結果を確認するということを続けました。

基本操作やデグレードが起きた操作を中心にテストケースを少しずつ増やす

最初に作ったログインするテストケースが安定して成功するようになったため、テストケースを増やすことにしました。どういう範囲を自動化するか？ということについては、下記を考慮して選んでいます。

基本操作で使う機能
開発の最初のころからある機能
- 変更頻度が高い場合、デグレードの可能性が高い
デグレードによる問題があった機能

テストケースを増やすときに注意したことは、「自動化に使う時間は、週に2～3時間」という最初に決めた上限を守るということです。例えば、以下のようなことを気を付けました。

テストケースを作りすぎない。メンテナンスも含めて、継続していけるボリュームに絞る。
なるべく時間をかけずにテストケースの作成・メンテナンスを行う。とにかく楽にできるやり方を採用。
- 期待結果の確認はMagicPodの「画像差分チェック」機能を利用し、画面項目ごとに期待結果確認の手順を書かない。
- テストケース作成に難航したら、その部分は自動化ではなくて手動テストで確認すると整理して、他の部分のテストケース作成に移る。

テストケースを大きく増やさない代わりに、作成済みのテストケースのメンテンナンスはきちんと行い、成功するテストが実行されているようにしました。

定期実行の結果は毎回確認する
テスト結果が失敗や要確認となっていた場合（＝成功ではない場合）は、放置せずその日中に対応（テストケースの修正やアプリケーションの修正）をする

やってみて成果は出たか

日次で定期実行しているMagicPodのおかげで、デグレード混入してから1営業日以内には検出ができるようになりました。開発メンバーにフィードバックをして早い段階で対処ができました。定期実行をしていなかったら、気づくのがもう少し遅くなったと思います。導入したきっかけがデグレードを早く検知したいということだったので、この点で導入した目的は達成できたと考えています。

別の切り口として、「自動化やりたいんだけど、今は難しいんですよね、、」という状況から「小規模だけど、テストの自動化の運用回してます」という状況に変えることができたというのも成果の１つと考えています。0から0.1ぐらいの変化ではありますが、この違いは大きいです。

ヘルススコア

2024/11/14のMagicPodのヘルススコアです。何とか、80以上（健全）をキープしています。この調子で続けていきたいです。

まとめ

新規のサービスを開発しているときに、どのように自動化を取り組んできたのか、ということを書いてきました。自動化の範囲はまだまだ少ないものの、最低限達成したいと考えていたことは達成ができているため、よかったと思っています。
一方で、限られた時間で進めてきているため、後回しにしていることもあります。その一つに、メンテナンスしやすいようにテストケースの共通化を進める、実行時間を短くするように手順を組み替える、といったような、作成したテストケースの改善があります。改善よりもさらに進んで、これまで作ってきたテストケースを作り変えてもいいかもしれないとも思っています。どのようなやり方をしたとしても、継続して、アプリケーションの状況をチームにフィードバックしていくために、日々の取り組みを続けたいと思っています。