回帰テストの業務改善イメージ
業務改善

【図解多数】回帰（リグレッション）テストのテストケースを改善してみた。

2022年1月3日

目次Category


新年あけましておめでとうございます。本年もよろしくお願い致します。

私は年末から大掃除しています。
1年の蓄積というものはすごいですね。台所の換気扇、恐ろしいほど汚いですよ。要チェックです。

さて、自宅の大掃除も大切ですが、業務の大掃除も同じくらい大切です。
 
不要なものは処分したり、無駄な作業は省いて効率化する。
いい替えると『時間の大掃除』とも呼べますね。
 
そんな『時間の大掃除』を行ったので、情報共有したいと思います。
長文になりますが、ぜひ最後までお付き合いくださいませ。
 
※当記事は、社内ライトニングトークの資料をもとに作成しております。
 

回帰テストとは

今回、「回帰テスト」の業務改善を行いました。
現場によっては「リグレッションテスト」とも呼びます。
 
回帰テストについての図解
 
既存システムに追加機能を実装したとき、元々あった機能が使えなくなってしまうことを「デグレード」と呼びます。
このデグレードが起きないように、改修箇所の影響範囲をテストを実施し確認します。
 
以降、リグレッションテストと呼びます。

案件のざっくり工程説明

私の案件では、スマホアプリを開発しています。
アプリを公開するまで、以下のような流れで進行します。
 

●要望を受ける
　　お客様から追加したい機能などを伺う
●要件をすり合わせる
　　機能の細かい仕様を検討などを行う
●設計→製造→単体テスト→結合テスト
　　一般的なウォーターフォールモデルを採用
●リグレッションテスト
　　デグレードしていないことを確認
●受け入れテスト
　　お客様の方で、動作確認いただく
●リリース
　　ストアにアプリを公開

この中でも、リグレッションテストに大きな課題を抱えていました。
 

リグレッションテストが抱える２つの課題

以下の2つがあります。
 
●総ケース数が 3,000件ほどある
●ツギハギだらけの「ゾンビテストケース」
 
以下で詳しく見ていきましょう。
 

総ケース数が 3,000件ほどある

回帰テストの課題1つ目
 
アプリ開発において、テストで以下の点を考慮しなければなりません。
 
●OS
●端末
●画面サイズ
 
上記の違いによって、思いもよらぬ不具合が起こるおそれがあります。
そのような不具合を１件でも見つけるため、多くのバリエーションでテストを行うことが求められます。
 
私の案件では、OSと端末バリエーションで合計６パターン実施しています。できるだけ画面サイズが異なるように端末を複数選択しています。
 
●OS
　　iOS
　　Android
●端末
　　iOS 3端末
　　Android 3端末
 
テストケースが500件ほどあるので、500×2×3=3000という結果になります。
ケース数が多すぎて、やる気が失せます。精神的な負荷がすごいです。
 

ツギハギだらけの「ゾンビテストケース」

回帰テストの課題2つ目
 
実はこのリグレッションテストケース、私が入りたての頃に仕様の把握をするということで作成しました。
 
その後も追加対応で修正が繰り返し行われ、、、
 
●重複ケース
●仕様変更で使われなくなったケース
 
などが点在するようになりました。
 
その結果、使わないケースがあったり「あれ？さっき似たようなケース実施したな。飛ばそ」という場面が増え始めていました。
 

ん〜〜……めんどくさっ！！

これらが関係し、結果的に3,000ケースにも膨れ上がっていたのです。
このような状況で１年以上、メンバーがストレスを抱えながら業務を行っていました。
 
ついに私もイライラが最骨頂に達します。
 
東国原さんばりの「どげんかせんといかん！」と一念発起。
 
2021年の5月ごろ、私が抱える仕事を早めに終わらせ２人日の空き工数で総見直しを行いました。
 

課題の整理をしてみた

このまま突っ走っても空回りすることは分かっています。
 
目的と、課題を細分化して明確にしていくことから始めました。
 
●目的
「テスト工数と、精神的な負荷を減らすため、リグレッションテストを改善したい」
「テスト工数」と「精神的な負荷」に課題を分け、「なぜ課題感があるのか？」を考えてみました。
 
●テスト工数
　なぜテスト工数がかかるのか？
　　→テストケースが多すぎる
　　→ログイン前後のテストケースが混在している。
 
テスト工数に関する課題
 
●精神的負荷
　なぜ精神的な負荷がかかるのか？
　　→粒度が細か過ぎて億劫になる
 
精神的負荷に関する課題
 

対策を考える

良い方法がないか調べていたところ、とあるフレームワークを見つけました。
 
その名も「ECRS（イクルス）」というものです。
 
これは、経営者などが業務で無駄なものを精査する際に使われるフレームワークです。
 
フレームワークECRSの図解
 
●Eliminate
　　捨てる：不要なテストケースを削除する
●Combine
　　まとめる：まとめられるテストは一緒にする
●Rearrange
　　再配置：テストの順番を工夫する
●Simplify
　　テストを自動化などで簡単にする
 
いずれも、自宅の掃除にも役立てられそうですね。
 
ここまでスッキリ抽象化されていると、清々しいです。
 
これらのフレームワークに今回の課題を当てはめていきます。
 
フレームワークECRSに課題を当てはめる
 
最後の「Simplify（自動化）」は、期間が２日しかないので見送りました。
対策を固め、チーム内でディスカッションを行い、改善を進めます。
 

実際のテストケース

回帰テストの実際のケース
ログイン前後でシートを分け、AndroidとiOSでファイルを分けました。
「影響対象」という列には「●」や「▲」などを記載し、今回の対応の影響がある画面や機能に印をつけ、「テスト観点」という列に具体的なデグレードしてないか確認事項を記載します。
 
※PLの公開許可もらっています。
 

改善後の効果

●テストケース数
改善前改善後効果
565119約1/4
●実施工数
改善前改善後効果
２人日１人日約1/2
大きな効果が得られました！
 
ログイン前後、OSごとにシートを分けたことで、メンバ同士で役割分担しやすくなったことが要因として大きいと考えています。
 

メンバーの反応

現在５名のメンバーがいますが、旧リグレッションテストを使われたことのある２人に反応を伺いました。
 

リーダー

これまでのリグレッションテストに比べ、実施しやすいと感じた。
ログイン前後でシートを分けたことで、ログインし直す手間や後回しにするという考える手間も減り、テストしやすかった。
 

サブリーダー

これまでより実施しやすく、時間も短縮された。
改善前に挙げていた課題も解消され、実施しやすいと感じる。
 

今後に向けて

ソースコードのリファクタリング等ももちろんですが、テスト工程の見直しも重要だと身をもって感じました。
 
また、世間一般的ではリグレッションテストは自動化されていることが多いと見受けられました。
 
今後は、リグレッションテストで短縮された工数を利用して、見送ったテストの自動化やドキュメントの整備を推し進めて行きたいと思います！
 

さいごに

弊社では、お客様のご要望に合ったシステム開発を行いつつ、内部の業務改善にも努めております。

お客様の要望に応えるだけでなく、自分たちも仕事がしやすい環境づくりにも力を入れています。

弊社に興味がございましたら、お気軽にご連絡ください！

☞弊社に関する情報はコチラ

☞代表田中のTwitterはコチラ

☞採用担当のTwitterはコチラ

この記事を書いた人

松永裕太郎

松永裕太郎

●2018年 新卒入社
●スマホアプリ /サーバサイド開発 /新卒研修講師
●最近はアジャイル開発について勉強中