はじめに
e-dashでQAエンジニアをしているuedaです。
この記事では、これまで粒度の粗いユースケース一覧を元に行っていたリグレッションテストを、より具体的で誰でも再現可能な「テストケース」という資産に進化させ、さらにその資産が陳腐化しないためのメンテナンスプロセスを構築した話をします。
品質保証の土台を着実に固めていった、プロセス改善の記録です。
問題点1：リグレッションテストの属人化
プロセス改善に着手する以前、私たちのリグレッションテストは「ユースケース一覧」という指針を元に実施していました。
しかし、テストケースが整備されていなかったため、担当者がユースケースからテスト内容を都度解釈して実施しており、テストの進め方が担当者の経験則に依存し、属人化しているという課題がありました。
この属人化により、チームは主に2つのリスクを抱えていました。
リグレッションテストの属人化によるリスク
-
担当者の負荷集中とそれに伴う機会損失のリスク
テストの準備と実施に特定の担当者の時間が拘束され、その担当者のリソースが固定されてしまうことで、新たな品質改善活動に取り組む機会を失う可能性があります。 -
品質低下のリスク
担当者が不在の場合、既存機能への影響確認が不十分なままリリースに至る可能性がありました。これは、ユーザー環境での不具合（デグレード）発生に直結し、サービスの信頼を損ねる原因となります。
改善策1：リグレッションテストケースの作成
この属人化の問題を解決するために、曖昧なユースケースから、手順や期待結果が明確なテストケースへと落とし込みを行いました。
これにより、テスト作業が標準化され、担当者以外でも実施できるようになりました。その結果、担当者への負荷が分散されると共に、テスト品質低下などの、属人化に起因するリスクを解消することができました。
問題点2：テスト資産の陳腐化
こうして最初の問題は解決されましたが、別の問題が発生しました。
それがテスト資産の陳腐化です。
プロダクトは常に仕様変更や機能追加があるため、作ったテストケースをずっと使い続けてしまうと実態に合わないテストを行うことになり、結果として価値のない資産になってしまいます。
改善策2：テスト設計とテストケースの連携プロセス
この「テスト資産の陳腐化」という課題を解決するために、私たちは以下のプロセスを構築しました。
テスト設計プロセス
このプロセスでは、開発タスクをLinear、TestDesign(Sprint内の個別タスクに対するテスト設計書)をGitHub、テストケースをQase、TestSpec(プロダクトに対するテスト仕様書)をNotionを連携させています。
Sprint開発におけるプロセスの流れは以下の通りです。
- まず、
Linearで管理されている開発タスクを元に、GitHub上のMarkdownファイルとしてTestDesignを作成し、テスト設計を行います。このTestDesignはGitHub上でレビューを受けます。 - 確定した
TestDesignを基に、具体的なテストケースをCSV化し、QaseにSprintテストケースとして登録します。 - Sprint完了後、
TestDesignの内容とTestSpecとの差分を確認し、TestSpecに反映します。 - そして、更新された
TestSpecの内容をCSV化し、Qaseのリグレッションテストケースに差分として反映・マージします。
このプロセスの重要な点は、GitHub上で管理しているTestDesignを起点とし、NotionのTestSpecを経由して、Qaseのリグレッションテストケースを常に最新の仕様に追従させる仕組みを確立したことです。これにより、テストケースの陳腐化を防ぎ、品質保証の精度を維持しています。
【補足】各テストドキュメントの概要紹介
ここで登場するTestDesign、TestSpec、Qaseのリグレッションテストケースの各ドキュメントが、どのような構造で連携しているのか、補足としてご紹介します。
【TestDesign】
スプリント内の個別の開発タスクに対応するテスト設計書です。QAエンジニアが作成し、開発者がレビューを行います。
-
内容:
Input（テスト設計にあたり参照した情報）、改善内容（今回対象となる変更点）、やること（今回のテスト対象のシステム仕様や、具体的な確認項目やテスト観点、因子水準、テストパターン）が記述されます。
【TestSpec】
プロダクトの機能全体を網羅した、マスターとなるテスト仕様書です。
-
内容:
システム仕様として、システムの概要や、権限による違い、バリデーション、システムの振る舞いなどいった項目が記載され、その下にテスト仕様としてTestDesignと同様に具体的な確認項目やテストパターンが記載されていきます。
【リグレッションテストケース】
TestSpecのテストパターンの内容を元にQase上に登録された、実際に実行するテストケース群です。
-
内容:
項目名、Given（前提条件）、When（操作）、Then（期待結果）といったテストケースの基本要素に加え、トレーサビリティID、機能重要度、パターン重要度、実施優先度などが設定され、効率的なテスト実行に活用されます。
各ドキュメントのイメージ図
【補足】 テストドキュメント管理の継続的な改善
このプロセスで利用するツールも、常に最適な形を模索しています。
実は、以前TestDesignもNotionで管理していましたが、最近GitHubでの管理に移行しました。
主な理由としては、ソースコードと同様にプルリクエストベースでレビューを行えるためです。
現在はまだTestSpecがNotionに残っている状況ですが、将来的にはこれもGitHubへ移行し、テスト関連のドキュメント資産をすべてGitHub上で管理できる体制を整えていく予定です。プロセスは一度作って終わりではなく、今後も継続的に改善していきます。
問題点3：テスト実施コストの増大
テスト設計とテストケースの連携プロセスが回ることでテストケースは陳腐化することなく、着実に拡充していく基盤が整いました。
しかし、それは同時に、リグレッションテストにかかる実行コスト（時間）が増大していくという新たな問題を生むことにもなります。
改善策3：効率的なテスト実施のための優先度設定
この「テスト実行コストの増大」という問題に対応するため、私たちは効率性と網羅性のバランスを取ることを目指し、各テストケースに「松竹梅」の3段階の実施優先度を設定しました。
この優先度は、対象機能の重要度とテストパターンの重要度を加味して決定しています。
まとめ：改善の歩みと今後の課題
ここまでのプロセス改善の歩みを、問題と対策、そして現在の状況としてまとめると以下のようになります。
| 問題 | 対策 | 現在の状況 |
|---|---|---|
| テストケースの属人化 | テストケースの具体化 | ✅ 解決済み |
| テスト資産の「陳腐化」 | テスト設計とテストケースの連携プロセス | ✅ プロセス運用中 |
| テスト実行コストの増大 | 実施優先度の設定 | ⚠️ 対策実施済み（改善中） |
もちろん、このプロセスはまだ完成形ではありません。表で「改善中」とした通り、優先度を導入したものの、その運用にはまだ課題が残っています。
この優先度を導入してまだ日が浅いため、現状はまずプロセスを定着させることを目的に、最低限の品質を担保する「梅」コースを実施しています。今後は、どのような場合に「竹」や「松」を実施するべきか、その客観的な実施基準を設けることが次の課題です。
また、設定した優先度が本当に妥当であるかの評価も必要です。今後は、プロダクトの不具合発生状況や、利用状況データなどを参考にしながら、妥当性も定期的に見直していきたいと考えています。
おわりに
この記事では、私たちのチームが行ったプロセス改善の取り組みをご紹介しました。
私たちの取り組みが、同じようにリグレッションテストの運用に課題を感じている方々の、何かしらのヒントになれば幸いです。
Discussion