ソフトウェアテスト

ソフトウェアテストには通常、ソフトウェアバグ（望ましくない結果を引き起こすコードの欠陥）の処理が含まれます。 ^{[ 12 ]： 31}バグは一般的にテストの進行を遅らせ、デバッグと修正のためにプログラマーの支援を必要とします。

すべての欠陥が障害につながるわけではありません。例えば、デッドコードの欠陥は障害とはみなされません。

ある時点では故障を引き起こさない欠陥でも、環境の変化により後々故障につながる可能性があります。環境の変化の例としては、新しいコンピュータハードウェアでの実行、データの変更、異なるソフトウェアとの連携などが挙げられます。^{[ 13 ]}

単一の欠陥が、複数の故障症状を引き起こす可能性がある。

ソフトウェアテストには、要件ギャップ（設計から要件が省略されている状態）が含まれる場合があります。^{[ 5 ]： 426}要件ギャップは、テスト容易性、拡張性、保守性、パフォーマンス、セキュリティなどの非機能要件であることがよくあります。

ソフトウェアテストの根本的な限界は、単純な製品であっても、入力と前提条件（初期状態）のすべての組み合わせでテストを行うことが不可能であることです。 ^{[ 3 ]： 17-18 [ 14 ]} 異常な条件下で現れる欠陥は、テストでは見つけにくいです。また、品質の非機能的側面（本来あるべき姿と、本来果たすべき機能）であるユーザビリティ、スケーラビリティ、パフォーマンス、互換性、信頼性は主観的になる可能性があり、ある人にとって十分な価値があるものが、別の人にとってはそうではないかもしれません。

すべての可能な入力に対してテストを行うことは現実的ではないが、組み合わせ論を用いることで、テスト回数を最小限に抑えつつ網羅率を最大化することができる。^{[ 15 ]}

ソフトウェアテストは、ソフトウェアシステムのどの部分がテストの対象となるかに基づいて、レベルに分類できます。^{[ 19 ] [ 20 ] [ 21 ] [ 22 ]}

ソフトウェアテストには多くの手法があります。レビュー、ウォークスルー、または検査は静的テストと呼ばれ、一方、与えられたテストケースのセットでプログラムされたコードを実行することは動的テストと呼ばれます。^{[ 24 ] [ 25 ]}

静的テストは、校正のように暗黙的に行われることが多く、プログラミングツール/テキストエディタがソースコード構造をチェックしたり、コンパイラ（プリコンパイラ）が静的プログラム解析として構文とデータフローをチェックしたりする場合にも行われます。動的テストは、プログラム自体が実行されるときに行われます。動的テストは、コードの特定のセクションをテストするために、プログラムが 100% 完成する前に開始される場合があり、個別の関数またはモジュールに適用されます。^{[ 24 ] [ 25 ]}これらのための典型的な手法は、スタブ/ドライバを使用するか、デバッガ環境から実行することです。^{[ 25 ]}

静的テストには検証が含まれるが、動的テストには妥当性確認も含まれる。^{[ 25 ]}

パッシブテストとは、ソフトウェア製品とのやり取りなしにシステムの動作を検証することです。アクティブテストとは異なり、テスターはテストデータを提供せず、システムログとトレースを調べます。パターンと特定の動作をマイニングして、何らかの決定を下します。^{[ 26 ]}これは、オフラインランタイム検証とログ分析に関連しています。

実施するテスト戦略の種類は、テスト計画の実行開始前にIUTに適用するテストを決定する必要があるかどうか（事前設定テスト^{[ 29 ]}）またはIUTに適用する各入力が、以前のテストの適用中に得られた出力に動的に依存することができるかどうか（適応テスト^{[ 30 ] [ 31 ]}）によって異なります。

ソフトウェアテストは、多くの場合、ホワイトボックスとブラックボックスに分けられます。これら2つのアプローチは、テストケースを設計する際にテスターが取る視点を説明するために使用されます。両方のボックスの側面を含むグレーボックスと呼ばれるハイブリッドアプローチも、ソフトウェアテスト方法論に適用できます。^{[ 32 ] [ 33 ]}

ホワイトボックステスト

ホワイトボックステスト（クリアボックステスト、グラスボックステスト、トランスペアレントボックステスト、構造テストとも呼ばれる）は、エンドユーザーに公開される機能とは対照的に、プログラムの内部構造や動作を検証します。ホワイトボックステストでは、システムの内部的な視点（ソースコード）とプログラミングスキルを使用してテストケースを設計します。テスターは、コード内のパスを実行するための入力を選択し、適切な出力を決定します。^{[ 32 ] [ 33 ]}これは、回路内のノードをテストすること、たとえばインサーキットテスト（ICT）に似ています。

