本記事はソフトウェアテストの小ネタアドベントカレンダー18日目の記事です。
リグレッションテストと言えば自動化ですが、様々な事情で手動のリグレッショテストが必要になる場合があります。 そこで、本記事では、修正内容に応じたリグレッションテストの実施範囲を決める際に私が行なっている方法を紹介します。
目次
- 修正したコードの依存関係から決める
- 変更があったDBのテーブルの依存関係から決める
- 変更があった外部仕様の依存関係から決める
- 性能面への影響を考慮して決める
- リリース・ロールバックの各手順から決める
- 過去の不具合や経験や直感に基づいて決める
- 上記分析にミスがある場合に備えた念のためのテスト
- 参考文献
修正したコードの依存関係から決める
修正したコードと他の関数との依存関係を分析してテストの実施範囲を決めます。 DBやログに保存する内容の変更が生じる場合は、当該レコードやログを参照する関数やバッチなどもテストが必要な場合もあります。 依存関係の調査方法は、設計書の確認やソースコードのGrepによる目視確認、ソースコード解析ツール*1の利用などがあります。
また、マイクロサービスアーキテクチャの場合は、修正が影響するAPIと他サービスとの連携もテストが必要な場合があります。 テストすべき他サービスの調査方法は、ドキュメントの確認、APIのリクエスト元を記録したログの分析などがあります。
ただし、修正したコードやデータなどの依存関係があるからといって闇雲に全てをテストするわけではありません。 テスト設計時に最低限のテストケースを選ぶための工夫（テストケース削減の工夫） - かわちーばーのブログの「プロダクトリスクの大きさや予測される障害を分析してテスト量のメリハリをつける」や「テストはなるべく小さい部品単位で行う」で紹介した通り、修正内容に応じてリグレッションテストを実施する範囲を狭めます。
参考文献： 統合テストにおいて影響範囲に対するテスト漏れを防止する「影響波及パス分析法」の提案
変更があったDBのテーブルの依存関係から決める
あるテーブルのカラムの追加やカラムの型変更などを行なった場合、当該テーブルを参照するAPIのテストや当該APIと他サービスとの連携のテストを行います。 また変更前のテーブルのデータが変更後の利用できることのテストも必要になります。
依存関係の調査方法は、CRUD図の確認などがあります。
カラム追加の場合は当該テーブルを参照するAPIが全く動かないという障害が多いので、ハッピーパスのテストのみ（正常系１パターンのみ）行うことが多いです。
参考文献：システム変更を安全かつスピーディに進めるための極意とは？～CRUD表で今すぐできるコスト削減 (1/5)：EnterpriseZine（エンタープライズジン）
変更があった外部仕様の依存関係から決める
ブラックボックス視点での依存関係からリグレッションテストの実施範囲を決めます。
依存関係の調査方法は以下のようなものがあります。
- 機能と機能を利用するページ(機能を説明するヘルプページなどの静的コンテンツも含む)のマトリックス表を確認
- 業務フロー図や状態遷移図を確認
テスト内容は以下のようなものが考えられます。ただし、修正が他機能に影響なさそうであればテストを省略します。
- 変更があった機能を各ページでテスト
- 変更があった機能と同じページ内にある他機能のテスト
- 変更があった機能を利用する業務フローのテスト
性能面への影響を考慮して決める
コードの修正を行った場合、修正したAPIの性能が悪化する場合だけでなく、サービス全体としてリクエスト数が増加して性能が悪化する場合があります。 例えば、サーバーの応答時間の悪化、メモリ不足、コネクションプールの枯渇といったことが考えられます。
修正内容からこれらの影響を考慮し、必要に応じてテストや本番環境の状況の調査などを行います。
リリース・ロールバックの各手順から決める
ゼロダウンタイムデプロイを行う場合、かつ、アプリケーションのデプロイやDBのマイグレーションを複数伴う場合は、リリース・ロールバックの作業途中でもサービスが正常に動作する必要があります。
また、Webアプリケーションの場合は、ユーザーがブラウザで旧バージョンの画面を表示した後、裏で新バージョンがデプロイされ、ユーザーがそのまま旧バージョンの画面で操作をすることがあります。
そのため、上記を踏まえたテストが必要になります。
以下は、ECサイトで購入履歴テーブルのカラム追加、アプリケーションのデプロイの順番でリリースする場合のテスト内容の例です。
購入履歴テーブルのカラム追加
アプリケーションのデプロイ後の動作確認
- ECサイトの注文確認画面を開く
- アプリケーションのデプロイを実施
- アプリケーションのデプロイ前に開いた注文確認画面から注文を完了させ、注文が正常に完了すること、購入履歴が正しく表示されることを確認
- （通常の機能テストで確認する）アプリケーションのデプロイ後にカートに商品追加〜注文完了まで実施し、注文が正常に完了すること、購入履歴が正しく表示されることを確認
過去の不具合や経験や直感に基づいて決める
上述の方法は修正内容からトップダウンでテストの実施範囲を決めていました。しかし、何らかの事情でトップダウンからの分析で導くことが難しいテストが存在する場合があります。そのような分析の難しさを補完するため、過去の類似事例や直感からテスト実施範囲を推測します。
例えば、過去に購入履歴テーブルを修正したらなぜかメルマガが配信できなくなったのでメルマガのテストを実施しよう（実は購入履歴に応じてメルマガの配信頻度をカスタマイズしている）、など
上記分析にミスがある場合に備えた念のためのテスト
自動テスト（E2Eテスト）のテスト内容の選び方 - かわちーばーのブログの「テスト漏れをカバーする保険」で紹介した通り、分析ミスがあった場合に備えて重要な機能のリグレッションテスト実施を検討します。
上記分析に自信がある場合は省略します。 例えば、修正内容が文言だけ、修正した関数が最近追加されたもので特定の用途でしか使われないことが明確、など。
参考文献
統合テストにおいて影響範囲に対するテスト漏れを防止する「影響波及パス分析法」の提案
システム変更を安全かつスピーディに進めるための極意とは？～CRUD表で今すぐできるコスト削減 (1/5)：EnterpriseZine（エンタープライズジン）
