2024.07.04
ソフトウェアテストとは 、コンピュータ上で動作するソフトウェアに対し、期待どおりに動作することを実証したり、欠陥や想定外の動作を検出したりする活動のことです。
ソフトウェアテストは、あらゆるソフトウェアを世に出すうえで避けて通れないプロセスです。 ソフトウェア開発ライフサイクルの中で、テスト活動を整理し、理解し、適切に実施していくことも重要です。
ソフトウェアテストを静的または動的、外見または内面、目的別、あるいはレベル別などの観点で分類することで、ソフトウェアテストを整理し、ソフトウェア開発ライフサイクルへ適用することができます。
ここでは「ソフトウェアテストとは何か」を基本から徹底解説します。ソフトウェアテストの種類やプロセス、成功させるポイントも紹介していきます。
- もくじ
1．ソフトウェアテストとは
ソフトウェアテストとは、コンピュータ上で動作するソフトウェアが期待どおりに動作するか、品質に問題がないかを検証する一連のプロセスです。
ソフトウェアは人が開発する以上、開発段階での人的ミスをゼロにすることはできません。リリース後に致命的な問題が発生すれば、顧客に多大な損害を与えたり、最悪の場合、ユーザーの命を脅かしたりするケースもあります。
このような問題の流出を防ぐために重要となるプロセスが、ソフトウェアテストです。
広義的には、ソフトウェアの開発成果物（設計書やソースコードなど）のレビューもソフトウェアテストの一種です。
これらは「静的テスト」と呼ばれますが、本記事では主にソフトウェアの実行をともなう「動的テスト」に焦点を当てて解説します。
2．ソフトウェアテストの目的
ソフトウェアテストの主な目的は、ソフトウェアの品質が妥当であるという裏付けを取り、不具合（不正な動作）を検出することです。
ソフトウェアは、あるべき姿を明確化した「要件」や、その実現方法を具体化した「設計」に沿って「実装」します。
そして、動的テストにおいては、ソフトウェアを実際に動かすことで、要件や設計どおりの振る舞いとなっていることを確認し、品質の妥当性を証明するのです。
ソフトウェアテストで不具合が見つかった場合は、その原因を調査し、バグ（プログラムや設計などの不備）を修正する必要があります。
なお、ソフトウェアを修正し、バグを解消するプロセスを「デバッグ」と呼びます。デバッグはテスト前に行うべきプロセスであり、ひと通りのバグを解消したうえでソフトウェアテストを実施することが理想です。
デバッグとは何かについて詳しくは、次の記事をお読みください。
3．ソフトウェアテストに関する基本用語
ソフトウェアテストに関する3つの基本用語「テストケース」「テストレベル」「テスト技法」について解説します。これらの用語は以降でも使うため、把握しておきましょう。
3-1 テストケース
「テストケース」とは、ソフトウェアテストを実施する際の具体的な条件や手順、期待結果などを定義した項目のことです。
ソフトウェアの要件や設計などに応じて事前にテストケースを作成し、それに沿ってテストを実施します。テストケースが不足していると不具合を検出できない恐れがあるため、漏れなくテストケースを作成することが重要です。
なお当サイト「Qbook」では、テストケースを効率的に作成するためのテンプレートを提供しています。無料でダウンロード可能なので、ぜひご活用ください。
3-2 テストレベル
「テストレベル」とは、ソフトウェアテストの検証範囲、フェーズに応じたレベルのことです。
一般的にはプログラムレベルの検証から実施し、フェーズを進めながら徐々にシステム全体へと検証範囲を広げていきます。この各フェーズをレベル分けするのがテストレベルです。テストレベルで分類したソフトウェアテストについては後述します。
3‐3 テスト技法
「テスト技法」とは、ソフトウェアテストの条件やデータ、テストケースなどを決めるうえで役立つテクニックのことです。
適切なテスト技法を用いることで、テストケースの抜け漏れ防止や、作成の効率化につながります。テスト技法で分類したソフトウェアテストについては後述します。
4．ソフトウェアテストの種類（テストレベルによる分類）
ソフトウェアテストには、さまざまな種類があります。まずは、前述のテストレベルで分類した際の代表的な4種類を見ていきましょう。
併せて、テストレベルについてイメージしやすいように、一般的なソフトウェア開発の流れを表現した「Ｖ字モデル」を掲載します。
Ｖ字モデルは、左側の開発工程と右側のテスト工程で構成されており、開発のレベルと各テストのレベルが対応しているのが特徴です。
上図における4つのテスト種類について、順番に紹介します。
4-1 単体テスト（ユニットテスト）
単体テスト（ユニットテスト）は、ソフトウェアのプログラムを構成する個々の要素（コンポーネント）に対して実施するテストです。
具体的なテストの単位は関数やクラス、モジュール、データ構造など、開発手法やプログラムの構造によって異なります。
単体テストは、プログラムレベルの具体的な実装方法を決める「詳細設計」の妥当性を検証するものです。コンポーネントに入力したデータに応じて、適切な処理が行われ、詳細設計どおりの結果が出力されることを検証します。
プログラムを意識した実施が求められるため、プログラムレベルで実行できる統合開発環境を用い、開発者自身が実施することが多いです。また、テストを支援する専用のツールを利用して実施する場合もあります。
4-2 結合テスト（統合テスト）
結合テスト（統合テスト）は、2つ以上のコンポーネントが正しく連携・相互作用するかを検証するテストです。
たとえば、コンポーネントAから送られたデータを、コンポーネントBが正しく表示できるか、といった複数要素をともなう検証を行います。
結合するテスト対象は、それぞれ単体テストを実施し、バグを取り除いたものとなります。つまり、単体テストが正しく完了していなければ、結合テストの段階で不具合が多発する恐れがあります。
結合テストは、ソフトウェアの機能や画面、それらの構成などを具体化する「基本設計」の妥当性を検証するものです。複数コンポーネントで構成された機能が基本設計どおりに動作することや、連携動作による副作用などがないことを検証します。
4-3 システムテスト（総合テスト）
システムテストは、全てのコンポーネントやサブシステムを統合したシステム全体が正しく振る舞うかを検証するテストです。
できる限り本番環境に近いテスト環境を構築して実施することが理想です。単体テストや結合テストが完了し、バグがひと通り取り除かれた前提で実施します。
システムテストは、顧客の要求にもとづきソフトウェアの機能や性能などを明確化する「要件定義」の妥当性を検証するものです。各機能が要件定義で定められた通りに動作することや、システム全体の性能が要件を満たすことなどを検証します。
4-4 受け入れテスト
受け入れテストは、ソフトウェアを納品し、実際に運用しても問題ないかを検証する最終的なテストです。システムテストにより、全体の品質を担保できた前提で実施します。
受け入れテストは、顧客やユーザーがソフトウェアに求めるものを明確化する「要求分析」の妥当性を検証するものです。顧客やユーザーの要求を満たす必要があるため、実運用に近い環境・手順で動作させ、要求に合致しない部分がないかを検証します。
インストールや設定といった導入段階の検証も含まれることが一般的です。受け入れテストは多くの場合、ソフトウェアを発注した顧客や独立したテストチームが行います。
5．ソフトウェアテストの種類（テスト技法による分類）
続いて、前述のテスト技法による分類を見ていきましょう。ソフトウェアテストをテスト技法で分類した場合、次の3種類が代表的です。
- ブラックボックステスト
- ホワイトボックステスト
- 経験ベースのテスト
5‐1 ブラックボックステスト
「ブラックボックステスト」は、テスト対象の内部構造を考慮せず、外部から見た振る舞いに着目するソフトウェアテストです。
ソフトウェアに特定のインプットを与えて動作させた際に、要件や設計として想定されるアウトプットが得られることを検証します。なお、一般的にシステムテストは外部的な振る舞いに着目するため、ブラックボックステストの一種です。
5‐2 ホワイトボックステスト
「ホワイトボックステスト」は、テスト対象の内部構造に着目するソフトウェアテストです。プログラムレベルで処理の分岐やデータの流れなどを把握したうえで、設計どおりの処理が行われるかを検証します。なお、一般的に単体テストはプログラムの処理分岐なども含めて検証するため、ホワイトボックステストの一種です。
5‐3 経験ベースのテスト
「経験ベースのテスト」は、過去の経験を頼りに実施するソフトウェアテストです。テスト担当者自身の経験則や、過去のテスト結果から得た知見などを活用します。
主にテストケースを作成・選択するプロセスに経験を活用するのが特徴です。
前述の2種類では難しいテストケースを実施できる可能性がありますが、品質はテスト担当者やテストチームの経験量に大きく依存します。ブラックボックステストやホワイトボックステストを補完する位置づけのテストといえます。
6．ソフトウェアテストの主要プロセス
ソフトウェアテストでは、さまざまなプロセスを正しい手順で進めていく必要があります。ソフトウェアテストの主要なプロセスは、次の6つです。
6-1 テスト計画
「テスト計画」は、ソフトウェアテストを進めるうえでの基本事項を明確にするプロセスです。
ソフトウェアテストの目的やテスト範囲、担当者、スケジュールなどを決めます。テスト計画に不備があれば、以降のテストプロセスにも悪影響が生じるでしょう。そのため、テスト計画から正確に実施することが重要となります。
6-2 テスト分析
「テスト分析」は、対象となるソフトウェアの要件や設計などを分析し、「何をテストすべきか」を明確にするプロセスです。
具体的なテストケースは作成しませんが、どのような観点でテストすべきかを決めておく必要があります。十分なテスト分析を行うことで、テストケースを作成する際の方向性がはっきりするでしょう。なお、テスト分析について詳しくは、次の記事をご覧ください。
6-3 テスト設計
「テスト設計」は、テスト分析に沿って必要なテストケースを作成し、「どのようにテストするか」を明確にするプロセスです。
テストケースを漏れなく作成しようとすると、膨大な量となり、負担が大きくなりやすいといえます。そのため、「同値分割法」や「境界値分析」といったテスト技法を活用し、効率化することが一般的です。テスト技法の種類について知りたい方は、次の記事を参考にしてください。
6-4 テスト実装
「テスト実装」は、テストケースを実行するために必要となる準備作業全般を行うプロセスです。たとえば、テストデータやテストアカウントの作成が挙げられます。
また、ソフトウェアテストの自動化を図る場合、テストコードの実装やテスト自動化ツールの導入が必要です。
テスト自動化について詳しくは、次の記事をお読みください。
6-5 テスト実行（実施）
「テスト実行（実施）」は、テストケースに沿って実際にソフトウェアを検証していくプロセスです。
テストケースの条件や手順のもとでソフトウェアを動かし、実際の振る舞いが期待結果と一致しているかを検証します。テスト実行の結果、NGのテストケースがある場合は、原因調査のうえ修正が必要です。
テスト実行について詳しくは、次の記事をご覧ください。
6-6 テスト完了
「テスト完了」は、ソフトウェアテストの結果を整理し、最終確認やフィードバックを行うプロセスです。
ひと通りテストケースを消化した後に実施します。テスト結果に問題がないことの確認や、作業上の改善点や問題点の振り返りなどが主な内容です。特に問題がなければ、ソフトウェアテストは完了となります。
7．ソフトウェアテストの7原則とは
ソフトウェアテストの歴史は長く、そのなかで7つの原則が提唱されました。ここでは、ソフトウェアテストにおける7原則を簡単に紹介します。
1．テストは欠陥があることは示せるが、欠陥がないことは示せない
ソフトウェアテストは前提として、欠陥があることは示せますが、欠陥がないことを完全には示せません。テストケースを実行して問題が出なかったとしても、偶然発生しなかったり、見逃したりしていることも考えられます。
そのため、「作成した全てのテストケースに問題がない＝100％欠陥がない」とは言い切れず、過信は禁物です。
2．全数テストは不可能
ソフトウェアテストのテストケースを全て網羅しようとすると、さまざまな要素の組み合わせを考慮する必要があります。
結果としてテストケースは膨大なものとなるため、現実的に全てを実施することは不可能です。そのため、検証する価値の高いテストケースを選択して作成したり、実行上の優先順位を付けたりすることが重要となります。
3．早期テストで時間とコストを節約
ソフトウェアテストは、できる限り早期に実施することが理想といえます。ソフトウェアテストが後になるほど、欠陥が判明した際に多くのプロセスをさかのぼって対応しなければなりません。
つまり、早期に実施するほうが時間とコストを節約できるといえます。
4．欠陥の偏在
ソフトウェアの欠陥は、特定の機能やコンポーネントに偏りやすい傾向があります。これは、機能やコンポーネントによって、難易度や複雑度が異なるためです。
難易度が高い、あるいは複雑なものほど欠陥が生じやすいでしょう。そのため、欠陥の偏在を考慮してテスト工数を配分することが理想です。
5．テストの弱化
ソフトウェアテストでは、決まったパターンのテストケースを実施し続けると、新しい欠陥を発見することが難しくなります。
そのため、定期的にソフトウェアテストの方法を見直すことも考えましょう。
6．テストはコンテキスト次第
ソフトウェアテストの内容や方法は、テスト対象や目的、予算などさまざまな要素の影響を受けます。
そのため、「このソフトウェアはこうテストすべきだ」といった先入観を持つべきではありません。コンテキスト（状況や環境）次第でテストの内容や方法が変わってくることを念頭に置きましょう。
7．「欠陥ゼロ」の落とし穴
欠陥やバグが無く、テストがうまくいったとしても、そのソフトウェアを顧客やユーザーが満足してくれるかは別問題です。
たとえば、見た目やデザイン、ユーザビリティなどは、ユーザーの要求が満たされていなければ不満足につながってしまいます。欠陥やバグをゼロにすることに固執するのではなく、顧客やユーザーの要求に対する満足度には、常に注意するようにしましょう。
8．ソフトウェアテストを成功につなげる方法
ソフトウェアテストの方法はさまざまですが、企業やチームに合わせた方法を選ぶことが大切です。ここでは、ソフトウェアテストを成功につなげる方法を3つ紹介します。
8-1 テスト自動化を図る
ソフトウェアテストのテストケースは、適切に選定したとしても相当数になることが少なくありません。
テスト担当者の負担を軽減したい場合は、テスト自動化を図るとよいでしょう。ツールやテストコードを活用することで、テストケースを自動で実行できます。
ただしテスト自動化の実施方法によっては、かえって負担増大につながる場合もあるため注意が必要です。
テスト自動化を成功させるポイントを知りたい方は、次の記事を参考にしてください。
8-2 テスト技法に関する知識を増やす
ソフトウェアテストを効率的に実施したい場合、テスト技法に関する知識を増やすことも効果的です。テスト技法を有効活用することでテスト設計を効率化でき、価値の高いテストケースを選定できるでしょう。
なお、テスト技法に関する理解を深めたい場合は、弊社のeラーニングをご活用ください。動画とテキストを組み合わせた専門家監修の教材を用いて、テストやソフトウェア品質について効率的に学習できます。
ソフトウェア品質セミナー eラーニング版「品質とテストの基本編」
ソフトウェアテストの意義と重要性、並びにソフトウェア業務の概観と品質の考え方を体系的に把握することを目的としています。そして、基本的な発想法の講義を実施し、実業務での活用の視点を提供します。
8-3 自社での実施が難しい場合は第三者検証を活用する
高品質なソフトウェアテストを実施するためには、テスト分析やテスト設計といった各プロセスのノウハウが必要です。
ソフトウェアテストに精通した人材を自社で確保できない場合は、外部のプロが実施してくれる「第三者検証」を活用するのもよいでしょう。
なおQbookを運営するバルテスでは、ソフトウェアテストの専門家が実施する第三者検証サービスを提供しています。自社でソフトウェアテストの実施が難しい場合は、ぜひご活用ください。
まとめ
ソフトウェアテストとは、ソフトウェアが期待どおりに動作するか、品質に問題がないかを検証する一連のプロセスのことです。
テストの種類は様々ありますが、テストレベルでの分類は以下の通りです。
- 単体テスト...詳細設計に対応しコンポーネント単体を検証
- 結合テスト...基本設計に対応しコンポーネントやシステムの相互作用部分を検証
- システムテスト...要件定義に対応し統合されたシステムが要件を満たすことを検証
- 受け入れテスト...要求分析に対応し対象システムが要求に妥当であるかを検証
テスト技法による分類は主に以下の3つです。
- ブラックボックステスト
- ホワイトボックステスト
- 経験ベースのテスト
ソフトウェアテストでは、さまざまなプロセスを正しい手順で進めていく必要があります。
あらゆるソフトウェアにはテストが欠かせません。高品質なソフトウェアテストを実施するためには、基本的な知識を身につけることが大切です。
本記事で紹介したソフトウェアテストの種類やプロセス、方法をぜひ参考にしてください。