ホワイトボックステストは、ソフトウェアテストプロセスのユニットレベル、統合レベル、システムレベルで適用できますが、通常はユニットレベルで行われます。 ^{[ 34 ]}ユニット内のパス、統合中のユニット間のパス、システムレベルテスト中のサブシステム間のパスをテストできます。このテスト設計方法は多くのエラーや問題を発見できますが、仕様の未実装部分や不足している要件を検出できない場合があります。

ホワイトボックステストで使用される手法には、次のものがあります。^{[ 33 ] [ 35 ]}

• APIテスト– 公開APIおよび非公開API（アプリケーションプログラミングインターフェース）を使用したアプリケーションのテスト
• コードカバレッジ– コードカバレッジの基準を満たすテストを作成する（例えば、テスト設計者はプログラム内のすべてのステートメントが少なくとも1回実行されるようなテストを作成できる）。
• 障害注入法 – テスト戦略の有効性を評価するために意図的に障害を導入する
• 突然変異検査方法
• 静的試験方法

コードカバレッジツールは、ブラックボックステストを含むあらゆる方法で作成されたテストスイートの完全性を評価できます。これにより、ソフトウェアチームはめったにテストされないシステムの部分を調べ、最も重要な機能ポイントがテストされていることを確認できます。^{[ 36 ]}ソフトウェアメトリクスとしてのコードカバレッジは、次の項目についてパーセンテージで報告できます。^{[ 32 ] [ 36 ] [ 37 ]}

• 関数カバレッジとは、実行された関数について報告するものです。
• ステートメントカバレッジとは、テストを完了するために実行された行数を報告するものです。
• 判定カバレッジとは、特定のテストの真分岐と偽分岐の両方が実行されたかどうかを報告するものです。

100% ステートメント カバレッジは、すべてのコード パスまたは分岐 (制御フローの観点から) が少なくとも 1 回実行されることを保証します。これは正しい機能を保証するのに役立ちますが、同じコードが異なる入力に対して正しく処理される場合と誤って処理される場合があるため、十分ではありません。^{[ 38 ]}

ブラックボックステスト

ブラックボックステスト（機能テストとも呼ばれる）は、実装を知らず、ソースコードを読まずにテストケースを設計することを指します。テスターはソフトウェアが何をするべきかだけを知っており、どのように行うかは知りません。^{[ 39 ]}ブラックボックステストの手法には、同値分割、境界値分析、全ペアテスト、状態遷移表、決定表テスト、ファジングテスト、モデルベーステスト、ユースケーステスト、探索的テスト、仕様ベーステストなどがあります。^{[ 32 ] [ 33 ] [ 37 ]}

仕様ベースのテストは、適用要件に従ってソフトウェアの機能をテストすることを目的としています。^{[ 40 ]}このレベルのテストでは通常、詳細なテストケースがテスターに​​提供され、テスターは、特定の入力に対して出力値（または動作）がテストケースで指定された期待値と「同じ」か「同じではない」かを簡単に検証できます。テストケースは、仕様と要件、つまりアプリケーションが何をするべきかに基づいて構築されます。仕様、要件、設計などのソフトウェアの外部記述を使用してテストケースを導き出します。これらのテストは機能的または非機能的である可能性がありますが、通常は機能的です。仕様ベースのテストは、正しい機能を保証するために必要となる場合がありますが、複雑な状況やリスクの高い状況から保護するには不十分です。^{[ 41 ]}

ブラックボックステストは、通常ユニットレベルでは使用されないものの、あらゆるレベルのテストに使用できます。^{[ 34 ]}

コンポーネントインターフェーステスト

コンポーネント インターフェース テストは、サブシステム コンポーネントの関連する動作だけでなく、データ値にも焦点を当てたブラック ボックス テストの一種です。 ^{[ 42 ]}コンポーネント インターフェース テストの手法は、ユニット間の完全な統合テストを超えて、さまざまなユニットまたはサブシステム コンポーネント間で渡されるデータの処理をチェックするために使用できます。^{[ 43 ] [ 44 ]}渡されるデータは「メッセージ パケット」とみなすことができ、あるユニットから生成されたデータの範囲またはデータ型をチェックし、別のユニットに渡される前に妥当性をテストできます。インターフェース テストのオプションの 1 つは、渡されるデータ項目のログ ファイルを別に保持することです。多くの場合、タイム スタンプが記録され、数日または数週間にわたってユニット間で渡される数千件のデータ ケースを分析できます。テストには、他のインターフェース変数が通常の値として渡される一方で、一部の極端なデータ値の処理をチェックすることが含まれます。^{[ 43 ]}インターフェース内の異常なデータ値は、次のユニットでの予期しないパフォーマンスを説明するのに役立ちます。

