ソフトウェアテスト

TestingCup – ポーランドのソフトウェアテスト選手権、カトヴィツェ、2016年5月

ソフトウェア テストは、ソフトウェアが意図した目的を達成し、期待を満たしている かどうかを確認する行為です。

ソフトウェアテストは、ソフトウェアの品質と障害のリスクに関する客観的で独立した情報を、ユーザーやスポンサー、その他の利害関係者に提供することができます。 [ 1 ]

ソフトウェアテストは特定のシナリオにおけるソフトウェアの正しさを判断できますが、すべてのシナリオにおける正しさを判断することはできません。[ 2 ] [ 3 ]すべてのバグを見つけることはできません。

ソフトウェアテストでは、オラクルから得られる正確性を測定する基準に基づいて、問題を認識する可能性のある原則とメカニズムを採用します。オラクルの例としては、仕様、契約、[ 4 ]比較対象製品、同一製品の過去のバージョン、意図された目的または期待される目的に関する推論、ユーザーまたは顧客の期待、関連する標準、適用法などが挙げられます。

ソフトウェア テストは、本質的に機能的なものでも非機能的なものでもかまいません。

ソフトウェアテストは、多くの場合、動的な性質を持ちます。つまり、ソフトウェアを実行して実際の出力が期待通りであることを確認します。また、静的な性質を持つ場合もあります。つまり、コードと関連ドキュメントをレビューするのです。

ソフトウェア テストは、多くの場合、「ソフトウェアは想定された動作と必要な動作を実行しているか?」という質問に答えるために使用されます。

ソフトウェアテストから得られた情報は、ソフトウェア開発プロセスの改善に活用できる可能性がある。[ 5 ]：41–43

自動テストの一般的なアプローチは「テストピラミッド」であり、テストの大部分は単体テストであり、次に少数の統合テスト、最後にエンドツーエンド（e2e）テストが続く。[ 6 ] [ 7 ] [ 8 ]

経済

2002年にNISTが実施した調査によると、ソフトウェアのバグは米国経済に年間595億ドルの損失をもたらしていると報告されています。ソフトウェアテストをより適切に実施すれば、このコストの3分の1以上を回避できる可能性があります。[ 9 ]

コスト面からソフトウェアテストをアウトソーシングすることは非常に一般的であり、中国、フィリピン、インド、パキスタンが好まれる目的地となっている。[ 10 ]

歴史

グレンフォード・J・マイヤーズは1979年に初めてデバッグとテストの分離を導入した。[ 11 ]彼の注目は破損テスト（「成功するテストケースとは、まだ発見されていないエラーを検出するテストケースである。」[ 11 ]：16 ）にあったが、それはソフトウェアエンジニアリングコミュニティがデバッグなどの基本的な開発活動を検証活動から分離したいという願望を示した。ソフトウェアテストには通常、ソフトウェアのバグ（望ましくない結果を引き起こすコードの欠陥）の処理が含まれる。 [ 12 ]：31 バグは一般にテストの進行を遅らせ、デバッグと修正にプログラマーの支援を必要とする。

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

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

目標

ソフトウェア テストは通常​​、目標主導で行われます。

バグを見つける

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

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

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

1 つの欠陥によって複数の障害症状が発生する可能性があります。

要件が満たされていることを確認する

ソフトウェアテストには、要件のギャップ（設計から要件が漏れている）が含まれる場合があります。[ 5 ]：426 要件のギャップは、テスト可能性、スケーラビリティ、保守性、パフォーマンス、セキュリティなどの非機能要件であることが多いです。

コードカバレッジ

ソフトウェアテストの根本的な限界は、単純な製品であっても、あらゆる入力と前提条件（初期状態）の組み合わせでテストを行うことが不可能であるということです。 [ 3 ] : 17–18 [ 15 ] 異常な状況で発生する欠陥は、テストでは発見が困難です。また、品質の非機能的側面（あるべき姿と、本来の機能） ――ユーザビリティ、スケーラビリティ、パフォーマンス、互換性、信頼性――は主観的になりがちです。ある人にとって十分な価値を構成するものが、別の人にとってはそうではないこともあります。

あらゆる入力をテストすることは現実的ではありませんが、テストでは組み合わせ論を使用してカバレッジを最大化し、テストを最小限に抑えることができます。[ 16 ]

カテゴリー

テストは様々な方法で分類することができます。[ 17 ]

自動テスト

テスト自動化とは、テストの実行を制御し、実際の結果と予測結果を比較するためにソフトウェア（テスト対象のソフトウェアとは別）を使用することです。 [ 18 ]テスト自動化は、手動操作なしでテスト対象システム（SUT）のテストをサポートし、テスト実行の高速化とテスト頻度の向上につながります。テスト自動化は継続的テストの重要な側面であり、継続的インテグレーションと継続的デリバリー（CI/CD）にもしばしば用いられます。[ 19 ]

レベル

ソフトウェアテストは、ソフトウェアシステムのどの程度がテストの焦点となるかによってレベルに分類できます。[ 20 ] [ 21 ] [ 22 ] [ 23 ]

ユニットテスト

ユニットテスト（コンポーネントテストまたはモジュールテストとも呼ばれる）は、分離されたソースコードをテストして期待される動作を検証するソフトウェアテストの一種です。 [ 24 ]

統合テスト

統合テストは、複数のソフトウェアコンポーネント、モジュール、またはサービスをまとめてテストし、組み合わせた際に期待どおりに動作することを確認するソフトウェアテストの一種です。コンポーネントを個別にテストするのではなく、統合された部分間の相互作用とデータ交換をテストすることに重点が置かれます。

システムテスト

システム テスト、別名エンドツーエンド (E2E) テストは、完全なソフトウェア システムに対して実行されるテストです。

静的、動的、受動的なテスト

ソフトウェアテストには多くのアプローチがあります。レビュー、ウォークスルー、検査などは静的テストと呼ばれ、与えられたテストケースセットを用いてプログラムされたコードを実行することは動的テストと呼ばれます。[ 25 ] [ 26 ]

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

静的テストには検証が含まれますが、動的テストには検証も含まれます。[ 26 ]

パッシブテストとは、ソフトウェア製品とのやり取りを一切行わずにシステムの動作を検証することを意味します。アクティブテストとは異なり、テスターはテストデータを提供せず、システムログとトレースを参照します。テスターはパターンや特定の動作を探し出し、何らかの判断を下します。[ 27 ]これは、オフライン実行時検証やログ分析に関連しています。

