こんにちは、株式会社UPSIDERでQAエンジニアをしているkitazawaです。
「プロダクトリリースが増えるにつれ、手動テストの負担がじわじわ大きくなってきた」
「テストはあるけど、誰がやっても結果がバラついてしまう」
そんな悩みを持つQAや開発チームの方に向けて、私たちが取り組んできたリグレッションテストのパッケージングと運用改善の話を紹介します。
🔍 背景と課題
リグレッションテストは、プロダクト品質を守るうえで非常に重要な工程です。
とくにリリース前のタイミングでは、短時間で・確実に・過不足なく機能確認を行う必要があります。
このときに重要なのが「誰がやっても同じ精度で確認できる」再現性のあるテスト構造です。
しかし、以前の私たちのチームでは、以下のような課題がありました：
- テストケースが点在し、複製・整理が煩雑
- テストの進捗を一覧で確認できず、管理も手作業
- チェック項目が毎回ブレがちで、属人化の温床に
とりわけ、毎リリースで繰り返し使う基本的なテストケースですら、整備が不十分なことで視認性が悪くなり、「いまどのテストが済んでいて、どれが未実施なのか」がぱっと見で把握できない状況が続いていました。
その結果、進捗確認や実施状況の把握に余計な手間がかかり、肝心のテスト実行より“管理のための作業”に時間を取られてしまうという本末転倒な状態に陥っていたのです。
📦 リグレッションテストのパッケージングとは？
🔁 リグレッションテストとは？
リグレッションテストは、ソフトウェアに変更を加えたときに既存機能が壊れていないかを確認するためのテストです。
軽微なバグ修正や仕様変更でも、他の機能に影響が出ることはよくあります。
だからこそ、変更のたびに繰り返し確認が必要であり、しかも短時間で正確に行う必要があります。
私たちのチームでは、リリース直前にリグレッションテストを走らせるのが標準的なフローとなっています。
📦 パッケージングって何？
パッケージングとは、テストケースを意味のある単位で整理・分類し、まとまりとして管理することです。
たとえば：
といった形でまとめておけば、再利用しやすくなり、無駄な実行を避けつつ、必要十分なテストだけを素早く選択できるようになります。
🧩 パッケージングによって得られたこと
⚡ 実行の高速化と効率化
以前は、機能追加や修正のたびに、「なんとなく関係ありそうなテストを都度ピックアップして実行する」というような運用が続いていました。
こうなると判断が人に依存しがちで、漏れや重複も起こりやすいし、実行にムダも出てきます。そこで「この変更ならこのパッケージを実行」と、即座に判断できる仕組みに切り替えました。
テスト実行の時間や工数が削減されるのはもちろん、フル実行ではなく「見るべきところをちゃんと見る」視点へのシフトによって、本質的な不具合の検出にもつながるようになった感覚があります。
🔍 可視性とトラブルシュートの向上
パッケージごとにテストが整理されていると、見直しが必要な領域や改善ポイントが浮かび上がりやすくなります。
たとえば：
- 「このパッケージの確認に毎回時間がかかっている」
- 「ここの仕様理解にばらつきがあって、判断が揃わない」
といった“つまずきポイント”が見えてくるようになります。
また、パッケージ単位での実施率や進捗をチームで定期的に共有することで、共通認識を持って改善サイクルを回せるようになりました。結果的に、テストのやり方そのものも少しずつ良くなってきているな、と感じます。
🧪 自動テストはやらないの？
ここまで「必要なときに必要なテストだけを走らせる」ためのパッケージングの話をしてきましたが、
ここまで読むと、「じゃあ自動テストはどうしてるの？」と思われるかもしれません。
もちろん、やっています。
日常的に走らせるテストや、広範囲なチェックが必要なケースでは、基本的に自動化しています。
CIに組み込んでおき、特定のブランチやイベントに応じて自動で回るようにすることで、人の手を介さず品質チェックが回る状態を整えています。
さらに、パッケージングされたテスト自体もコード側と連携していて、変更のあったファイルに関連するパッケージだけを自動で選んで実行するといった、より最適化された運用にも取り組んでいます。
💡 導入におけるTipsと落とし穴
⚠️ 落とし穴：スプレッドシート運用の落とし穴は“最初の設計ミス”にある
パッケージ化したテストケースを運用していくにあたって、私たちが選んだのはGoogle スプレッドシートでした。複製のしやすさや関数による自動集計、条件付き書式など、視認性と管理性の両方が取りやすく、特に小〜中規模の手動テストを扱うにはちょうど良いツールです。
ただ、使い始めてすぐ「便利！」とはならず、序盤はいろいろな“詰まり”に遭遇しました。
たとえば、見た目優先でテンプレートを先に作ってしまった結果、あとから関数や集計ロジックを入れようとして構造が崩れてしまうというパターン。参照列のズレや書式崩れ、関数が一部だけ壊れるなど、地味に面倒なトラブルに何度も引っかかりました。
✅ Tips：スプレッドシートの設計は「構造→テンプレ→装飾」の順で
この経験から学んだのは、「テンプレを整えるより、先にロジックの設計を」という教訓です。
- 実施/未実施/要修正などの状態はどの列で管理するのか
- 集計はどこに表示し、どんな数式で処理するのか
- 複製しても壊れないシート構成はどうするか
このあたりを先に決めておけば、テンプレートを整えるときもブレがなく、あとからのメンテナンスコストを最小化できます。
特にチームで共有して使う場合、「誰が触っても壊れない」を意識しておくだけで、運用の安定感は段違いになります。
🏁 おわりに
今回紹介したリグレッションテストのパッケージングは、派手さはないけれど、チーム開発を支える大事な土台だと感じています。
運用の構造を見直すことで、「どのテストを・いつ・どうやるか」がクリアになり、品質担保の安心感と、テスト作業の効率の両立ができるようになりました。
まだまだ改善の余地はあります。たとえば：
- パッケージの実行をコード差分に応じて動的に切り替える
- テストの実施状況を可視化し、アラートまで連携する
- QA以外のメンバーとも共同編集できる仕組みに発展させる
といった構想は進行中です。
小さな工夫の積み重ねが、プロダクト全体の品質とチームの安心感につながる。
このブログが、同じような課題に向き合う方の参考になれば幸いです。
ここまで読んでいただき、ありがとうございました！