視覚検査

ビジュアルテストの目的は、開発者が必要な情報を簡単に見つけられるようにデータを提示し、情報が明確に表現されるようにすることで、ソフトウェア障害発生時に何が起こっていたかを開発者が調査できるようにすることです。^{[ 45 ] [ 46 ]}

ビジュアルテストの核心は、問題（またはテストの失敗）を単に説明するだけでなく、実際に目に見える形で示すことで、理解度と明確さが大幅に向上するという考え方です。そのため、ビジュアルテストでは、テストシステム上で発生するすべての事象をビデオ形式で記録し、テストプロセス全体を録画する必要があります。出力ビデオには、ピクチャーインピクチャー方式のウェブカメラによるリアルタイムのテスター入力と、マイクからの音声解説が補足されます。

ビジュアルテストには多くの利点があります。テスターは開発者に問題（およびそれに至る経緯）を言葉で説明するだけでなく、視覚的に示すことができるため、コミュニケーションの質が飛躍的に向上します。また、多くの場合、テストの失敗を再現する必要がなくなります。開発者はテスト失敗に必要なすべての証拠を入手できるため、障害の原因と修正方法に集中できます。

アドホックテストと探索的テストは、実装に必要な準備時間が少なく、重要なバグを迅速に発見できるため、ソフトウェアの整合性をチェックするための重要な方法論です。^{[ 47 ]}アドホックテストでは、テストが即興的に行われるため、テスターが文書化された方法に基づいてテストを行い、そのテストのバリエーションを即興的に作成することで、欠陥修正のより厳密な検証が可能になります。^{[ 47 ]}ただし、手順の厳密な文書化が維持されない限り、アドホックテストの限界の1つは再現性の欠如です。^{[ 47 ]}

ソフトウェア障害（実際の障害であれ、認識上の障害であれ）の一般的な原因は、他のアプリケーションソフトウェア、オペレーティングシステム（またはオペレーティングシステムのバージョン、新旧を問わず）、あるいは元の環境と大きく異なるターゲット環境（例えば、デスクトップ上で実行することを想定していた端末アプリケーションやGUIアプリケーションが、Webブラウザでレンダリングする必要のあるWebアプリケーションに改造される場合など）との互換性の欠如です。例えば、下位互換性の欠如は、プログラマが最新バージョンのターゲット環境でのみソフトウェアを開発およびテストし、すべてのユーザーがそのバージョンを使用しているとは限らないために発生する可能性があります。その結果、最新のソフトウェアが以前のバージョンのターゲット環境や、以前のバージョンのターゲット環境では使用可能だった古いハードウェア上で動作しないという意図しない事態が生じます。このような問題は、オペレーティングシステムの機能を別のプログラムモジュールやライブラリに事前に抽象化することで解決できる場合があります。

健全性テストは、さらなるテストを進めることが妥当かどうかを判断するものです。

スモークテストとは、ソフトウェアの動作を最小限に試行し、ソフトウェアが全く動作しないような基本的な問題がないかどうかを判断するために行われるテストです。このようなテストは、ビルド検証テストとして使用できます。

回帰テストは、大規模なコード変更後に欠陥を見つけることに重点を置いています。具体的には、劣化または消失した機能、および再発した古いバグなど、ソフトウェアの回帰を発見することを目的としています。このような回帰は、以前は正しく動作していたソフトウェア機能が意図どおりに動作しなくなったときに発生します。通常、回帰は、新しく開発されたソフトウェアの部分が既存のコードと衝突したときに、プログラムの変更の意図しない結果として発生します。回帰テストは、以前のソフトウェア機能の多数の詳細をチェックするため、商用ソフトウェア開発では通常最大のテスト作業であり、 ^{[ 52 ]}新しいソフトウェアを開発しながら、以前の機能が引き続きサポートされていることを確認するために、新しい設計の一部をテストするために古いテストケースを使用することもできます。

回帰テストの一般的な手法としては、以前に実行したテストケースを再実行し、以前に修正した不具合が再発していないかを確認することが挙げられます。テストの深さは、リリースプロセスの段階と追加機能のリスクによって異なります。リリース後半に追加された変更やリスクが高いと判断された変更については、徹底的なテストを行うこともできますし、リリース初期に変更が加えられた場合やリスクが低いと判断された場合は、各機能に対して肯定的なテストのみを行う、非常に浅いテストを行うこともできます。

