この記事は、2026年2月に開催された社内カンファレンス「開運冬まつり2026 Day1セッション」のQAエンジニアレーンで発表されたLTをブログ形式にして発信しているものです。
2026春QAエンジニアリレーブログの、4本目の記事です。
こんにちは！GaroonのQA（品質保証）エンジニアをしている福元です。
普段はGaroonのTsukimi（インフラ移行）チームで、テスト設計・実施やテストマネジメントを担当しています。2022年に新卒入社し、今年で5年目になります。
社内カンファレンスの1レーンとして、「テスト実施以外の、QAエンジニアの活動」というテーマでQAエンジニアによる発表がありました。 そのレーンで、チーム配属後から約3年半コツコツ続けている「既存テストの改善活動」について発表したので、その内容をお話しします。
「CI通してるんで、ちょっと待ってください！」
チームに配属されてしばらく経った頃、開発中にこんなやり取りを何度も見かけました。
「CI通してるんでちょっと待ってください！」
「今月もリグレッションテスト（200ケース x 4環境）お願いします！」
現在は各チームでテストコードの改善やテストケースの見直しが進み、こうした声は少しずつ減ってきていますが、当時はE2Eテストが不安定で、手動テストも過剰にある状態でした。
「この分野には興味がある」「なんとなく解決案も思いつく」「空き時間もある」ということで、先輩のakihisa1210に相談し、個人タスクとして改善活動を始めました。 取り組んだ内容は大きく3つです。
- 既存テストの修正 ― 不安定なテストを直す
- 既存テストの解体 ― やりすぎていたテストを見直す
- 新規テストの作成 ― テスト構成のバランスを整える
既存テストの修正 ― お祈りRerunからの脱却
残念ですが、CIで失敗したテストのRerun成功を祈りながら繰り返しても、絶対に成功しないケースがあります。
たとえば通知のE2Eテストでは、作成されたデータが環境に残るため、Rerunしてもデータの件数が合わず、その日はもう成功しません。
ところが、失敗したテストのRerunではなくCIジョブの再実行や翌日の再実行では環境が作り直されるので成功します。すると「運が悪かっただけか」で済まされてしまい、誰もテストコードを修正していませんでした。
こういった冪等に実行できないテストを見つけては、冪等に実行できるように修正する、ということを繰り返しています。
既存テストの解体 ― 毎月200ケース x 4環境、本当に必要？
チーム配属直後、毎月決まった定常タスクがありました。約200ケースのテストを、ブラウザ4環境で実施するというものです。
最初は「こんな機能があるんだ」と新鮮な気持ちで取り組んでいましたが、何回かやっていると、ふと思いました。
「このテストケース、環境ごとにやる必要あるかな？」
チームメンバーの力も借りながら、不要なケースの削除や手動テストから自動テスト（E2Eテスト）への移行を進めていきました。
E2Eテストの実行速度も改善する
手動テストは減らせたものの、自動テストの方にも問題がありました。
Garoonの開発では、ブランチ名に -with-e2e を付けるとコミットごとにE2Eテストが実行されます。開発者はこれを使ってリリース可能な状態のアーカイブをQAに渡してくれるのですが、テスト数が約600件。不安定なテストも紛れていたため、「いつになったら実行終わる？」という状況でした。
こちらもテストケースの削除・統合を行い、実行速度の改善を進めています。
新規テストの作成 ― E2Eテスト偏重からの脱却
「テストが多くて困っているのに、新しくテストを作るの？」と思われるかもしれませんが、理由があります。
Garoonの自動テストは、手動テストを自動化する際にすべてE2Eテストとして実装されたため、E2Eテストとユニットテストの二層構成になっていました。E2Eテストはユーザー視点で動作を保証できる反面、不安定で実行時間が長いです。この構成はバランスが良いとは言えません。
そこで、E2Eテストとユニットテストの間に位置するインテグレーションテストの導入を提案しました。今回導入するインテグレーションテストは、ブラウザを使わずにHTTPリクエストを直接送信し、レスポンスのHTMLやJSONを検証するテストです。このテストでは、ある程度ユーザー視点での動作保証ができて、かつE2Eテストよりも安定して短時間で実行できます。
これまでは個人活動として進めてきましたが、影響範囲が大きく、チームとしてのアドバイスも欲しいということで、2026年1Qから開発チーム内の公式プロジェクトとして活動を始めました。
改善活動のために勉強したこと
個人で一から始めた活動だったので、たくさんのことを勉強しました。
- 現在実行されているテストの内容を理解する
- 既存のテストコードの書かれ方を把握する（プログラミング言語自体の理解も含めて）
- 自動テストの理想的な状態とは何かを考える
- インテグレーションテストの実装方法を調べる
進め方としては、書籍やWebで調べて、実験してみて、その結果を先輩やAIに相談する、という繰り返しでした。
改善活動の難しさと楽しさ
難しさ
- 同意を得ること: 影響範囲が大きいので、いろいろな人に「こんなことをしたいんだけど、どう？」と相談しながら、同意を得られる案を作り上げるのが大変でした。
- 時間の確保: TsukimiチームのQAとして一番時間を割いていた業務はテスト設計・実施なので、テスト業務の合間に進めていました。改善を一気に進めたい気持ちをぐっと抑えつつ、コツコツ続けてきました。
楽しさ
- 成果が目に見える: 手動テスト数が減ったり、自動テストの実行速度が上がったりと、効果がはっきり見えるのでやりがいがあります。
- 仕事の幅が広がった: CI周りや自動テストの中身を把握しているので、関連するタスクの依頼や質問が増えました。幅広く頼ってもらえるのは、素直に嬉しいです。
今後の展望
まずは、インテグレーションテストへの移行を進めていきます。
改善が終わったらどうなるか？
また次の改善が始まります。テストの改善に終わりはないので、引き続きコツコツ取り組んでいきます。
開運冬まつり2026のQAエンジニアレーンでは、他にもさまざまなテーマで発表がありました。他の発表者のブログも順次公開予定ですので、ぜひそちらもご覧ください！