探索的

探索的テストとは、ソフトウェアテストのアプローチの一種であり、簡潔には学習、テスト設計、テスト実行の同時進行と説明されます。1984年にこの用語を造語したCem Kaner氏[ 28 ]は、探索的テストを「テスト関連の学習、テスト設計、テスト実行、そしてテスト結果の解釈を、プロジェクト全体を通して並行して実行される相互に補完的な活動として捉えることで、個々のテスターが自身の作業品質を継続的に最適化できるよう、個人の自由と責任を重視するソフトウェアテストのスタイル」と定義しています。[ 29 ]

プリセットテストと適応型テスト

実行されるテスト戦略のタイプは、IUTに適用されるテストをテスト計画の実行開始前に決定する必要があるかどうか（プリセットテスト[ 30 ]）、またはIUTに適用される各入力が以前のテストの適用中に得られた出力に動的に依存できるかどうか（適応型テスト[ 31 ] [ 32 ]）によって異なります。

黒/白のボックス

ソフトウェアテストは、ホワイトボックスとブラックボックスの2つに分けられることが多い。これら2つのアプローチは、テスト担当者がテストケースを設計する際に用いる視点を表すために用いられる。また、両方のボックスの側面を取り入れたグレーボックスと呼ばれるハイブリッドなアプローチも、ソフトウェアテスト方法論に適用されることがある。[ 33 ] [ 34 ]

ホワイトボックステスト

ホワイトボックステスト図
ホワイトボックステスト図

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

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

ホワイトボックステストで使用される手法には以下のものがある: [ 34 ] [ 36 ]

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

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

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

ブラックボックステスト

ブラックボックス図

ブラックボックステスト（機能テストとも呼ばれる）とは、実装に関する知識やソースコードを読まずにテストケースを設計することを指します。テスターはソフトウェアが何をすべきかは理解しますが、どのように動作するかは理解しません。[ 40 ]ブラックボックステストの手法には、同値分割法、境界値分析、全ペアテスト、状態遷移表、決定表テスト、ファズテスト、モデルベーステスト、ユースケーステスト、探索的テスト、仕様ベーステストなどがあります。[ 33 ] [ 34 ] [ 38 ]

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

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

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

コンポーネント・インターフェース・テストはブラックボックス・テストの一種であり、サブシステム・コンポーネントの関連アクションだけでなく、データ値にも焦点を当てています。[ 43 ]コンポーネント・インターフェース・テストは、様々なユニット、あるいはサブシステム・コンポーネント間で渡されるデータの処理を、それらのユニット間の完全な統合テストを超えてチェックするために使用できます。[ 44 ] [ 45 ]渡されるデータは「メッセージ・パケット」と見なすことができ、あるユニットから生成されたデータの範囲やデータ型をチェックし、別のユニットに渡す前に妥当性をテストすることができます。インターフェース・テストの選択肢の一つは、渡されるデータ項目のログファイルを別途作成することです。このログファイルには、数日または数週間にわたってユニット間で渡される数千件のデータケースを分析できるように、タイムスタンプが記録されることがよくあります。テストには、他のインターフェース変数が通常の値として渡されている間に、一部の極端なデータ値の処理をチェックすることが含まれます。[ 44 ]インターフェース内の異常なデータ値は、次のユニットで予期しないパフォーマンスが発生する原因を説明するのに役立ちます。

視覚テスト

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

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

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

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

グレーボックステスト

グレーボックステスト（アメリカ式綴り：gray-box testing）は、テスト設計を目的として内部データ構造とアルゴリズムに関する知識を活用し、それらのテストをユーザーレベル、つまりブラックボックスレベルで実行します。テスターは多くの場合、「ソースコードと実行バイナリ」の両方にアクセスできます。[ 49 ]グレーボックステストには、境界値やエラーメッセージなどを特定するためのリバースエンジニアリング（動的コード解析を使用）も含まれる場合があります。 [ 49 ]入力データの操作や出力のフォーマットは、入力と出力がテスト対象システムと呼ばれる「ブラックボックス」の外部にあるため、グレーボックステストとはみなされません。この区別は、 2人の異なる開発者によって作成された2つのコードモジュール間の統合テストを行う場合、特に重要です。この場合、テストにはインターフェースのみが公開されます。

ソフトウェアの動作原理を理解することで、テスターはソフトウェアを外部からテストする際に、より適切なテストの選択を行うことができます。通常、グレーボックステスターは、データベースへのシードなどのアクティビティを含む、隔離されたテスト環境を構築することが許可されます。テスターは、データベースに対してSQL文を実行し、その後クエリを実行するなどの特定のアクションを実行した後、テスト対象製品の状態を観察し、期待される変更が反映されていることを確認することができます。グレーボックステストは、限られた情報に基づいてインテリジェントなテストシナリオを実装します。これは特に、データ型の処理、例外処理などに適用されます。[ 50 ]

グレーボックステストの概念により、ブラックボックステストとホワイトボックステストの間のこの「恣意的な区別」はいくぶん薄れてきました。[ 35 ]

インストールテスト

ほとんどのソフトウェアシステムには、本来の目的で使用する前に必要なインストール手順があります。これらの手順をテストして、使用可能なインストール済みソフトウェアシステムを実現することをインストールテストと呼びます。[ 51 ]：139 これらの手順には、完全または部分的なアップグレード、およびインストール/アンインストールのプロセスが含まれる場合があります。

  • ユーザーはさまざまなオプションを選択する必要があります。
  • 依存ファイルとライブラリを割り当て、ロード、または配置する必要があります。
  • 有効なハードウェア構成が存在している必要があります。
  • ソフトウェアシステムは他のソフトウェアシステムに接続するために接続性を必要とする場合がある。[ 51 ]：145

互換性テスト

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

スモークテストとサニティテスト

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

スモークテストは、ソフトウェアを最小限の操作で動作させ、動作を妨げるような基本的な問題がないかを確認することを目的としています。このようなテストは、ビルド検証テストとして使用できます。

回帰テスト

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

回帰テストの一般的な方法には、以前のテストケースセットを再実行し、以前に修正された障害が再発していないかどうかを確認することが含まれます。テストの深さは、リリースプロセスの段階と追加機能のリスクによって異なります。リリースの後半で追加された変更やリスクが高いと判断された変更については、完全なテストを実施します。一方、リリースの初期段階で追加された変更やリスクが低いと判断された変更については、各機能に対する肯定的なテストのみで構成される非常に浅いテストを実施します。