受け入れテストは、ソフトウェアが顧客の期待を満たしていることを確認するためのシステムレベルのテストです。^{[ 53 ] [ 54 ] [ 55 ] [ 56 ]}

受け入れテストは、プロジェクトの終了時または途中、アジャイルプロジェクトでは完了した各ユーザーストーリーの後などに実施されることがあります。^{[ 57 ]}

テストは、ソフトウェア開発プロセスのどの段階で実行されるか、またはテストの具体性のレベルによって、これらのレベルに分類されることが多い。^{[ 56 ]}

• ユーザー受け入れテスト（UAT）
• 運用受入試験（OAT）
• 契約および規制上の受入試験
• アルファテストとベータテスト

場合によっては、UATは顧客自身が、自社の環境とハードウェア上で実施する。

OATは、品質管理システムの一部として、製品、サービス、またはシステムの運用準備（リリース前）を実施するために使用されます。OATは、主にソフトウェア開発およびソフトウェア保守プロジェクトで使用される、一般的な非機能ソフトウェアテストの一種です。このタイプのテストは、サポート対象となるシステム、または本番環境の一部となるシステムの運用準備状況に焦点を当てています。そのため、運用準備テスト（ORT）または運用準備および保証（OR&A）テストとも呼ばれます。OAT内の機能テストは、システムの非機能的な側面を検証するために必要なテストに限定されます。

さらに、ソフトウェアテストでは、システムの移植性が期待どおりに動作することに加えて、動作環境を損傷したり部分的に破損させたり、その環境内の他のプロセスを動作不能にしたりしないことを保証する必要があります。^{[ 58 ]}

契約上の受入テストは、契約締結時に定義された契約上の受入基準に基づいて実施され、規制上の受入テストは、ソフトウェア製品に関連する規制に基づいて実施されます。これら2つのテストは、ユーザーまたは独立したテスターに​​よって実施できます。規制上の受入テストでは、規制当局がテスト結果を監査する場合もあります。^{[ 56 ]}

アルファテストとは、開発者のサイトで潜在的なユーザー/顧客または独立したテストチームによって行われる、シミュレーションまたは実際の運用テストのことです。アルファテストは、ソフトウェアがベータテストに進む前に、内部受け入れテストの一形態として、既製ソフトウェアによく用いられます。^{[ 59 ]}

ベータテストはアルファテストの後に行われ、外部ユーザー受け入れテストの一形態とみなすことができます。ベータ版と呼ばれるソフトウェアのバージョンは、ベータテスターと呼ばれるプログラミングチーム以外の限られたユーザーにリリースされます。ソフトウェアは、さらなるテストによって製品の欠陥やバグが少ないことを保証するために、グループにリリースされます。ベータ版は、将来のユーザーからのフィードバックの範囲を最大化し、より早く、長期間または無期限に（永久ベータ）価値を提供するために、一般に公開されることがあります。^{[ 60 ]}

機能テストとは、コードの特定の動作や機能を検証する活動のことです。これらは通常、コード要件ドキュメントに記載されていますが、開発手法によってはユースケースやユーザーストーリーに基づいて行われる場合もあります。機能テストは、「ユーザーはこれを実行できるか」または「この特定の機能は正しく動作するか」といった疑問に答えることを目的としています。

非機能テストとは、スケーラビリティやその他のパフォーマンス、特定の制約下での動作、セキュリティなど、特定の機能やユーザー操作とは直接関係のないソフトウェアの側面をテストするものです。テストによって、スケーラビリティやパフォーマンスの極端な状態が不安定な実行につながる限界点、つまりブレークポイントが特定されます。非機能要件は、特にユーザーの適合性という観点から、製品の品質を反映する傾向があります。

継続的テストとは、ソフトウェアリリース候補に関連するビジネスリスクについて即座にフィードバックを得るために、ソフトウェアデリバリーパイプラインの一部として自動テストを実行するプロセスです。 ^{[ 61 ] [ 62 ]}継続的テストには、機能要件と非機能要件の両方の検証が含まれます。テストの範囲は、ボトムアップ要件やユーザーストーリーの検証から、包括的なビジネス目標に関連するシステム要件の評価まで広がります。^{[ 63 ] [ 64 ]}

