はじめに
こんにちは、テックタッチで QA PM をしている shutty です。
この記事は 2024 年 9 月 26 日に開催した PayPay / Rakuten Group / Techtouch - QA Night #1 で発表した リグレッションテスト期間の短縮を目指して の続きです。当時進めていた取り組みが一段落したため、整理してみました。リグレッションテストのテストケース数に課題を感じている方にとって何かしらの解決のヒントになりますと幸いです。
現在テックタッチでは、「リリーストレイン」の考え方に基づいて、開発を進めています。個別開発案件の完了条件には「機能ごとの検証が終了しており、不具合の対応方針が決まっていること」が含まれており、これらを複数まとめてリグレッションテストを行っています。
私たちがここ最近向き合っていたのは、リグレッションテストにかかる時間の長さでした。
このリグレッションテストで必ず実施していたのが、優先度高に分類された約 3,000 件のテストケースです。しかし、すべてを毎回実行することは、コスト・期間ともに無視できない影響がありました。加えて、環境適応性や効率性に焦点を当てた追加検証も含まれていたため、コードフリーズから本番リリースまでに長時間かかっていました。
今回は、そのようなリグレッションテストにおけるスコープの見直しと、優先度高の棚卸しを通じてどのような変化を得たのかをご紹介します。
テストケース管理の課題とツール導入
当初、私たちはテストケースをスプレッドシートで管理していました。しかし、以下のような課題が積み上がっていました。
- 複数ファイル・シートをまたぐことで一覧性が乏しく、全体像がつかみにくい
- ケースの重複や類似の確認が困難で、再利用もされにくい
- テスト実行やメンテナンス時に誤編集が起こりやすい
こうした状況を改善するため、私たちは Qase というテストケース管理ツールを導入しました。導入背景や選定理由については、こちらの記事でもご紹介しています：
とくに当時「Qase はテストスイートで管理できる」ことに注目していましたが、実際に運用していく中で、階層構造（toggle 表示）による視認性の高さや全体感の把握のしやすさが想像以上に有効であると実感しています。
スイート単位での整理と優先度の見直し
Qase 上での管理体制が整ってきたことで、私たちは次にテストスイート単位での再整理に着手しました。
たとえば「テキストボックスへの入力」に関するスイートには、以下のような多数のケースが格納されていました。
- 入力文字数のバリエーション（1 文字 〜 255 文字など）
- 禁止文字・特殊文字の入力
- エラー時のハンドリングやメッセージ表示確認
これらのうち、いくつかのケースには「優先度高」が設定されていました。たしかに、顧客の利用頻度を考慮すると優先度高として妥当なものもあります。
しかし一方で、それらの多くはフロントエンドのユニットテスト (UT)、コンポーネントテスト（CT）ですでにカバーされている、または近接領域でテストが十分に行われているものも多く存在しました（テストの分類についてはテスト自動化の協業を加速する！ テックタッチのフロントエンドにおけるテストの分類をご参照ください）。
そこで以下のようなポリシーを設定し、優先度の再整理を進めました。
- 正常系・準正常系のパターンが網羅されていればリグレッションテストでは代表パターンの確認で十分
- UT や CT で既に担保できる内容は、E2E・手動リグレッションテストでは優先度を下げる（=リグレッションテストでは実行しない）
- テストスイート内のテストケース数および優先度高のテストケースの割合の目安の決定
マニュアルテストからUT/ITへ移行
整理の結果と見えてきた成果
この優先度の見直しプロジェクトは、約1年弱かけて段階的に進行しました。各スイート単位でのレビューと、UT・CT・IT などの他レイヤーでのテスト実施状況を開発者と協力して確認しながら進めていきました。
その結果、約 3,000 件あった優先度高のテストケースのうち、他レイヤーで担保できている／近接領域でカバーされていると判断した 1,200 件の優先度を変更しました。これにより約 5 人日分の工数の削減を達成しました。
おわりに：次への布石
今回ご紹介したのは、リグレッションテストにおけるテストケースの整理と優先度見直しによる効率化でした。
次に私たちが取り組むのは、この整理されたテスト資産を活用した E2E テスト自動化の推進 です。
具体的には
- 整理された優先度高のテストケースをベースに、既存機能の E2E テスト自動化
- 新機能開発時に対応する機能の E2E テストの自動化
を進めていきます。