受け入れテスト

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

受け入れテストは、開発の任意の 2 つのフェーズ間の引き継ぎプロセスの一部として実行できます。

テストは、ソフトウェア開発プロセスの中で実行される場所やテストの特殊性のレベルによって、これらのレベルにグループ化されることが多い。[ 56 ]

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

場合によっては、UAT は顧客自身の環境とハードウェア上で顧客によって実行されることもあります。

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

さらに、ソフトウェアテストでは、システムの移植性が期待通りに機能するだけでなく、動作環境に損傷を与えたり部分的に破壊したり、その環境内の他のプロセスが動作しなくなったりしないことを確認する必要があります。[ 57 ]

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

アルファテスト

アルファテストとは、潜在的なユーザー／顧客、または開発者のサイトで独立したテストチームによって行われる、シミュレーションまたは実際の運用テストです。アルファテストは、市販ソフトウェアがベータテストに進む前の社内受け入れテストとしてよく使用されます。[ 58 ]

ベータテスト

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

機能テストと非機能テスト

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

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

継続的テスト

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

破壊試験

破壊的テストは、ソフトウェアまたはサブシステムに障害を発生させることを試みます。無効または予期しない入力を受け取った場合でもソフトウェアが正常に機能することを検証し、入力検証およびエラー管理ルーチンの堅牢性を確立します。ファジングと呼ばれるソフトウェアフォールトインジェクションは、障害テストの一例です。ソフトウェアフォールトインジェクションのページには、様々な市販の非機能テストツールへのリンクがあります。また、破壊的テストを実行できるオープンソースおよび無料のソフトウェアツールも多数あります。

ソフトウェアパフォーマンステスト

パフォーマンステストは通常​​、特定のワークロードにおけるシステムまたはサブシステムの応答性と安定性を評価するために実行されます。また、スケーラビリティ、信頼性、リソース使用率など、システムのその他の品質特性を調査、測定、検証、または確認するためにも使用されます。

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

パフォーマンステストの具体的な目標については、ほとんど合意が得られていません。負荷テスト、パフォーマンステスト、スケーラビリティテスト、ボリュームテストという用語は、しばしば同じ意味で使用されます。

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

ユーザビリティテスト

ユーザビリティテストは、ユーザーインターフェースが使いやすく理解しやすいかどうかを確認するためのものです。主にアプリケーションの使用に焦点を当てています。これは自動化できるテストではなく、熟練したUIデザイナーの監視下で実際に人間が操作する必要があります。ユーザビリティテストでは、構造化されたモデルを用いてインターフェースの動作を確認することができます。Stanton、Theofanos、Joshi (2015) のモデルはユーザーエクスペリエンスに焦点を当てており、Al-SharafatとQadoumi (2016) のモデルは専門家による評価を目的としており、デジタルアプリケーションのユーザビリティ評価に役立ちます。[ 64 ]

アクセシビリティテスト

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

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

コンプライアンスの共通基準

セキュリティテスト

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

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

国際化とローカリゼーション

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

グローバリゼーションテストでは、ソフトウェアが異なる通貨やタイムゾーンなどの新しい文化に適応しているかどうかを検証します。[ 66 ]

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

開発テスト

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

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

A/Bテスト

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

同時テスト

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

適合性試験または型式試験

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

出力比較テスト

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

特性試験

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

プロパティ テスト ライブラリを使用すると、ユーザーはランダム入力を構築する戦略を制御し、縮退したケースや、テスト対象の実装の側面を完全に実行するために必要な特定のパターンを特徴とする入力をカバーできるようになります。

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

変成岩試験

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

VCRテスト

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

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

契約テスト

契約テスト（前述の法的根拠に基づく契約受入テストと混同しないよう注意すべきである）は、任意の2つのソフトウェアサービス間の統合ポイントをテストする方法論であり、各サービス間で送信されるリクエストとレスポンスが、一般的に契約と呼ばれる共通の期待事項に準拠しているかどうかを確認することによって行われる。これは、分散システム、サービス指向ソフトウェアアーキテクチャ、マイクロサービスの文脈でよく使用される。[ 68 ] [ 69 ]

チームワーク

役割

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

1980 年代には、 「ソフトウェア テスター」という用語は、独立した職業を指すために使われるようになりました。

注目すべきソフトウェアテストの役割とタイトルには、次のものがあります。[ 70 ]テストマネージャー、テストリーダー、テストアナリスト、テスト設計者、テスター、自動化開発者、テスト管理者。[ 71 ]

プロセス

ソフトウェアを開発する組織はそれぞれ異なる方法でテストを実行しますが、共通のパターンがあります。[ 2 ]

ウォーターフォール開発

ウォーターフォール開発では、テストは通常​​、コードが完成した後、製品が顧客に出荷される前に実行されます。[ 72 ]この方法では、プロジェクトの遅延を補うためにテストフェーズがプロジェクトのバッファーとして使用されることが多く、テストに費やされる時間が損なわれることになります。[ 11 ] : 145–146

ウォーターフォールプロセスでは、開発プロジェクトの開始時にテストを開始し、プロジェクトが終了するまで継続的なプロセスにすることができると主張する人もいます。[ 73 ]

アジャイル開発

アジャイル ソフトウェア開発では、通常、コードの記述中にテストを実行し、プログラマーとテスターの両方でチームを編成し、チーム メンバーがプログラミングとテストの両方を実行します。

アジャイル開発の実践方法の一つであるテスト駆動ソフトウェア開発（TDD）は、製品コードの作成と並行してユニットレベルのテストを実行するユニットテスト手法です。 [ 74 ]テストコードは、新機能の追加や障害発生時の発見（バグ修正）に応じて更新されます。通常、ユニットテストコードはプロジェクトコードと共に保守され、ビルドプロセスに統合され、各ビルドで実行され、回帰テストの一部としても実行されます。この継続的インテグレーションの目的は、開発を支援し、欠陥を削減することです。[ 75 ] [ 74 ]

プログラミングとテストの機能ごとにチームを分けている組織でも、多くの場合、プログラマーがユニットテストを実行します。[ 76 ]

サンプルプロセス