破壊的テストは、ソフトウェアまたはサブシステムを意図的に故障させようとするものです。無効な入力や予期しない入力を受け取ったときにソフトウェアが正しく機能するかどうかを検証し、入力検証ルーチンとエラー管理ルーチンの堅牢性を評価します。 ^{[ 65 ]}ファジングの形式によるソフトウェア障害注入は、障害テストの一例です。ソフトウェア障害注入のページには、さまざまな商用非機能テストツールへのリンクがあります。また、破壊的テストを実行するオープンソースおよび無料のソフトウェアツールも多数あります。

パフォーマンス テストは一般的に、特定のワークロードの下でシステムまたはサブシステムが応答性と安定性の面でどのように動作するかを判断するために実行されます。また、拡張性、信頼性、リソース使用量など、システムのその他の品質特性を調査、測定、検証、または確認するためにも役立ちます。

負荷テストは、大量のデータや多数のユーザーなど、特定の負荷がかかった状態でもシステムが動作し続けることができるかどうかを主にテストします。これは一般的にソフトウェアのスケーラビリティと呼ばれます。非機能テストとして実行される関連する負荷テストは、耐久性テストと呼ばれることがよくあります。ボリュームテストは、特定のコンポーネント（たとえば、ファイルやデータベース）のサイズが急激に増加した場合でもソフトウェアの機能をテストする方法です。ストレステストは、予期しない、またはまれなワークロードの下での信頼性をテストする方法です。安定性テスト（負荷テストまたは耐久性テストと呼ばれることが多い）は、ソフトウェアが許容期間内またはそれ以上の期間にわたって継続的に正常に機能できるかどうかを確認します。

パフォーマンス テストの具体的な目標については、ほとんど合意が得られていない。負荷テスト、パフォーマンス テスト、スケーラビリティ テスト、ボリューム テストといった用語は、しばしば同義語として使われている。

リアルタイムソフトウェアシステムには、厳格なタイミング制約があります。タイミング制約が満たされているかどうかをテストするために、リアルタイムテストが使用されます。

ユーザビリティ テストは、ユーザー インターフェースが使いやすく理解しやすいかどうかを確認するものです。これは主にアプリケーションの使用に関するものです。これは自動化できる種類のテストではなく、熟練したUI デザイナーによって監視される実際の人間のユーザーが必要です。ユーザビリティ テストでは、構造化されたモデルを使用して、インターフェースがどれだけうまく機能するかを確認できます。Stanton、Theofanos、および Joshi (2015) モデルはユーザー エクスペリエンスに着目し、Al-Sharafat および Qadoumi (2016) モデルは専門家の評価用で、デジタル アプリケーションのユーザビリティを評価するのに役立ちます。^{[ 66 ]}

アクセシビリティテストは、ソフトウェアが障害のある人にもアクセス可能であることを確認するために行われます。一般的なウェブアクセシビリティテストには次のようなものがあります。

• フォントと背景色のコントラストが適切であることを確認する
• フォントサイズ
• マルチメディアコンテンツの代替テキスト
• マウスに加えて、コンピューターのキーボードを使用してシステムを操作できる機能。

機密データを処理するソフトウェアにとって、セキュリティテストはハッカーによるシステム侵入を防ぐために不可欠です。

国際標準化機構（ISO）はこれを「試験対象物および関連するデータと情報が、権限のない人物やシステムが使用、読み取り、または変更できないように保護され、権限のある人物やシステムがそれらへのアクセスを拒否されない程度を評価するために実施される試験の一種」と定義している。^{[ 67 ]}

国際化およびローカライズのテストは、ソフトウェアがさまざまな言語や地域で使用できることを検証するものです。擬似ローカライズのプロセスは、アプリケーションが別の言語に翻訳できるかどうかをテストし、ローカライズプロセスによって製品に新たなバグが発生する可能性がある場合を容易に特定するために使用されます。

グローバル化テストでは、ソフトウェアが異なる通貨やタイムゾーンなどの新しい文化に適応していることを検証します。^{[ 68 ]}

実際の人間言語への翻訳もテストする必要があります。ローカライズおよびグローバリゼーションの失敗例としては、以下のようなものが考えられます。

