はじめに
こんにちは！QCDグループに所属している小熊です。
Safie Viewer for PCのQA（システムテスト）を2019年9月頃から担当しているのですが、悩みのタネであった「度重なるバージョンアップによって増え続けるリグレッションテスト項目」の解消を目指してトライしてみたことについて書こうと思います。
セーフィーにおけるQCDグループはどういう事をしているのか？を紹介している記事もございますので、是非こちらもご確認ください！
リグレッションテストについて
Safie Viewer for PCは月イチで新バージョンがリリースされており（過去はもっと頻繁に（2～3週間に1回程度）リリースされていた）、その度に新機能追加や不具合修正などが既存機能に悪い影響（意図していない影響）を与えていないことを確認する必要が有ります。
Safie Viewer for PCは歴史が古いこともあって機能数が多くて思わぬところに開発影響が出たりするため、範囲や対象を絞り込まずに全てのテスト項目の実施（フルリグレッションテスト）をリリース毎に行っています。
暗黒時代
リリース毎に新機能もしくは改修が入るので、リグレッションテスト項目内容もそれに合わせて更新し続ける必要があります。
具体的には新機能は一度リリースされたら既存機能に含まれるのでその内容をリグレッションテストに落とし込んでいるのですが、その度にテスト項目は増え、増え、増え、と増え続け、これまで一番ひどかった時期の項目数をピックアップしたら下記表な感じでした。
| リリース月 | 実施項目数 |
|---|---|
| 2022年7月 | 1083 |
| 2022年12月 | 1230 |
| 2023年3月 | 1584 |
| 2023年8月 | 2102 |
1年で実施項目数が約2倍！こりゃだめだ。。
この件について頭を悩ませていたポイントを下記にまとめてみました。
テストの実施に時間がかかる
- 項目ごとに優先度を割り振り、優先度低い項目は毎回は実施しないようにしていたがそれでも限界
- テスト項目の視認性が悪くてやりにくい
テスト項目のメンテナンスに時間がかかる
- 1と共通点が多い問題、メンテナンス後に項目レビューするのも大変
- テスト自動化対応しにくい
テスト自動化対応しにくい
- 自動化できる／できない（しない）の精査、自動化した後の管理が大変
- これとは別に新機能／改修向けのテストの準備や実施が有り、特にテスト期間中はテスト項目消化に追われていた（探索的テストなど、他のことに割く工数が無い）
これらによって改善活動（テスト項目の整理整頓）にリソース割くのが困難、改善しないので更に項目が増えていき、さらにリソースが逼迫するという悪循環に陥ってました。
「整理整頓」時代
暗黒時代の中、ただ手をこまねいていたわけでは無く、課題解決のためにはどのような方針で整理整頓する必要があるのかをQAメンバー全員で議論や準備を少しずつ進めていたところ、ある転機がやってきました。
engineers.safie.link
↑の記事にあるテスト管理ツールの導入イベントです。
これまでスプレッドシートでテスト項目を作成＆実施していたものを管理ツールで行うことが決定、せっかく管理ツールへの移行に工数割くなら準備してきた改善案を適用した内容でやってやろうじゃないかとなり、テスト実施にかかる以外の工数をほぼ全振りして整理整頓対応することとなりました。
その時の整理整頓の活動方針は
これまでのテスト項目を優先度付けして、優先度高い内容を移行する新項目のメイン機能（骨格）とする
1で決めたメイン機能チェックは、なるべくシンプルにまとめる（肉付け）
肉付けの際は「自動化できる（自動テストのみで完結できる内容）」「できない or 困難（メンテナンスに時間かかるなど）」のように自動化可否を分けて（混在しないように）行う
の3点です。
特に①と②の対応に苦心しました。
どの機能を骨にして（いわゆる優先度付け）どれだけ肉付けするかは、「これまでで実施してきた項目」から「どれだけインシデントが検知できてきたか」の分析を行ってその結果を指針にしたり（新しい項目によって実施工数は減ったけどリリース後に見つかるバグが増えた、は許されない）、①や②の対応後に「これまでのインシデントが検知できる内容になっているか」の見直しを行ったり、それをメンバー間でレビューしあったり（①②の実施は各メンバーの感覚によってバラつきが有るので）、とにかく試行錯誤の連続でした。
また、テスト項目での記載内容によってちょっとでも項目を減らすように工夫しました。たとえば「画面AでボタンAの確認」「モーダルBで機能Bの確認」とぶつ切りになっていた2つの項目を「画面AでボタンAを押下した後のモーダルBで機能Bの確認」のように一連の流れで網羅できるような1つの項目へ組み替えたりです。
その後（現在）
整理整頓を頑張り始めてから、その後項目数はどうなったでしょうか。
| リリース月 | 実施項目数 |
|---|---|
| 2023年8月 | 2102 |
| 2024年5月 | 641 |
| 2024年12月 | 665 |
ピークから3分の1以下まで減りました（拍手！）
ただし気を抜くとあっという間に以前に逆戻りしてしまう（実際、5月から少しずつ増えている）ので活動の継続は必要なのと、浮いた工数をどのように有効活用していくかも今後の課題のひとつです。
まとめ
今回の対応が最適解とせず、メンバー内で整理整頓（①～③）への共通認識ができている今の内に更なる改善目指し、これからも試行錯誤進めていこうと思っています。（そのことをまたお話できたら良いなぁ）