以下のサンプルはウォーターフォール開発によく見られます。他の開発モデルでも同じアクティビティが見られますが、記述方法が異なる場合があります。

  • 要件分析：テストはソフトウェア開発ライフサイクルの要件フェーズから開始する必要があります。設計フェーズでは、テスターは設計のどの側面がテスト可能か、そしてどのようなパラメータでテストが機能するかを判断します。
  • テスト計画：テスト戦略、テスト計画、テストベッドの作成。テスト中には多くのアクティビティが実行されるため、計画が必要です。
  • テスト開発:ソフトウェアのテストで使用するテスト手順、テスト シナリオ、テスト ケース、テスト データセット、テスト スクリプト。
  • テスト実行：テスターは計画とテストドキュメントに基づいてソフトウェアを実行し、発見されたエラーを開発チームに報告します。プログラミングの知識が不足している場合、この部分は複雑になる可能性があります。
  • テスト レポート: テストが完了すると、テスターはメトリックを生成し、テストの取り組みとテストされたソフトウェアがリリースの準備ができているかどうかに関する最終レポートを作成します。
  • テスト結果分析: または欠陥分析は、通常、開発チームがクライアントと一緒に実行し、どの欠陥を割り当てるか、修正するか、拒否するか (つまり、ソフトウェアが適切に動作していることがわかった場合)、または後で対処するために延期するかを決定します。
  • 欠陥の再テスト: 開発チームによって欠陥が処理されると、テストチームによって再テストされます。
  • 回帰テスト: 最新の配信によって何も損なわれておらず、ソフトウェア製品全体が正しく動作していることを確認するために、新規、変更、または修正されたソフトウェアの各統合ごとに、テストのサブセットで構築された小さなテスト プログラムを使用するのが一般的です。
  • テストの終了: テストが終了基準を満たすと、主要な出力、学んだ教訓、結果、ログ、プロジェクトに関連するドキュメントのキャプチャなどのアクティビティがアーカイブされ、将来のプロジェクトの参照として使用されます。

品質

ソフトウェアの検証と検証

ソフトウェアテストは検証と妥当性確認と関連して使用される：[ 77 ]

  • 検証: ソフトウェアは正しく構築されていますか? (つまり、要件を実装していますか)。
  • 検証: 適切なソフトウェアを構築しましたか? (つまり、成果物は顧客を満足させるものですか)。

検証と妥当性確認という用語は、業界では一般的に互換的に使用されています。また、これら2つの用語が矛盾した定義で定義されていることもよくあります。IEEE標準ソフトウェア工学用語集によると：[ 12 ]：80–81

検証とは、特定の開発フェーズの製品がそのフェーズの開始時に課された条件を満たしているかどうかを判断するために、システムまたはコンポーネントを評価するプロセスです。
検証とは、開発プロセス中または開発プロセスの最後にシステムまたはコンポーネントを評価し、指定された要件を満たしているかどうかを判断するプロセスです。

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

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

この矛盾は、要件と指定要件とい​​う概念が異なる意味で使用されることによって発生します。

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

しかし、ISO 9000の場合、規定された要件とは、前述の通り、検証が必要となる一連の仕様を指します。仕様とは、前述の通り、ソフトウェア開発プロセスの各フェーズで生成される成果物であり、別の仕様を入力として受け取ります。仕様は、入力された仕様を正しく実装することで検証に成功します。SRSは最初の仕様であるため、SRSを除くすべての仕様を検証できます（ただし、SRSは検証可能です）。例えば、設計仕様はSRSを実装する必要があり、構築フェーズの成果物は設計仕様を実装する必要がある、といった状況が考えられます。

したがって、これらの単語を共通の用語で定義すると、明らかな矛盾は消えます。

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

SRSの場合、入力はステークホルダーの言葉であり、したがってSRSの妥当性確認とSRSの検証は同じであると主張する人もいるかもしれません。しかし、そのような考え方は混乱を招くだけなので、推奨されません。検証は、正式かつ技術的な入力文書を伴うプロセスであると考える方が適切です。

ソフトウェア品質保証

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

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

対策

品質測定には、正確性、完全性、セキュリティなどのトピックや、機能、信頼性、効率性、移植性、保守性、互換性、使いやすさなどのISO/IEC 9126要件が含まれます。

ソフトウェアの状態やテストの適切性を判断するのに役立つ、 頻繁に使用されるソフトウェア メトリック(測定基準)が多数あります。

遺物

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

テスト計画

テスト計画とは、意図されたテスト活動に対して取られるアプローチを詳述した文書である。計画には、目的、範囲、プロセスと手順、人員要件、緊急時対応計画などの側面が含まれる場合がある。[ 53 ]テスト計画は、すべてのテストタイプ（受け入れテスト計画やシステムテスト計画など）と計画上の考慮事項を含む単一の計画の形で提供される場合もあれば、複数の詳細なテスト計画の概要を示すマスターテスト計画（計画の計画）として発行される場合もある。[ 53 ]テスト計画は、全体的なテストアプローチを文書化した広範な「テスト戦略」の一部となる場合もあり、それ自体がマスターテスト計画である場合もあれば、独立した成果物である場合もある。

トレーサビリティマトリックス

ソフトウェア開発において、トレーサビリティマトリクス（TM）[ 78 ] : 244 は、通常表形式の文書であり、多対多の関係比較を使用して任意の2つのベースライン文書を相関させることで、関係の完全性を判断するのに役立ちます。 [ 78 ] : 3–22 これは、製品の高レベル要件（多くの場合、マーケティング要件で構成されている）と詳細要件を、高レベル設計、詳細設計、テスト計画、テストケースの対応する部分に使用することがよくあります。

テストケース

テストケースは通常、一意の識別子、設計仕様書からの要件参照、前提条件、イベント、実行する一連の手順（アクションとも呼ばれる）、入力、出力、期待される結果、そして実際の結果で構成されます。臨床的に定義すると、テストケースは入力と期待される結果です。[ 79 ]これは「条件xに対して導出される結果はyです」のように簡潔になることもありますが、通常、テストケースは入力シナリオと期待される結果をより詳細に記述します。テストケースは一連の手順で構成される場合もありますが（多くの場合、手順は複数のテストケースに対して実行できる別のテスト手順に含まれており、これは経済性を考慮しています）、期待される結果または成果は1つです。オプションのフィールドは、テストケースID、テストステップ、または実行順序番号、関連要件、深度、テストカテゴリ、作成者、そしてテストが自動化可能かどうか、また自動化されているかどうかを示すチェックボックスです。大規模なテストケースには、前提条件の状態または手順、および説明が含まれる場合もあります。テストケースには、実際の結果を格納する場所も必要です。これらの手順は、ワードプロセッサ文書、スプレッドシート、データベース、またはその他の一般的なリポジトリに保存できます。データベースシステムでは、過去のテスト結果、結果を生成した人物、その結果を生成するために使用されたシステム構成を確認できる場合もあります。これらの過去の結果は通常、別のテーブルに保存されます。