• 一部のメッセージは翻訳されていない場合があります。
• ソフトウェアのローカライズは、文脈を無視した文字列のリストを翻訳することによって行われることが多いが、翻訳者は曖昧な原文文字列に対して誤った翻訳を選択してしまう可能性がある。
• 複数の人が適切な連携なしに翻訳を行った場合、あるいは翻訳者が不注意な場合、専門用語に一貫性がなくなる可能性があります。
• 逐語訳は、翻訳先の言語では不適切、不自然、あるいは専門的すぎるように聞こえる可能性がある。
• 元の言語で書かれた未翻訳のメッセージは、ソースコードにハードコーディングされている場合があり、そのため翻訳できない可能性があります。
• 一部のメッセージは実行時に自動的に生成される場合があり、その結果生成される文字列は文法的に誤りがあったり、機能的に不正確であったり、誤解を招くものであったり、混乱を招くものであったりする可能性があります。
• ソフトウェアによっては、ソース言語のキーボードレイアウトでは機能しないキーボードショートカットを使用する場合があります。しかし、ターゲット言語のレイアウトでは、そのショートカットを使用して文字を入力することができます。
• ソフトウェアが対象言語の文字コードに対応していない場合があります。
• 原文言語で適切なフォントやフォントサイズが、翻訳先言語では不適切な場合があります。例えば、CJK文字はフォントが小さすぎると判読できなくなる可能性があります。
• 対象言語の文字列が、ソフトウェアが処理できる長さを超える場合があります。その結果、文字列の一部がユーザーに表示されなかったり、ソフトウェアがクラッシュしたり、誤動作したりする可能性があります。
• ソフトウェアによっては、双方向テキストの読み書きを適切にサポートしていない場合があります。
• ソフトウェアによっては、ローカライズされていないテキストを含む画像を表示する場合があります。
• ローカライズされたオペレーティングシステムでは、システム構成ファイルや環境変数の名前が異なったり、日付や通貨の形式が異なったりする場合があります。

開発テストは、ソフトウェア開発におけるリスク、時間、コストを削減するために、幅広い欠陥防止および検出戦略を同期的に適用するソフトウェア開発プロセスです。これは、ソフトウェア開発ライフサイクルの構築フェーズにおいて、ソフトウェア開発者またはエンジニアによって実施されます。開発テストの目的は、コードが他のテスト段階に進む前に構築エラーを排除することです。この戦略は、結果として得られるソフトウェアの品質向上と、開発プロセス全体の効率化を目指しています。

組織のソフトウェア開発に対する期待に応じて、開発テストには、静的コード分析、データフロー分析、メトリクス分析、ピアコードレビュー、単体テスト、コードカバレッジ分析、トレーサビリティ、その他のソフトウェアテスト手法が含まれる場合があります。

A/Bテストとは、提案された変更が既存の方法よりも効果的かどうかを判断するために、管理された実験を実施する手法です。顧客は、機能の現行バージョン（コントロール群）または変更されたバージョン（トリートメント群）のいずれかに誘導され、どちらのバージョンが望ましい結果を達成するのに適しているかを判断するためにデータが収集されます。

並行処理テストは、通常の使用条件下で、並行コンピューティングを使用するソフトウェアおよびシステムの動作とパフォーマンスを評価するものです。この種のテストで明らかになる典型的な問題としては、デッドロック、競合状態、共有メモリ／リソース処理に関する問題などが挙げられます。

ソフトウェアテストにおいて、適合性テストは、製品が規定された基準に従って動作するかどうかを検証するものです。例えば、コンパイラは、その言語の標準規格を満たしているかどうかを判断するために、広範なテストを受けます。

テキストのデータ比較や UI のスクリーンショット^など、期待される出力を表示することは、^{スナップショット テストまたはゴールデンマスター テストと呼ばれることもあります。他}の多くのテスト形式とは異なり、これは障害を自動的に検出することはできず、代わりに人間が出力の不整合を評価する必要があります。[ 3 ] : 195

プロパティテストとは、特定の入力に対して特定の期待される出力が得られることを主張するのではなく、多数の入力をランダムに生成し、それらすべてに対してプログラムを実行し、入力と出力のすべてのペアに対して真であるべき「プロパティ」の真偽を主張するテスト手法です。例えば、シリアライゼーション関数からのすべての出力は、対応するデシリアライゼーション関数によって受け入れられるべきであり、ソート関数からのすべての出力は、入力とまったく同じ要素を含む単調増加するリストであるべきです。

プロパティテストライブラリを使用すると、ユーザーはランダム入力の構築方法を制御でき、特殊なケースや、テスト対象の実装の側面を完全に実行するために必要な特定のパターンを持つ入力を確実に網羅できます。

プロパティテストは、HaskellライブラリのQuickCheckによって導入され普及したため、「生成テスト」または「QuickCheckテスト」とも呼ばれることがある。^{[ 69 ]}

メタモルフィックテスト（MT）は、プロパティベースのソフトウェアテスト手法であり、テストオラクル問題とテストケース生成問題に対処するための効果的なアプローチとなり得る。テストオラクル問題とは、選択されたテストケースの期待される結果を決定すること、あるいは実際の出力が期待される結果と一致するかどうかを判断することの難しさを指す。

