アプリケーションのプログラミングインターフェースを直接使用し、テスト対象のソフトウェアにコマンドを発行して行うテスト。
Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
テストスイートが遂行したN+1遷移のシーケンスのパーセンテージ。
グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。
テストスイートが遂行したN+1遷移のシーケンスのパーセンテージ。
リスクベースドテストの体系的なアプローチ。プロダクトリスクの識別と分析を行ない、発生可能性および影響に基づくプロダクトリスクマトリクスを作成する。この用語はProduct RISk MAnagement（プロダクトリスクマネジメント）の略語である。
身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
特定の方法でテスト対象とやりとりするユーザーまたは他の人、あるいはシステム。
同じ組織ではない人が、プロジェクトチームと同じ場所で行なうテスト。
一連のウェブアクセシビリティガイドラインの一部分。インターネットに関する主要な標準組織であるWorld Wide Web Consortium（W3C）のWeb Accessibility Initiative（WAI）が発行している。特に身体的な制約を持つ人がコンテンツを利用できるようにするための一連のガイドラインを含む。
ブラックボックステスト技法のひとつ。クラシフィケーションツリーを使用してテストケースを設計する。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。
すでに記述されているテスト順序通りに実行するテスト方法。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
質問または確認項目のリストを使用して行うレビュー技法。
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。
一つ以上のテストケースをセットにしたドキュメント。
識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
組織のテストプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象となるシステムのことであり、テスト対象の一種。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
テスト自動化アーキテクチャの設計、実装、および保守を担当する人。作成したテスト自動化ソリューションを技術的に進化させる役割も担う。
テスト自動化アーキテクチャを具現化または実装したもの。特定のテスト自動化要素を実装するコンポーネントの組み合わせで構成される。それらのコンポーネントには、市販のテストツール、テスト自動化フレームワーク、テストハードウェアなどが含まれることがある。
達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。
テスト入力を生成することでテスト設計を支援するツール。テスト入力の生成は、CASEツールのリポジトリ(たとえば要件マネジメントツール)に格納している仕様、ツールの中に保存してある特定のテスト条件、またはコードから行なわれる。
個人を特定できる情報または機密情報を保護して、意図せず漏洩しないようにすること。
別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、一時的なコンポーネントまたはツール。
抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
目標を達成するのに役立つ、一般的に認められている経験則。
新たに作成した各ビルドに対して、完全性を確認し、主要な機能性、安定性、および試験性を検証する自動化テストのセット。ビルドが頻繁にリリースされる場合（たとえば、アジャイルプロジェクト）に、業界で一般的に行なわれるテストである。新たに作成したビルドは、このテストの完了後に、次のテストに向けてリリースされる。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
真または偽として評価することのできる論理的表現。たとえば、A>B。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
相互関係のある活動のセット。入力を出力に変換する。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
ブラックボックステスト設計技法の一つ。ユーザーストーリーの実装の正しさを検証するために、ユーザーストーリーに基づいてテストケースを設計する。
日常言語またはビジネス言語で表現された、1つの文で構成されるユーザー要件またはビジネス要件。ユーザーが必要とする機能、その背後にある理由、何らかの非機能、および受け入れ基準を含む。
ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能属性のテストに利用できる。
変更により引き起こされた、コンポーネントやシステムの品質の悪化。
具体的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
設計のアプローチの一つ。ソフトウェア製品の使用に重点を置き、人的要因、人間工学、および使用性の知識や技法を適用することによって、ソフトウェア製品の使用性を高める。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。
コンポーネントまたはシステムの使用性に関わる要件。
システムを改善するため（形成的評価と呼ばれる）、またはシステムのメリットまたは価値を評価するため（総括的評価と呼ばれる）、システムの使用性に関わる情報を収集するプロセス。
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
入力、刺激（原因）、関連する出力（結果）を図式表現したもの。テストケースの設計で使用できる。
システムを受け入れる判断に焦点を当てたテストレベル
テストアイテム(機能)やフィーチャーが、テストに合格したか失敗したかを判定するための判定規則。
品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。
一つ以上のインシデントを引き起こしている未解明の原因。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
一般市場の多数の顧客向けに同一の規格で開発されたプロダクトの一種。
定義されたプロセスに従うレビュー。形式に則った文書の作成を伴う。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
物理的または機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、または実行の完全な打ち切りなどで特徴付けられる。
真または偽として評価することのできる論理的表現。たとえば、A>B。
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
ソフトウェア製品の移植性を判定するテストのプロセス。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
システム統合法のアプローチの一つ。早い時期に、基本機能を動作させるために、コンポーネントやシステムを結合すること。
コンポーネントやシステムが、特定の条件の下で使用される場合に、定義または示唆されているニーズを満たす機能を備えている度合。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
コンポーネントまたはシステムが取りうる状態を示し、ある状態から他への状態の変化の原因となる、（または）その結果として生ずる、イベントや状況を表すダイアグラム。
発生する可能性のあるイベントと状態の組み合わせから、生じる結果を示す遷移のテーブル。無効な遷移と、有効な遷移の両方を示す。
コンポーネントやシステムにおいて、二つの状態の間を遷移すること。
重要な懸念、問題、または機会を特定する評価の結果。
ソフトウェア製品の移植性を判定するテストのプロセス。
デシジョンテーブルの種類の一つ。出力に影響しない条件を考慮不要に設定して、ありえない入力または同じ出力を導き出す入力の組み合わせを一つの列（ルール）にまとめる。
テスト担当者の経験・知識・直感をベースに行なうテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
論理演算子（AND、OR、またはXOR）によって二つまたはそれ以上の単一条件が結合されたもの。たとえば、「A>B AND C>1000」。
論理演算子（AND、OR、またはXOR）によって二つまたはそれ以上の単一条件が結合されたもの。たとえば、「A>B AND C>1000」。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
要件、要件属性（たとえば、優先順位、信頼できる情報元）、注釈を記録し、要件の階層をたどる追跡や、要件変更管理を支援するツール。要件マネジメントツールの中には、あらかじめ定義した要件規約を基に、整合性や違反をチェックするような、静的解析をするものもある。
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。