テストスクリプト

テストスクリプトとは、ユーザーアクションを再現する手順またはプログラミングコードです。当初、この用語は自動回帰テストツールによって作成された成果物に由来していました。テストケースは、ツールまたはプログラムを使用してテストスクリプトを作成するためのベースラインとなります。

テストスイート

ソフトウェア開発において、テストスイート（検証スイートとも呼ばれる）とは、ソフトウェアプログラムをテストし、特定の動作を実行することを示すためのテストケースの集合体です。 [ 80 ]テストスイートには、各テストケースの集合体に関する詳細な指示や目標、およびテスト中に使用されるシステム構成に関する情報が含まれることがよくあります。テストケースのグループには、前提条件となる状態や手順、および後続のテストの説明が含まれる場合もあります。

テストフィクスチャまたはテストデータ

多くの場合、特定の機能の同じ機能をテストするために、複数の値またはデータセットが使用されます。すべてのテスト値と変更可能な環境コンポーネントは別々のファイルに収集され、テストデータとして保存されます。このデータをクライアントや製品、プロジェクトに提供することも有用です。テストデータを生成するための手法はいくつかあります。

テストハーネス

ソフトウェア、ツール、データ入力と出力のサンプル、および構成はすべて、総称してテスト ハーネスと呼ばれます。

試運転

テスト実行とは、ユーザーが実行し、期待される結果と実際の結果を比較する一連のテストケースまたはテストスイートのことです。完了すると、実行されたすべてのテストのレポートが生成されます。

認定資格

ソフトウェアテスターや品質保証スペシャリストの専門職としての志を支援するための認定プログラムがいくつか存在します。論争のセクションで述べたように、テスト分野はまだ認定制度の導入に至っていないと主張する実務家もいます。

論争

ソフトウェア テストに関する主な論争には次のようなものがあります。

アジャイル vs. 従来型
テスターは不確実性と絶え間ない変化の条件下での作業を学ぶべきでしょうか、それともプロセスの「成熟」を目指すべきでしょうか？アジャイルテストの動きは、2000年代初頭から主に商業界で人気が高まってきましたが、[ 81 ] [ 82 ]、政府や軍[ 83 ]ソフトウェアプロバイダーはこの方法論だけでなく、従来のテストラストモデル（ウォーターフォールモデルなど）も使用しています。
手動テストと自動テスト
一部の著者は、テスト自動化はその価値に比べて非常に高価であるため、慎重に利用すべきだと考えています。[ 84 ]テスト自動化は、要件を把握し実装するための手段と見なすことができます。一般的に、システムの規模が大きく複雑であるほど、テスト自動化のROIは高くなります。また、ツールと専門知識への投資は、組織内で適切なレベルの知識共有が行われていれば、複数のプロジェクトにわたって償却できます。
ISO 29119ソフトウェアテスト標準の存在は正当化されるでしょうか?
ISO 29119規格に対して、コンテキスト駆動型ソフトウェアテスト派から強い反対意見が表明されている。国際ソフトウェアテスト協会（ISTS）などの専門テスト団体は、この規格の撤回を試みている。[ 85 ] [ 86 ]
一部の専門家は、試験分野は認証の準備ができていないと主張している。
[ 87 ]現在提供されている認定資格は、申請者にソフトウェアテスト能力を証明することを実際に要求するものではありません。広く受け入れられている知識体系に基づいた認定資格はありません。認定資格自体は、個人の生産性、スキル、実践的な知識を測定することはできず、テスターとしての能力やプロフェッショナリズムを保証するものでもありません。 [ 88 ]
欠陥の修正にかかる相対的な費用を示すために使用される研究
欠陥の発生と検出状況に応じて、欠陥の修正にかかる相対的な費用を示す研究の適用性については、相反する見解があります。例えば、

一般的に、欠陥の発見が早け​​れば早いほど、修正コストは低くなると考えられています。次の表は、欠陥が発見された段階に応じた修正コストを示しています。[ 89 ]例えば、要件定義の問題がリリース後に初めて発見された場合、要件レビューの段階で既に発見されていた場合に比べて、修正コストは10～100倍高くなります。しかし、近年の継続的デプロイメントの実践やクラウドベースのサービスの登場により、再デプロイメントとメンテナンスのコストは時間の経過とともに軽減される可能性があります。

欠陥を修正するためのコスト 検出された時間
要件 建築 工事 システムテスト リリース後
導入時間 要件 1× 3× 5～10倍 10倍 10～100倍
建築 – 1× 10倍 15× 25～100倍
工事 – – 1× 10倍 10～25倍

この表の元となるデータは乏しい。ローラン・ボサヴィットは分析の中でこう述べている。

「小規模プロジェクト」の曲線は、わずか2つの1年生チームから得られたものであり、サンプル数が少なすぎるため、「小規模プロジェクト全般」に外挿することは全く正当化できません。GTEの研究では、データが大規模プロジェクトと小規模プロジェクトという2つのプロジェクトから得られたと述べているだけで、そのデータについての説明はありません。ベル研究所の「セーフガード」プロジェクトについて引用されている論文は、ボームのデータポイントが示唆するようなきめ細かいデータを収集していないことを明確に否定しています。IBMの研究（フェイガンの論文）には、ボームのグラフと矛盾すると思われる主張が含まれており、彼のデータポイントに明確に一致する数値結果は示されていません。

ボーム氏はTRWのデータについて論文を引用していない。2010年に「Making Software」に寄稿した際は、1976年のオリジナル論文を引用している。ボーム氏が引用するのに適切な時期にTRWで実施された大規模な研究は存在するが、その論文にはボーム氏の主張を裏付けるようなデータは含まれていない。[ 90 ]

参照