VCRテスト（「再生テスト」または「録画/再生テスト」とも呼ばれる）は、通信が遅い、または信頼性の低いコンポーネント（多くの場合、テスターの制御範囲外にあるサードパーティAPI）を含む回帰テストの信頼性と速度を向上させるためのテスト手法です。この手法では、システムと外部コンポーネントとのやり取りを録画（「カセット」）し、その後のテスト実行時に、録画したやり取りを外部システムとの通信の代替として再生します。

この技術は、RubyライブラリのvcrによってWeb開発で普及しました。

契約テストは、前述の法的動機に基づく契約受入テストと混同してはならないが、2 つのソフトウェア サービス間の統合ポイントをテストする手法であり、各サービス間で送信される要求と応答が、一般的に契約と呼ばれる共通の期待値セットに準拠しているかどうかを確認することによって行われる。これは、分散システム、サービス指向ソフトウェア アーキテクチャ、マイクロ サービスのコンテキストでよく使用される。^{[ 70 ] [ 71 ]}

2020年代初頭から、人工知能はソフトウェアテストのワークフローにますます統合されるようになりました。AI駆動のテスト手法は、テストケースの作成を自動化し、変更に動的に適応し、機械学習を活用してコードベースの高リスク領域を特定します。このアプローチは、回帰テストの効率を高めながら、テストの全体的なカバレッジを拡大します。^{[ 72 ]}

重要な進展の一つは、自己修復型テスト自動化です。これは、自動化されたテストが人間の介入なしにユーザーインターフェイスの変更を自動的に検知し、適応するものです。3,600を超えるグレー文献ソースを対象としたAI駆動型テスト自動化の研究では、自己修復型テストスクリプトが、実際に最も一般的なAIソリューションの一つであることが明らかになりました。^{[ 73 ]}

ACM Computing Surveys (2023)に掲載された三次研究では、AI 手法がソフトウェア開発ライフサイクルのすべての主要なフェーズで広く適用されていることがわかり、テストケース生成、障害予測、自動修復が AI 支援テスト研究の 3 つの最も活発な分野であると特定されました。^{[ 74 ]}

シフトレフトテストとは、ソフトウェア開発ライフサイクルのできるだけ早い段階でテスト活動を統合し、欠陥を修正するコストが最も低い段階で検出できるようにする手法です。この用語は、学術文献であるDr. Dobb's Journalで初めて記述され、その後のACM / IEEEの研究で体系化されました。^{[ 75 ]}

実証研究では、開発の初期段階で欠陥を発見した場合、テストを後の段階に延期する従来のアプローチと比較して、シフトレフトテストによって欠陥の検出にかかる時間が40～60%短縮され、欠陥の除去コストが75～85%削減されることが実証されています。^{[ 76 ]}

2023年の国際情報管理技術会議（ICIMTech）で発表されたケーススタディでは、シフトレフトテストをアジャイル開発手法に1年間統合することで、本番環境に到達するバグの数が大幅に減少したことが明らかになった。^{[ 77 ]}

組織内では、テスターはソフトウェア開発チームとは別のチームに所属する場合もあれば、同じチームに統合される場合もある。また、ソフトウェアテストは、専任のソフトウェアテスターではない人によって実施されることもある。

1980年代には、 「ソフトウェアテスター」という言葉が独立した職業を指す言葉として使われるようになった。

ソフトウェアテストの代表的な役割と肩書きには、テストマネージャー、テストリーダー、テストアナリスト、テストデザイナー、テスター、自動化開発者、テスト管理者などがあります。^{[ 78 ] [ 79 ]}

ソフトウェアを開発する組織は、テストの実施方法が異なりますが、共通のパターンがあります。^{[ 2 ]}

ソフトウェアテストは検証および妥当性確認と併せて使用されます。^{[ 85 ]}

• 検証：ソフトウェアは正しく構築されているか？（つまり、要件を満たしているか？）
• 検証：我々は適切なソフトウェアを構築したか？（つまり、成果物は顧客のニーズを満たしているか？）

検証と妥当性確認という用語は業界では一般的に同義語として使われており、また、これら2つの用語が矛盾する定義で使われていることもよくあります。IEEE^{ソフトウェア}エンジニアリング用語標準用語集^{[ 12 ]} : ^{80-81によると}

検証とは、システムまたはコンポーネントを評価し、特定の開発段階の成果物が、その段階の開始時に課せられた条件を満たしているかどうかを判断するプロセスである。

