身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
ある特定のシステムと同じ入力を受け入れ、同じ出力を作り出す装置、コンピュータプログラム、またはシステム。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
セッションベースドテストの測定と管理の手法。たとえば、探索的テスト。
テスト活動をテストセッションとして計画するアプローチ
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
セッションベースの探索的テストにおけるテスト活動のドキュメント。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テスト対象となるシステムのことであり、テスト対象の一種。
コンポーネントやシステムのテストを実施する熟練した専門家。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
テスト自動化アーキテクチャの設計、実装、および保守を担当する人。作成したテスト自動化ソリューションを技術的に進化させる役割も担う。
テスト自動化アーキテクチャを具現化または実装したもの。特定のテスト自動化要素を実装するコンポーネントの組み合わせで構成される。それらのコンポーネントには、市販のテストツール、テスト自動化フレームワーク、テストハードウェアなどが含まれることがある。
テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
目標を達成するのに役立つ、一般的に認められている経験則。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
真または偽として評価することのできる論理的表現。たとえば、A>B。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
ユーザーのニーズ、要件、およびビジネスプロセスに重点を置いて、実際のまたはシミュレートされた運用環境で、対象となるユーザーが実行する受け入れテスト。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
一つ以上のインシデントを引き起こしている未解明の原因。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
情報をエンコードするプロセス。認可されたもののみが一般的には特定の復号化キーまたは復号化プロセスを使用して元の情報を読み取れるようにする。
真または偽として評価することのできる論理的表現。たとえば、A>B。
規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
測定することによって、ある実体の特性に付加した数字や種別。
重要な懸念、問題、または機会を特定する評価の結果。
テスト担当者の経験・知識・直感をベースにテストケースを導き出したり選択したりする技法。
テスト担当者の経験・知識・直感をベースに行なうテスト。
統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。