参考文献

  1. ^ Kaner, Cem (2006年11月17日).探索的テスト(PDF) . Quality Assurance Institute Worldwide Annual Software Testing Conference. フロリダ州オーランド. 2014年11月22日閲覧.
  2. ^ a b Pan, Jiantao (1999年春). 「ソフトウェアテスト」（コースワーク）. カーネギーメロン大学. 2017年11月21日閲覧。
  3. ^ a b c d Kaner, Cem ; Falk, Jack ; Nguyen, Hung Quoc (1999). 『コンピュータソフトウェアのテスト』（第2版）. ニューヨーク: John Wiley and Sons. ISBN 978-0-471-35846-6。
  4. ^ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand ; Fiva, Arno (2007年9月). Contract Driven Development = Test Driven Development – Writing Test Cases (PDF) . ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007. Dubrovnik, Croatia . 2017年12月8日閲覧.
  5. ^ a b Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防：ソフトウェア管理におけるベストプラクティス. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0。
  6. ^コーン、マイク（2009年）『アジャイルで成功する：スクラムを用いたソフトウェア開発』アディソン・ウェズリー・プロフェッショナル、ISBN 978-0321579362。
  7. ^ Molina, Alessandro (2021). Pythonによるテスト駆動ソフトウェアの作成：PythonとPyTestを使用して、アプリケーションのニーズと複雑さに合わせて拡張できるテストスイートを作成する。Packt Publishing. ISBN 978-1838642655。
  8. ^ Fernandes da Costa, Lucas (2021). 『JavaScriptアプリケーションのテスト』 Manning. ISBN 978-1617297915。
  9. ^ 「ソフトウェアテストのための不十分なインフラストラクチャの経済的影響」（PDF） .米国国立標準技術研究所. 2002年5月. 2017年12月19日閲覧。
  10. ^ Vashistha, Avinash; Khan, Imrana (2009年10月). 「世界の新興アウトソーシング都市トップ50：Global Services-Tholons調査」 . 2025年10月25日閲覧。
  11. ^ a b c Myers, Glenford J. (1979).ソフトウェアテストの芸術. John Wiley and Sons. ISBN 978-0-471-04328-7。
  12. ^ a b c IEEE標準ソフトウェア工学用語集、IEEE、1990、doi：10.1109/IEEESTD.1990.101064、ISBN 978-1-55937-067-7
  13. ^ 「Certified Tester Foundation Level Syllabus」 . International Software Testing Qualifications Board . 2011年3月31日. セクション1.1.2. 2017年10月28日時点のオリジナル(pdf)からアーカイブ。 2017年12月15日閲覧。
  14. ^ 「Certified Tester Foundation Level Syllabus」 . International Software Testing Qualifications Board . 2011年3月31日. セクション1.1.2. 2017年10月28日時点のオリジナル(pdf)からアーカイブ。 2017年12月15日閲覧。
  15. ^ 「Certified Tester Foundation Level Syllabus」（PDF） . International Software Testing Qualifications Board . 2005年7月1日 . Principle 2、Section 1.3. 2008年12月17日時点のオリジナル（PDF）からアーカイブ。 2017年12月15日閲覧。
  16. ^ Ramler, Rudolf; Kopetzky, Theodorich; Platz, Wolfgang (2012年4月17日). TOSCAテストスイートにおける組み合わせテスト設計：教訓と実践的影響. IEEE 第5回国際ソフトウェアテスト・検証会議 (ICST). モントリオール, ケベック州, カナダ. doi : 10.1109/ICST.2012.142 .
  17. ^ Kaner, Cem; Bach, James; Pettichord, Bret (2001).ソフトウェアテストにおける教訓：コンテキスト駆動型アプローチ. Wiley. pp.  31–43 . ISBN 978-0-471-08112-8。
  18. ^ Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防：ソフトウェア管理におけるベストプラクティス. Wiley-IEEE Computer Society Press. p. 74. ISBN 978-0-470-04212-0。
  19. ^ O'Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (2015年10月15日).システム、ソフトウェア、およびサービスプロセス改善：第22回ヨーロッパ会議、EuroSPI 2015、アンカラ、トルコ、2015年9月30日～10月2日。議事録. Springer. ISBN 978-3-319-24647-5。
  20. ^ Bourque, Pierre; Fairley, Richard E. 編 (2014). 「第5章」 .ソフトウェアエンジニアリング知識体系ガイド. 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. 2018年1月2日閲覧。
  21. ^ Bourque, P.; Fairley, RD 編 (2014). 「第4章 ソフトウェアテスト」(PDF) . SWEBOK v3.0: ソフトウェアエンジニアリング知識体系ガイド. IEEE. pp. 4–1–4–17. ISBN 978-0-7695-5166-1. 2018年6月19日時点のオリジナル（PDF）からアーカイブ。2018年7月13日閲覧。
  22. ^ Dooley, J. (2011).ソフトウェア開発と専門職実務. APress. pp.  193–4 . ISBN 978-1-4302-3801-0。
  23. ^ Wiegers, K. (2013). 『ソフトウェアエンジニアリング文化の創造』Addison-Wesley. pp.  211–2 . ISBN 978-0-13-348929-3。
  24. ^ Kolawa, Adam; Huizinga, Dorota (2007).自動欠陥予防：ソフトウェア管理におけるベストプラクティス. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0。
  25. ^ a bグレアム、D.;ヴァン・ヴィーネンダール、E.エヴァンス、I. (2008)。ソフトウェアテストの基礎。センゲージ学習。ページ 57–58。ISBN​​ 978-1-84480-989-9。
  26. ^ a b c d Oberkampf, WL; Roy, ​​CJ (2010). 『科学計算における検証と妥当性確認』ケンブリッジ大学出版局. pp.  154–5 . ISBN 978-1-139-49176-1。
  27. ^ Lee, D.; Netravali, AN; Sabnani, KK; Sugla, B.; John, A. (1997). 「パッシブテストとネットワーク管理への応用」. Proceedings 1997 International Conference on Network Protocols . IEEE Comput. Soc. pp.  113– 122. doi : 10.1109/icnp.1997.643699 . ISBN 978-0-8186-8061-8. S2CID  42596126 .
  28. ^ Cem Kaner、「探索的テストのチュートリアル」 Wayback Machineで2013年6月12日にアーカイブ、p.2
  29. ^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013 年 6 月 12 日にアーカイブ、p. 36。
  30. ^ Lee, D.; Yannakakis, M. (1996). 「有限ステートマシンのテストの原理と方法 - 概要」 IEEE紀要84 ( 8): 1090–1123 . doi : 10.1109/5.533956 .
  31. ^ Petrenko, A.; Yevtushenko, N. (2011). 「非決定性FSMで規定された決定性実装の適応型テスト」 .ソフトウェアとシステムのテスト：第23回IFIP WG 6.1国際会議、ICTSS 2011、パリ、フランス、11月7-10日. コンピュータサイエンス講義ノート. 第7019巻. Springer Berlin Heidelberg. pp.  162– 178. doi : 10.1007/978-3-642-24580-0_12 . ISBN 978-3-642-24579-4。
  32. ^ Petrenko, A.; Yevtushenko, N. (2014). 「FSMを用いた非決定性システムの適応型テスト」. 2014 IEEE 第15回高保証システムエンジニアリング国際シンポジウム. IEEE. pp.  224– 228. doi : 10.1109/HASE.2014.39 . ISBN 978-1-4799-3466-9。
  33. ^ a b c d Limaye, MG (2009).ソフトウェアテスト. Tata McGraw-Hill Education. pp.  108–11 . ISBN 978-0-07-013990-9。
  34. ^ a b c dサレハ、KA (2009)。ソフトウェアエンジニアリング。 J.ロス出版。ページ 224–41。ISBN​​ 978-1-932159-94-3。
  35. ^ a b c Ammann, P.; Offutt, J. (2016).ソフトウェアテスト入門. ケンブリッジ大学出版局. p. 26. ISBN 978-1-316-77312-3。
  36. ^ Everatt, GD; McLeod Jr., R. (2007). 「第7章 機能テスト」.ソフトウェアテスト：ソフトウェア開発ライフサイクル全体にわたるテスト. John Wiley & Sons. pp.  99– 121. ISBN 978-0-470-14634-7。
  37. ^ a bスティーブ・コーネット（1996年頃）「コードカバレッジ分析」ブルズアイテストテクノロジー入門。2017年11月21日閲覧。
  38. ^ a bブラック、R. (2011).実用的なソフトウェアテスト：効果的かつ効率的なテストプロフェッショナルになる. John Wiley & Sons. pp.  44–6 . ISBN 978-1-118-07938-6。
  39. ^簡単な例として、 C関数は1つの文のみで構成されています。仕様に対するすべてのテストは、 が選択された場合を除いて成功します。intf(intx){returnx*x-6*x+8;}f(x)>=0x=3
  40. ^パットン、ロン (2005).ソフトウェアテスト（第2版）. インディアナポリス: サムズパブリッシング. ISBN 978-0-672-32798-8。
  41. ^ Laycock, Gilbert T. (1993).仕様に基づくソフトウェアテストの理論と実践(PDF) (博士論文).シェフィールド大学コンピュータサイエンス学部. 2018年1月2日閲覧。
  42. ^ Bach, James (1999年6月). 「リスクと要件ベースのテスト」(PDF) . Computer . 32 (6): 113–114 . 2008年8月19日閲覧.
  43. ^ Mathur, AP (2011). 『ソフトウェアテストの基礎』 . ピアソン・エデュケーション・インディア. p. 63. ISBN 978-81-317-5908-0。
  44. ^ a b Clapp, Judith A. (1995).ソフトウェア品質管理、エラー分析、テスト. William Andrew. p. 313. ISBN 978-0-8155-1363-6. 2018年1月5日閲覧。
  45. ^ Mathur, Aditya P. (2007). 『ソフトウェアテストの基礎』 . Pearson Education India. p. 18. ISBN 978-81-317-1660-1。
  46. ^ Lönnberg, Jan (2003年10月7日).ソフトウェアのビジュアルテスト(PDF) (修士論文). ヘルシンキ工科大学. 2012年1月13日閲覧。
  47. ^ Chima, Raspal. 「Visual testing」 . TEST Magazine . 2012年7月24日時点のオリジナルよりアーカイブ。 2012年1月13日閲覧。
  48. ^ a b c Lewis, WE (2016).ソフトウェアテストと継続的品質改善（第3版）. CRC Press. pp.  68– 73. ISBN 978-1-4398-3436-7。
  49. ^ a b Ransome, J.; Misra, A. (2013). Core Software Security: Security at the Source . CRC Press. pp.  140–3 . ISBN 978-1-4665-6095-6。
  50. ^ 「ブラックボックス、ホワイトボックス、グレーボックス向けSOAテストツール」（ホワイトペーパー）。Crosscheck Networks。2018年10月1日時点のオリジナルよりアーカイブ。2012年12月10日閲覧。
  51. ^ a b Myers, G. (2004). Sandler, C.; Badgett, T.; Thomas, M. (編). The Art of Software Testing (第2版). Wiley. ISBN 9780471469124。
  52. ^ Ammann, Paul; Offutt, Jeff (2008年1月28日). 『ソフトウェアテスト入門』ケンブリッジ大学出版局. p. 215. ISBN 978-0-521-88038-1. 2017年11月29日閲覧。
  53. ^ a b c Lewis, WE (2016).ソフトウェアテストと継続的品質改善（第3版）. CRC Press. pp.  92–6 . ISBN 978-1-4398-3436-7。
  54. ^ Machado, P.; Vincenzi, A.; Maldonado, JC (2010). 「第1章 ソフトウェアテスト：概要」 Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (編).ソフトウェアエンジニアリングにおけるテスト手法Springer Science & Business Media. pp.  13– 14. ISBN 978-3-642-14334-2。
  55. ^ Clapp, JA; Stanten, SF; Peng, WW; et al. (1995).ソフトウェア品質管理、エラー分析、およびテスト. Nova Data Corporation. p. 254. ISBN 978-0-8155-1363-6。
  56. ^ a b c「ISTQB CTFLシラバス2018」（PDF） . ISTQB - 国際ソフトウェアテスト資格委員会. 2022年3月24日時点のオリジナルよりアーカイブ（PDF） . 2022年4月11日閲覧。
  57. ^ Woods, Anthony J. (2015年6月5日). 「運用上の受け入れ – ISO 29119ソフトウェアテスト規格の適用」（ホワイトペーパー）. Capgemini Australia . 2018年1月9日閲覧。
  58. ^ 「ソフトウェアテストで使用される用語の標準用語集」（PDF）バージョン3.1。国際ソフトウェアテスト資格委員会（ISQB ）。 2018年1月9日閲覧。
  59. ^ O'Reilly, Tim (2005年9月30日). 「Web 2.0とは何か」 . O'Reilly Media. 第4章 ソフトウェアリリースサイクルの終焉. 2018年1月11日閲覧。
  60. ^ Auerbach, Adam (2015年8月3日). 「パイプラインの一部：継続的テストが不可欠な理由」 . TechWell Insights . TechWell Corp. 2018年1月12日閲覧。
  61. ^ Philipp-Edmonds, Cameron (2014年12月5日). 「リスクと継続的テストの関係：Wayne Ariola氏へのインタビュー」 . Stickyminds . 2018年1月16日閲覧。
  62. ^ Ariola, Wayne; Dunlop, Cynthia (2015年10月). DevOps: バグをより早くクライアントにプッシュしていますか? (PDF) . Pacific Northwest Software Quality Conference . 2018年1月16日閲覧。
  63. ^ Auerbach, Adam (2014年10月2日). 「Shift Left and Put Quality First」 . TechWell Insights . TechWell Corp. 2018年1月16日閲覧。
  64. ^ Taqi, Farwa; Batool, Syeda Hina; Arshad, Alia (2024年5月23日). 「クラウドアプリケーションのユーザビリティ開発尺度の開発と検証」 . International Journal of Human–Computer Interaction : 1– 16. doi : 10.1080/10447318.2024.2351715 . ISSN 1044-7318 . 
  65. ^「セクション4.38」。ISO /IEC/IEEE 29119-1:2013 – ソフトウェアおよびシステムエンジニアリング – ソフトウェアテスト – パート1 – 概念と定義。国際標準化機構。 2018年1月17日閲覧。
  66. ^ 「グローバリゼーションのステップバイステップ：世界対応のテストアプローチ。Microsoft Developer Network」。Microsoft Developer Network。2012年6月23日時点のオリジナルよりアーカイブ。 2012年1月13日閲覧。
  67. ^ Claessen, Koen; Hughes, John (2000). 「QuickCheck」 .第5回ACM SIGPLAN国際関数型プログラミング会議議事録. Icfp '00. pp.  268– 279. doi : 10.1145/351240.351266 . ISBN 978-1-58113-202-1. S2CID  5668071 .
  68. ^ 「コントラクトテストとは何か、そしてその重要性は？」 BrowserStack 。2025年11月15日閲覧。
  69. ^ Fowler, Martin. 「bliki: Contract Test」 . martinfowler.com . 2025年11月15日閲覧。
  70. ^ Gelperin, David ; Hetzel, Bill (1988年6月1日). 「ソフトウェアテストの成長」 . Communications of the ACM . 31 (6): 687– 695. doi : 10.1145/62959.62965 . S2CID 14731341 . 
  71. ^グレゴリー、ジャネット、クリスピン、リサ (2014). 『More Agile Testing』. Addison-Wesley Professional. pp.  23– 39. ISBN 978-0-13-374956-4。
  72. ^ 「ソフトウェアテストライフサイクル」 . etestinghub . ソフトウェアテストにおけるテストフェーズ. 2012年1月13日閲覧。
  73. ^ダスティン、エルフリーデ (2002).効果的なソフトウェアテスト. Addison-Wesley Professional. p. 3. ISBN 978-0-201-79429-8。
  74. ^ a b「テスト駆動開発（TDD）とは何か？」 Agile Alliance . 2015年12月5日. 2018年3月17日閲覧。
  75. ^ 「モバイルアプリケーションのためのテスト駆動開発と継続的インテグレーション」。Microsoft Developer Network。2009年1月14日。 2018年3月17日閲覧。
  76. ^ Brown, Chris; Cobb, Gary; Culbertson, Robert (2002年4月12日).迅速ソフトウェアテスト入門.
  77. ^ Tran, Eushiuan (1999). 「検証／妥当性確認／認証」（コースワーク）. カーネギーメロン大学. 2008年8月13日閲覧。
  78. ^ a b Gotel, Orlena; Cleland-Huang, Jane ; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (2012年1月1日). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (編).ソフトウェアとシステムのトレーサビリティ. Springer London. doi : 10.1007/978-1-4471-2239-5_1 . ISBN 978144712​​2388。
  79. ^ IEEE (1998).ソフトウェアテストドキュメントのためのIEEE標準. ニューヨーク: IEEE. ISBN 978-0-7381-1443-9。
  80. ^ Pinto, Leandro Sales; Sinha, Saurabh; Orso, Alessandro (2012年11月11日). 「テストスイートの進化に関する神話と現実を理解する」 . ACM SIGSOFT 第20回ソフトウェア工学基礎国際シンポジウム議事録. Association for Computing Machinery. pp.  1– 11. doi : 10.1145/2393596.2393634 . ISBN 9781450316149. S2CID  9072512 .
  81. ^ Strom, David (2009年7月1日). 「私たちは皆、物語の一部である」 . Software Test & Performance Collaborative. 2009年8月31日時点のオリジナルよりアーカイブ。
  82. ^ Griffiths, M. (2005). 「PMIへのアジャイルプロジェクトマネジメントの指導」. Agile Development Conference (ADC'05) . ieee.org. pp.  318– 322. doi : 10.1109/ADC.2005.45 . ISBN 978-0-7695-2487-0. S2CID  30322339 .
  83. ^ Willison, John S. (2004年4月). 「アジャイルな力のためのアジャイルソフトウェア開発」 . CrossTalk (2004年4月). STSC. 2005年10月29日時点のオリジナルよりアーカイブ。
  84. ^例としては、マーク・フュースター著『ドロシー・グラハム：ソフトウェアテスト自動化』（アディソン・ウェスリー、1999年、 ISBN）が挙げられます。 978-0-201-33140-0。
  85. ^ "stop29119" . commonsensetesting.org . 2014年10月2日時点のオリジナルよりアーカイブ。
  86. ^ Paul Krill (2014年8月22日). 「ソフトウェアテスター、ISO 29119規格提案に難色」InfoWorld .
  87. ^ Kaner, Cem (2001). 「NSFの助成金申請は『ソフトウェアテストに関する学術的および商業的なコースの質を大幅に向上させるための基盤を築く』ことを目的としている」（PDF） 。 2009年11月27日時点のオリジナル（PDF）からアーカイブ。2006年10月13日閲覧。
  88. ^ Kaner, Cem (2003).ソフトウェアテスターの有効性の測定(PDF) . STAR East. 2010年3月26日時点のオリジナル(PDF)からアーカイブ。 2018年1月18日閲覧。
  89. ^ McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. p  . 29. ISBN 978-0-7356-1967-8。
  90. ^ Bossavit, Laurent (2013年11月20日). 「欠陥のコスト：図解歴史」.ソフトウェアエンジニアリングのレプラコーン：伝説が現実になる過程と対処法. leanpub.

さらに読む

ウィキメディア コモンズには、ソフトウェア テストに関連するメディアがあります。
Wikiversityでは、ソフトウェアテスト部門でソフトウェアテストについてさらに学び、他の人に教えることができます。
「 https://en.wikipedia.org/w/index.php?title=ソフトウェアテスト&oldid= 1336542517」より取得