検証とは、開発プロセスの途中または終了時に、システムまたはコンポーネントが規定された要件を満たしているかどうかを評価するプロセスである。

また、ISO 9000規格によれば、次のようになります。

検証とは、検査および客観的な証拠の提供を通じて、指定された要件が満たされていることを確認することである。

検証とは、検査および客観的な証拠の提供を通じて、特定の意図された用途またはアプリケーションに対する要件が満たされていることを確認することである。

この矛盾は、要求事項と特定要求事項という概念が異なる意味で用いられていることに起因する。

IEEE規格の場合、検証の定義で言及されている要件とは、ソフトウェアが解決し満たさなければならない利害関係者の問題、ニーズ、要望の集合です。このような要件は、ソフトウェア要件仕様書（SRS）に文書化されます。また、検証の定義で言及されている成果物とは、ソフトウェア開発プロセスの各フェーズの出力成果物です。これらの成果物は、実際には、アーキテクチャ設計仕様書、詳細設計仕様書などの仕様書です。SRSも仕様書ですが、検証することはできません（少なくともここで使用されている意味では。この点については後述します）。

しかし、ISO 9000 の場合、規定された要求事項は、前述のとおり、検証しなければならない仕様のセットです。仕様は、前述のとおり、別の仕様を入力として受け取るソフトウェア開発プロセスのフェーズの成果物です。仕様は、入力仕様を正しく実装したときに正常に検証されます。SRS は最初の仕様であるため、それ以外のすべての仕様を検証できます（ただし、妥当性確認は可能です）。例えば、設計仕様は SRS を実装する必要があり、構築フェーズの成果物は設計仕様を実装する必要があります。

つまり、これらの言葉を一般的な用語で定義すると、見かけ上の矛盾は解消される。

SRSとソフトウェアの両方を検証する必要があります。SRSは、関係者と協議することで静的に検証できます。しかし、ソフトウェアの一部実装やプロトタイプ（動的テスト）を実行し、関係者から肯定的なフィードバックを得ることで、SRSが正しく策定されているという確信をさらに高めることができます。一方、ソフトウェアは、最終的な実行可能な製品（ソースコードなどの成果物やドキュメントではなく）であるため、関係者にソフトウェアを実行して試用してもらうことで、動的に検証する必要があります。

SRS（ソフトウェア要件仕様書）の場合、入力はステークホルダーの言葉であるため、SRSの妥当性確認と検証は同じであると主張する人もいるかもしれません。しかし、このような考え方は混乱を招くだけなのでお勧めできません。検証とは、正式な技術文書を入力とするプロセスであると考える方が適切です。

一部の組織では、ソフトウェア テストはソフトウェア品質保証(SQA) プロセスの一部です。 ^{[ 3 ] : 347} SQA では、ソフトウェア プロセス スペシャリストと監査担当者は、ドキュメント、コード、システムなどの成果物だけでなく、ソフトウェア開発プロセスに関心を持ちます。彼らは、納品されるソフトウェアに最終的に含まれる欠陥の数、いわゆる欠陥率を減らすために、ソフトウェア エンジニアリングプロセス自体を検証し、変更します。許容される欠陥率が何であるかは、ソフトウェアの性質によって異なります。フライト シミュレーター ビデオゲームは、実際の飛行機用のソフトウェアよりもはるかに高い欠陥許容度を持ちます。SQA と密接な関係がありますが、テスト部門は独立して存在することが多く、一部の企業では SQA 機能が存在しない場合があります。

ソフトウェアテストとは、テスト対象のソフトウェアを調査し、関係者に品質に関する情報を提供する活動です。一方、QA（品質保証）とは、欠陥のあるソフトウェアが顧客に届くのを防ぐためのポリシーと手順を実施することです。

品質測定には、正確性、完全性、セキュリティなどのトピックや、ISO/IEC 9126の要求事項である機能性、信頼性、効率性、移植性、保守性、互換性、ユーザビリティなどが含まれます。

ソフトウェアの状態やテストの妥当性を判断するのに役立つ、頻繁に使用されるソフトウェアメトリクス（指標）が数多く存在する。

ソフトウェアテストプロセスでは、複数の成果物が生成される可能性がある。実際に生成される成果物は、使用されるソフトウェア開発モデル、利害関係者、および組織のニーズによって左右される。

ソフトウェアテスターや品質保証スペシャリストのキャリア目標を支援するための認定プログラムはいくつか存在する。しかし、論争の項で述べたように、テスト分野はまだ認定制度を受け入れる準備ができていないと主張する実務家も少数ながら存在する。