2023.10.5

【第2回】：異常系テストの実施方法と課題

ソフトウェアの信頼性を保証するうえで、「異常系テスト」の実施が欠かせません。異常系テストとは、仕様外の状況・正常でない状況におけるソフトウェアの振る舞いを検証するテストです。

市場での不具合流出、ひいては情報漏洩や多大なコスト発生といった種々のリスクを防ぐうえで、異常系テストは非常に重要となります。現実のソフトウェア市場において、異常系テストの不足によって重大なリスクが顕在化した事例は後を絶ちません。詳しくは、第1回の記事をご一読ください。

【第1回】：異常系テストの基礎知識と重要性

ソフトウェアのこうしたリスクを確実に検出するうえで、異常系テストの正しい実施方法を把握することが肝要です。ただし、異常系テストの実施には課題も少なくありません。そこで第2回となる本記事では、異常系テストの実施方法と課題についてお伝えします。

異常系テストの実施方法

異常系テストの実施方法は開発・QA現場にもよりますが、次の5プロセスに沿って進めることが通例です。

テストベースの参照・理解
異常ケースの洗い出し
テストケースの作成
テストの実装・環境構築
テストの実行

各プロセスについて、順番に解説します。なお、第1回では「準正常系テスト」と「異常系テスト」が存在することをお伝えしました。本記事の「異常系テスト」は、これらを包括するものとして論じます。

1.テストベースの参照・理解

まずは「テストベース」を参照し、テスト対象システム（SUT）がどのようなものかを理解します。テストベースとは、仕様書や設計書といったテスト実施にあたっての基となる資料のことです。テストベースから機能や振る舞い、性能などの情報を理解し、テストケースへの布石とします。

前提として、異常系テストで実施すべき具体的なテストシナリオは、SUTの仕様や設計などにより変わってきます。そのためテストベースの理解は、実施する異常系テストの方向性を決めるうえで欠かせません。

2.異常ケースの洗い出し

テストベースの内容を踏まえて、異常ケースの洗い出しを行います。実際にユーザーがソフトウェアを使用することを想定し、どのような異常が発生し得るのかを明確にします。この段階で洗い出しが甘かった場合、異常系テストの漏れにつながるため重要なプロセスです。

たとえば「入力金額の税込価格を表示する」という機能がテスト対象となる場合を考えます。この場合、仕様の上下限値を超えた入力、数値以外の入力、記号やコードの混入、入力中のログアウトやブラウザ終了など、多岐にわたる異常ケースが考えられます。

3.テストケースの作成

洗い出した異常ケースに沿って、どのようにテストするかを考え、テストケースに落とし込みます。各テストケースには具体的なテスト手順、テストの前提条件、期待値などを記載。手動による異常系テストの場合、テスト仕様書やテスト項目書といった文書に記載することが通例です。

検証すべき入力値や操作手順を具体化し、漏れのないテストケースを作成することが求められます。たとえば「数値以外の入力」という異常ケースを検証する場合でも、具体的に何を入力するかはテストケース作成者の判断に委ねられます。そのため異常ケースを深掘りし、不具合の発生が疑われるパターンは漏れなくテストケースを作成することが重要です。

4.テストの実装・環境構築

テストの実装は、テストデータやテストアカウントといった実行に必要となる要素を準備するプロセスです。ハードウェアの接続や関連ソフトウェアの導入などの環境構築も含まれます。異常系テストを自動化する場合は、この段階でテストスクリプトを作成します。

特に手動で異常系テストを実施する場合は、テスト日程・工数の都合で全テストケースの消化が難しい場合があるため、優先順位付けも重要です。実行に必要な工数や不具合の発生確率、発生時の被害規模などを勘案し、各テストケースに優先度を設定します。

5.テストの実行

テストの準備を整えたうえで、実際にテストケースを実行するプロセスです。手動テストの場合は、SUTをテスト手順に沿って担当者が操作し、結果が期待値と一致するかを検証します。テスト結果の記録やエビデンスの確保、不具合の報告なども行います。

自動テストの場合は、テストスクリプトの実行によりテストケースの実施が可能です。テスト担当者はテストケースの選択や進捗管理、モニタリングなどを行います。「Eggplant」などのテスト自動化ツールを用いる場合は、テストケースの選択や不具合の報告なども自動化できます。

異常系テストケースを実施するうえでの課題

ソフトウェアテストにおいて異常系テストの重要性は高いものの、その実施にあたっては課題が少なくありません。異常系テストを実施するうえでの主な課題は、次の3つです。

課題1：漏れのない異常ケースの洗い出しが困難

「想定外を想定」しなければならない所が異常系テストの難しさです。異常系テストの漏れによる品質問題には、そもそも想定外を想定できていないケースが少なくありません。しかし現実には、多岐にわたる異常ケースをテスト担当者が漏れなく洗い出すことは困難です。多くのテスト経験を持つ熟練者であっても、人的ミスを100％防ぐことはできません。

異常ケースの洗い出し作業の品質は、テスト担当者の経験やスキルに強く依存します。異常ケースの種類は非常に多く、SUTの特性によっても不具合の発生しやすさが変わるためです。テスト経験が多くない場合、対象のSUTで検証すべき異常ケースを過去に経験していない場合が往々にしてあります。異常ケースの洗い出し漏れがテストの漏れに直結することは、言うまでもありません。

課題2：合否基準が曖昧になりやすい

テストベースに明確な答えが存在する正常系テストとは異なり、異常系テストの答えは基本的に明記されません。そのため、異常ケースが発生した際の合否基準が曖昧になりやすいと言えます。合否基準が誤っていた場合、テストケースを漏れなく実施できたとしても正確な不具合検出は不可能です。

たとえば、電源断のようにハードウェアを巻き込む異常ケースは、ソフトウェアでは手の打ちようがない場合が少なくありません。こうしたケースでは、データの消失などによるシステムへの影響範囲が大きくなり、テスト担当者の一存で「どうあればOKである」と決めることは困難です。開発者や顧客との調整が必要となれば、テスト担当者の業務的な負担も大きくなります。

課題3：異常ケースの実行ハードルが高い

異常ケースを実行するための難易度は、正常ケースと比べて高いといえます。タイミングのシビアな操作が求められるケースや、タイミングがあらゆるプロセスに遍在するケース、異常な環境を強引に作り出さなければならないケースが多いためです。工数や社内リソースの制約により、実行を見送らざるを得ないことも珍しくありません。

たとえば、「サーバーの処理能力を超えるリクエストを送る」というテストケースは、運用環境上での実行は現実的に不可能です。実行するためには、試験環境のセットアップや大量のテストデータ作成、データ送信用のクライアントプログラム実装など、多くの準備作業が必要となります。

また、サーバー障害などをともなうテストケースの場合、ハードウェアへのダメージも懸念されます。このように、異常系テストは担当者の負担や懸念事項が多く、実行のハードルが高いのです。