2024.02.07
一口にテストと言っても、その種類はさまざまです。それぞれのテストの役割や意味、意図を理解することで、テストの内容をより良くしたり、状況に応じたテストを計画したりできるようになります。
ここでは、よく使われる代表的なテストと2つの視点(V＆V)について解説します。
- もくじ
1．テストの種類
単体テスト・結合テスト・システムテスト
ソフトウェアは、さまざまなプログラムの部品によって構成されています。その部品の最小単位を「関数」、関数を組み合わせたものを「機能」、機能を組み合わせたものを「システム」と呼びます。
関 数：プログラムの部品の最小単位
機 能：「関数」を組み合わせて作り上げたもの
システム：「機能」を組み合わせて作り上げたもの
ソフトウェアのテストは、小さな単位から始めて、少しずつ粒度を大きくしていきます。
＜テストの順序＞
1.（粒度小）プログラムの最小単位である「関数」を対象に、「単体テスト」を行う
2.（粒度中）いくつかの関数を組み合わせて、「結合テスト」を行う
3.（粒度大）いくつかの機能を組み合わせて、「システムテスト」を行う
＜粒度を、小さな単位からだんだん大きくする理由＞
・テスト対象の粒度が大きくなるほど、プログラム上で未検証の部分が増えていくため
・テスト対象の粒度が大きくなるほど、バグを見つけにくくなるため
・テスト対象の粒度が大きくなるほど、テストでバグを見つけられても、原因調査がやりにくくなり、工数がかかるため
・テスト対象の粒度が大きくなるほど、手戻りが大きくなり、コスト的にも時間的にも無駄が生じるため
この、「単体テスト」「結合テスト」「システムテスト」のことを、テストレベルと呼びます。
テストレベルという用語は ソフトウェア開発プロジェクトで頻繁に使われるので覚えておきましょう。
機能テスト、非機能テスト
ソフトウェアやシステムを開発する上で、どんな機能を持たせる必要があるか定義するものを、「機能要件」と呼びます。
機能には直接関係しないものの、そのソフトウェアやシステムが備えるべき特性を、「非機能要件」と呼びます。
機能テスト
定義されている機能が仕様どおりに動作するかを、検証するテスト
非機能テスト
機能テストの項目以外を検証するテスト
- 性能テスト
- 信頼性テスト（大容量テスト、エージングテストなど）
- ユーザビリティテスト など
ホワイトボックステスト、ブラックボックステスト
ホワイトボックステストとは、テスト対象のプログラム構造を把握した上で行うテストです。
主な観点は、プログラムが設計したとおりに、実装したとおりに動作するかを確認することです。
一方、ブラックボックステストは、テスト対象のプログラム構造を把握していない状態で、プログラムが仕様どおりに動作するかを確認するテストです。
テスト対象の構造が不明（ブラックボックス）な状況でテストすることから、このように呼ばれています。
前述した「テストレベル」で言うと、ホワイトボックスとブラックボックスの使い分けは、多くは以下のように行われます。
単体テスト：ホワイトボックステスト
結合テスト：ホワイトボックステスト
システムテスト：ブラックボックステスト
ホワイトボックステストの狙いは、テスト対象のプログラムを細かいところを隅々まで検証することです。
対して、ブラックボックステストでプログラムの1行1行を細かく検証するのは非常に困難です。ブラックボックステストをいかに密に行っても、どうしても検証漏れが起きてしまいます。
では、ホワイトボックステストをしっかり行えばブラックボックステストは必要無いのかと言うと、そうではありません。
ホワイトボックステストは、プログラムが設計どおり・実装どおりに動作するかを主に検証するため、プログラムの設計に漏れ・抜けがあった場合や、仕様の誤認があった場合に検出できず、バグを見逃してしまう可能性があります。
そのため、ブラックボックステストも行う必要があります。 ホワイトボックステストとブラックボックステストは、それぞれに役割があり、双方が補い合っているのです。
動的テスト、静的テスト
テスト対象のプログラムやシステムを実際に動かして検証することを、「動的テスト」と言います。
対して、テスト対象を動作させないで検証することを、「静的テスト」と言います。
静的テストの代表的なものは、レビューです。その他にも、静的解析や形式手法といったものがあります。
静的テストでは、動的テストで再現するのは困難な、微妙なタイミングなどで発露するバグを、比較的見つけやすいです。また、動的テストは、バグの発見から修正まで、バグ票の起票と原因解析を行うことで時間と労力がかかるのに対して、静的テストのレビューなどでは、不具合箇所をピンポイントで見つけられるため、コストを抑えて対処しやすいというメリットがあります。
品質管理や品質保証のためには、動的テストと静的テストをどう実施していくか、戦略を講じることがカギとなります。
手動テスト、自動テスト
マウスクリックやテキスト入力、実施結果の良否判定などのテストのオペレーションを、人の手で行うことを、「手動テスト」と呼びます。
対して、テストのオペレーションをコンピュータで行うことを、「自動テスト」と呼びます。
自動テストには以下のようなメリットがあり、昨今では導入する組織が増えてきています。
- テストのオペレーションが迅速で正確（誤操作・誤認識などのヒューマンエラーが無い）
- 繰り返し何度も実施することでコスト的なメリットが得られる
ただし、自動テストを導入・運用するにあたっては以下のような前提条件もあります。
- テスト対象が自動テストを実施できる構造になっていること
- 自動テストの環境を開発し、セットアップするコストと労力がかかること
- 仕様変更・設計変更が生じたら、それを自動テスト環境にも反映する必要があること
スクリプト型テスト、非スクリプト型テスト
テストを実施するパターンには、「スクリプト型テスト」と「非スクリプト型テスト」があります。
スクリプト型テストとは、テストオペレータがテスト手順書を参照しながら、テストの操作を実施するものです。自動テストも、あらかじめ実施手順をプログラム化しているため、スクリプト型テストに含まれます。
非スクリプト型テストは、テストの実施手順を定めていないものを指します。
たとえば、ランダムに操作を行うモンキーテストや、テストの熟練者が仕様の把握とテスト対象の動きを観察しながら行う探索的テストは、非スクリプト型テストに分類されます。
スクリプト型、非スクリプト型のどちらにも、それぞれメリットがあります。
スクリプト型テストのメリット
- テスト設計の質を担保しやすい
- テスト設計の内容を文書化すれば、レビューしやすい
- テストの再利用がしやすい
非スクリプト型テストのメリット
- テスト設計の手間を省けるため、テスト期間を短縮できる
- テスト内容を臨機応変に変えられる
スクリプト型と非スクリプト型は、目的が異なるため、どちらかが優れているわけではありません。
テスト対象とプロジェクトの状況に応じて、スクリプト型・非スクリプト型のテストを、どこでどのように使うのか、戦略を講じることが必要です。
2．テストの2つの視点（V&V）
テストには、大きく分けて、「検証」と「妥当性確認」の２つの視点があります。
検証（Verification）
仕様通りに動作するか、製品が正しく動作するかを確認すること
妥当性の確認（Validation）
その製品によって目的を達成できているか、正しい製品を開発できているかを確認すること
2つの視点をあわせて、「Verification and Validation」または「V&V」と呼びます。
ここで重要なのは、検証（Verification）の視点でテストを実施してバグがゼロだったとしても、品質が高いとは言い切れない、ということです。
例えば、仕様通りの動きをするものの、デザインやユーザビリティがイマイチで、使い勝手が悪かったらどうでしょうか。正しく動作はするけれど、そのための手順が非常に複雑で時間がかかるものだったらどうでしょうか。
その製品が仕様通りに動作していたとしても、その製品で実現したかったことが十分できないのであれば、それはユーザーにとって品質が良いものとは言えません。
検証（Verification）の視点でテストするか、妥当性確認（Validation）の視点でテストするか、またはその両方なのか。テスト計画策定など早期の段階で、テストの指針や目的を明確にしておくことが重要です。 そのテストに求められているものが抜け落ちた状態で先に進んでしまえば、大きな手戻りや作業追加が発生し、リカバリが非常に難しくなります。
まとめ
テストには様々な種類があります。
それぞれの役割や特徴を理解することで、より効率的にテストをしたり、状況にあったテストを計画をすることができます。
テストの効率化を上げて開発スピードを向上させていくためにも、今回紹介したテストの種類や視点については理解しておくことをおすすめします。
テスト技法の種類についてはこちらの記事もご覧ください。
