リグレッションテストとは？ テスト専門会社の秘訣を伝授
昨今のソフトウェアの開発現場では、仕様は複雑化し、連携する機器やシステムは増え、ソフトウェアの規模も膨れ上がっています。そんな開発現場において、変更を加えた部分”以外”の部分に不具合が発生していないか、いわゆるデグレの発生は、どんなプロジェクトでも例外無く大きな課題になっています。このデグレの確認において、重要な役割を果たすのがリグレッションテストです。このブログではリグレッションテストの意味や目的について、テスト専門会社の勘所も交えてご紹介させて頂きます。
リグレッションテストってなに？どういう意味なの？
ここで改めてリグレッションテストについてご説明を致します。職場によっては回帰テストとも呼ばれますが、回帰を英訳すると”Regression“になり同じテストになります。ここではInternational Software Testing Qualifications Board(以降ISTQB)の記載に則りリグレッションテストとしてご紹介をさせて頂きます。
リグレッションテストについてISTQBの用語集では下記の様な説明がされています。(https://glossary.istqb.org/jp/search)
「ソフトウェアの変更されていない領域で欠陥が混入している、もしくは露呈していることを検出するための、変更関連のテストの一種。」
日本語訳が少しおかしいですが、シンプルに言い換えますとリグレッションテストとは「変更されていない領域に欠陥が無いことを確認するためのテスト」という意味です。
（実際には欠陥が無いことは証明できませんが、分かりやすく表現するための言い換えです。）
続いてリグレッションテストで陥りやすい状況について次の章でご紹介いたします。
リグレッションテストで陥りやすい状況
開発プロセスの中で非常に重要な位置づけをもつリグレッションテストですが、陥りやすい状況もありますので代表的なものを2つほどご紹介していきます。
【リグレッションテストで陥りやすい２つの状況】
- 繰り返される無駄なテスト
自動化ができていれば多少無駄があっても良いのでは？なんて声も聞こえてきそうですが、自動化は何度でも自動で繰り返してくれますが、メンテナンスも必要です。特に自動化におけるメンテナンスはテストケースと自動化スクリプトの両方のメンテナンスが必要となり、思った以上の工数を要することが多々あります。
テストケースを作成の際は、できるだけ少ないテストケースで必要な画面や機能・分岐条件・パラメータ等を網羅し、同じ内容なのに同様のパラメータだけが異なるといったテストケースにならないようしっかりと作りこむことが必要になります。
また、実行する範囲についても重要であり、毎回手元にある全てのリグレッションテスト用のテストケースを実行するのでなく、変更を加えられた範囲よりリソースに応じて優先度をつけて行うことが重要です。
- バラバラなテスト内容
こちらの内容は主にリリース後の追加開発等の現場におけるリグレッションテストが対象になります。「リグレッションテスト用のテストケースを作ろう！」と社内で号令が掛かりました。みなさんの現場では、同じ粒度・同じ方向性で作業に取り掛かることは可能でしょうか。リグレッションテストは他のテストタイプと比較しても、その定義からテスト内容に統一性を持たせることが難しく、人によって内容が異なりがちです。
Ａさんが作成したテストケースとＢさんが作成したテストケースでは、内容や記載方法、一つのシナリオでカバーする範囲まで全く異なると、テストケースの管理にも非常に苦労することになり、テストケースのメンテナンスも同様に大変です。
作成ないし他のテストタイプから流用してカスタマイズする際は、フォーマット等を標準化することはもちろん必要です。そしてテストケースの対応する画面や機能・業務シナリオを可視化することで、管理やメンテナンスし易いテストケースを作成できます。
以上が陥りやすいミスについてご紹介しました。
このあとは、リグレッションテストの勘所についてご紹介します。
リグレッションテストの勘所と目的の大切さ
この章ではリグレッションテストの勘所について、テストケース作成時、テスト実行時の2つに分けてご紹介いたします。
- テストケース作成時
まずは最も大事なポイントはリグレッションテストに限らず、テストの目的を明確にすることです。そのテストケースでは何を確認したいのか？そのテストケースではどの範囲・観点をカバーするのか？このような目的を明確に定義し、全体像を設計したうえで作成することで、効果の高いテストケースを作成できます。
また、前の章でも記載しましたが、フォーマット・テストケースの粒度・書き方等を標準化しておくと、作成時だけでなく管理・メンテナンス時においもて容易性が高まります。
続いては、リグレッションテストとは切っても切り離せない自動化についてですが、やはりメンテナンスし易いことが非常に重要です。シナリオテストの形態で自動化をする場合は、一つ前の章でも記載しましたがテストケースと自動化スクリプトの双方をメンテナンスする必要があり、テストの目的や対応する範囲を定義したうえで作成することが重要です。
また、自動化関連でもう一つ重要なことは自動化できる部分とできない部分、できるけどしない部分の切り分けです。できる部分と出来ない部分の切り分けは、ツールごとに得意・不得意があり特性に応じて切り分けることができると思います。問題なのは自動化できるがスクリプト作成に時間を要し、費用対効果を出せるか不明な場合や、こまめなメンテナンスが必要となることが事前に分かっている場合です。エンジニアとしてはできるならやりたいと思いがちですが、どの程度の頻度で実行するのかといった視点も含めて考える必要があります。
- テスト実行時
よくリグレッションテストの説明に、「過去のデータより影響範囲を・・・」といった説明を見受けます。さて、過去のデータとは何でしょう？すぐに思いつくのは不具合データですね。不具合分析することで、次のリリースでの影響範囲の分析の一助にもなります。
それ以外にも一つお勧めしたいのは、テスト結果がOKだったという記録です。
テストスイート等のテストケースのかたまりごとに不具合率等を記録し、そのテストケース群の結果を記録することで、そのテストケース群のカバーする範囲の信頼性を数値化できます。その数値により、限られたリソースの中でどの範囲を行うのかといったテストマネージャの永遠の課題に対する、一つのヒントになります。
まとめ
ここまでリグレッションテストについてご説明をさせて頂きました。リグレッションテストは繰り返し行うことが前提のテストの為、自動化や管理やメンテナンスの容易性がとても重要になります。ご紹介した内容はリグレッションテストに限らず、他のテストでも言える内容が殆どですが、他のテストと同じ様に基本が大事だと捉えて頂けますと幸いです。
また、バルテス（株）ではこのブログでも何度も登場したテスト自動化について、「日本語でスクリプトを作成」できるT-DASHというツールを販売しています。このツールはテストスクリプトを日本語・英語の自然言語で作成できる為、リグレッションテストの説明でも何度も自動化の課題として登場した、メンテナンスの容易性を大幅に高めています。
ご興味ございましたらページ下部もしくはナビゲーションにありますトライアル申し込みのリンクより無料トライアルをご利用頂けますので是非お試しください。
そして、誰でもカンタンにテスト自動化ができる時代は、すぐそこまできています。当サイトでは、テスト自動化ツールに興味のある方へ、「テスト自動化 推進ガイドブック」と「テスト自動化ツールT-DASH 基本ガイドブック」のダウンロード資料をご用意しております。ぜひダウンロードいただき、資料をご覧ください。
.png)