公開：
テストタイプとは？種類ごとの特徴や使い分けのポイントを解説
テストを実施しているにもかかわらず、リリース後に予期しない不具合が発覚する。こうした問題に直面した場合「どのようなテストを、どのタイミングで実施すべきか」という判断が適切にできていない可能性があります。
検証の目的や対象に応じてさまざまな手法が存在するソフトウェアテスト。それぞれのテストタイプについて特性を理解し、プロジェクトの要件に応じて適切に使い分けることで、品質保証につながります。
本記事では、テストタイプの定義や主な種類、効果的な使い分け方について解説します。
目次
テストタイプとは
ソフトウェアテストを計画する際「何を重点的に検証すべきか」を明確にすることは品質保証の基盤になります。
ここでは、テストタイプの定義や、混同されやすい「テストレベル」との違いについて整理します。
定義
テストタイプとは「何を・どのようにテストするか」を基準としたテストの分類方法です。
検証の目的や対象となる品質特性に応じて、適切なテストタイプを選択することで、テスト全体の効率化と十分な品質確保につながります。
テストタイプとテストレベルの違い
テストタイプと混同されやすい概念に「テストレベル」があります。両者の違いは以下の通りです。
テストタイプ
「何を・どのようにテストするか」という検証の目的や対象に基づく分類
例）機能テスト、非機能テスト、ブラックボックステスト
テストレベル
「いつ・どの段階でテストを実施するか」という開発工程内での位置づけに基づく分類
例）単体テスト、結合テスト、システムテスト
テストタイプとテストレベルは交差する概念であり、例えば「結合テスト」（テストレベル）の段階で「機能テスト」（テストタイプ）を実施する、といったかたちでテストを計画・実施していきます。
テストタイプの分類：要件別
テストタイプにはいくつかの分類方法があります。まずは、検証する要件ごとに分けた2つのテストタイプを解説します。
機能テスト
機能テストは、ソフトウェアが仕様通りに動作するかを検証するテストです。具体的には、ユーザーが実行する操作に対して、期待される結果が正しく返されるかを確認します。
例えば、ECサイトの開発であれば、以下のような項目が機能テストの対象となります。
- 商品をカートに追加できるか
- 在庫数が正しく更新されるか
- 決済処理が正常に完了するか
- 注文確認メールが送信されるか
機能テストでは、「正常系」（開発者が意図した通りの操作）だけでなく、「異常系」（想定外の入力やエラーケース）も含めて検証することが重要です。例えば、在庫がない商品を購入しようとした場合に適切なエラーメッセージが表示されるか、といった観点も確認対象に含まれます。
適切な機能テストを実施することで、プロダクトを商品として成り立たせる最低限の機能を保証できます。
参考：機能テストとは？種類や実施手順、非機能テストとの違いを解説
非機能テスト
非機能テストとは、ソフトウェアにおける「機能以外の品質特性」を検証するテストの総称です。
検証する品質特性に応じて、以下のような種類があります。
性能テスト
システムの応答時間や処理速度が要件を満たしているかを検証
負荷テスト
想定される同時アクセス数やトランザクション量（単位時間あたりの処理件数）のもとで、システムが安定して動作するかを検証
ストレステスト
システムの限界を超える負荷をかけ、障害が発生する条件や障害発生時の挙動を検証
セキュリティテスト
不正アクセスや情報漏洩、権限の不正利用などに対するシステムの脆弱性を検証
ユーザビリティテスト
対象ユーザーに近い人物にシステムを操作してもらってその様子を観察し、「使いやすさ」や「わかりやすさ」を検証
ボリュームテスト
大容量のデータを扱う際にシステムが正常に処理できるかを検証
障害許容性テスト
システム障害の発生時に、適切な検知や復旧が実行されるかを検証
耐久テスト
システムを長時間連続稼働させた際に、メモリリークやリソース枯渇などの問題が発生しないかを検証
互換性テスト
異なるOS、ブラウザ、ハードウェア、ネットワーク環境など、多様な利用環境下で期待通りに動作するかを検証するテスト
移植性テスト
システムを別の環境へ移したときに期待通りに動作するかを検証するテスト
機能テストに加えて非機能テストを十分に実施することにより、単に“動く”だけではない、“安心して快適に使える”プロダクトの実現につながります。
参考：非機能テストとは？主な種類や実施手順、機能テストとの違いを解説
テストタイプの分類：アプローチ手法別
テストタイプには「どのように検証するか」というアプローチ別の分類も存在します。
ここでは「ブラックボックステスト」と「ホワイトボックステスト」という2つの分類について解説します。
ブラックボックステスト
ブラックボックステストとは、プログラムの内部構造は確認せず、入力に対して仕様通りの出力が行われるかを検証するテストです。ソースコードの実装方法を問わず「ユーザーから見た振る舞い」に焦点を当てて検証します。
ブラックボックステストには、以下のような手法があります。
境界値分析
仕様や実装でミスの起こりやすい境界値を入力した際の挙動を重点的にテストする技法
同値分割（同値分析）
出力が同じになるような入力をそれぞれグループ（同値クラス）にまとめ、各クラスの代表値を選んでテストを行う技法
デシジョンテーブルテスト
条件と結果の組み合わせを表形式で整理し、必要なテストケースを洗い出す技法
状態遷移テスト
システムの状態間の遷移に着目してテストケースを設計する技法
ブラックボックステストには「プログラミングの知識がなくとも実施できる」「ユーザー視点での動作確認や実際の利用シーンに近いテストができる」といった利点があります。
一方で、内部ロジックの不具合や効率性の問題を見逃すリスクがあるため、より精度の高い品質保証に向けては次に紹介するホワイトボックステストと組み合わせることが重要です。
ホワイトボックステスト
ホワイトボックステストとは、ソースコードの内部構造や制御フローに基づいてテストケースを設計する技法で、プログラムの処理経路やデータの流れに着目し、実装の論理的な正確性を検証するために実行されます。
ホワイトボックステストには、以下のような手法があります。
ステートメントテスト
すべての実行可能な文（ステートメント）が少なくとも1回は実行されるようにテストケースを設計する技法
ブランチテスト
プログラム内のすべての条件分岐において、真・偽両方のパスを少なくとも1回は実行するようにテストケースを設計する技法
ホワイトボックステストを実施することで、ブラックボックステストではわからないコードの保守性の問題や潜在的なリスクを検出できます。また、カバレッジ指標（対象のプログラムのうちどれくらいテストされているかを評価する指標）により、網羅性を定量的に評価しやすいのも大きな利点です。
一方で、ブラックボックステストと違い「そもそも仕様書の内容が不適切である」「ユーザー目線で使いづらい」といった問題を見つけられない点には注意が必要です。また、大規模システムの開発ではテストケースが膨大になるため、リスクベースでの優先順位付けや自動化による工数削減が求められます。
※ブラックボックステスト・ホワイトボックステストの各技法についての詳細な解説は、以下の記事をご覧ください。
参考：主要ソフトウェアテスト技法を一覧で解説│目的や特徴、使い分け
テストタイプを効果的に使い分けるためのポイント
以上のようにテストタイプにはさまざまな種類があり、プロダクトの性質やリソース状況などによって使い分ける必要があります。
最後に、テストタイプを効果的に使い分けるための3つのポイントを解説します。
プロジェクトの特性とリスクに基づいて優先順位を決める
テストタイプの選択肢は、プロジェクトの特性や潜在するリスクに応じて判断する必要があります。
品質リスクが高い領域を優先的にテストすることで、限られたリソースを最も効果的に配分できます。リスク分析の際には、以下のような観点を考慮するとよいでしょう。
- 不具合が発生した場合のビジネスへの影響度
- 機能の使用頻度やユーザー数
- 技術的な複雑さや変更の頻度
- 過去のプロジェクトでの不具合発生傾向
例えば、金融システムの開発では、外部からの攻撃や障害発生が致命的なトラブルにつながるため、セキュリティテストや障害許容性テストの優先度が高くなります。一方で、消費者向けのモバイルアプリでは「日常使用時の快適さ」が重視されるため、ユーザビリティテストや性能テストにもリソースを割く必要があります。
開発者やビジネスサイド、（受託開発の場合は）クライアントなどとコミュニケーションをとり、品質要件の優先度に応じてテスト計画を組んでいくことが求められます。
早期テストで重要なテストタイプを優先的に実施する
開発の後工程で発見された不具合は、修正コストが大きくなるだけでなく、プロジェクト全体のスケジュールに影響を及ぼします。そのため、重要なテストは設計段階やプロトタイプ段階から実施するとよいでしょう。
例えば、以下のような取り組みが考えられます。
- 設計レビューの段階でセキュリティリスクを洗い出す
- プロトタイプでユーザビリティテストを実施し、早期に改善点を特定する
- 単体テスト段階で詳細なホワイトボックステストを実施し、コードの品質を担保する
このように段階的にリスクの検出を図ることで、手戻りを最小限に抑えつつ、効率的な品質向上につなげられます。
8つの品質特性をもとに必要なテストを整理する
ISO/IEC 25010で定義されている8つの品質特性をもとに必要なテストタイプを検討することで、テストタイプの選択漏れを防ぐことができます。
それぞれの品質特性と関連するテストタイプは、以下のように整理できます。
| 品質特性 | 内容 | 関連するテストタイプの例 |
| 機能適合性 | 仕様通りの機能を提供しているか | 機能テスト |
| 性能効率性 | 適切な応答時間や処理速度を実現しているか | 性能テスト、負荷テスト |
| 互換性 | 他システムとの連携や異なる環境での動作が可能か | 互換性テスト |
| 使用性 | スムーズに使用できるか、ユーザーエラーが起きづらいか | ユーザビリティテスト |
| 信頼性 | 安定して動作するか、障害時に適切に対応できるか | 障害許容性テスト、耐久テスト |
| セキュリティ | 認められた権限に応じたデータアクセスができるか、機密性が保たれているか | セキュリティテスト |
| 保守性 | 将来的な変更がしやすいか | コードレビュー、ホワイトボックステスト |
| 移植性 | 異なる環境への移行が可能か | 移植性テスト |
プロジェクト開始時に品質特性ごとの重み付けを明確にしておくことで、適切なテストタイプの選択につながります。
テストタイプの全体像への理解が、最適なテスト計画につながる
それぞれ目的や役割、検証する品質特性が異なるテストタイプ。機能テストで仕様通りの動作を確認できたとしても、性能やセキュリティに問題があれば、ユーザー満足度の低下や離脱につながるため注意が必要です。
また、プロジェクトごとに求められる品質要件の優先順位や内包されるリスクは異なります。そのため、プロジェクトに応じた最適なテストタイプの組み合わせを考えながらテスト計画を組むようにしましょう。
社内にテスト計画・設計のナレッジが不足している場合は、専門的な知見を持つ第三者機関との協業も有効な選択肢の1つです。AGESTのソフトウェアテストサービスでは、テストタイプの取捨選択を含めたテスト計画・設計から実施、改善計画まで一気通貫でサポートを提供しています。豊富な実績を持つテストエンジニアが、お客様の状況や課題に適切な助言を行い、長期的な内製化を支援いたします。
自社の品質保証体制の見直しをお考えの方は、ぜひ一度ご相談ください。
