Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
エクストリームプログラミング（XP）のような技法や手法が取り込まれているアジャイルソフトウェア開発方法論を用いたり、開発をテストの一部とみなしたり、テストファースト設計パラダイムを重視するプロジェクトで実施するテスト。
アジャイルソフトウェア開発を支援する価値に関する宣言。ここでいう価値とは、以下のようなものである。・プロセスやツールよりも個人との対話を重視する・網羅的なドキュメントよりも動作するソフトウェアを重視する・契約交渉よりも顧客との協調を重視する・計画に従うことよりも変化に対応することを重視する
大きなユーザーストーリーのひとつ。1回のイテレーションではデリバリーできない、または更に小さなユーザーストーリーに分割できる程度の大きさのもの。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
物理的な接続がなく、デプロイやアクセス、マネジメントされるサービスの仮想的なデリバリーを可能にする技術。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
故障や誤動作が人命や人々への深刻な損害、若しくは機器へのダメージや環境被害となる可能性のあるシステム。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
テスト対象となるシステムのことであり、テスト対象の一種。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
特定の境界条件の下で、テスト自動化の長期目標を達成するための高位レベルの計画。
システム全体を毎日（多くの場合、夜間）、コンパイル、リンクして作成する開発の活動。これにより、最新の変更を反映した一貫性のあるシステム、アプリケーションにいつでもアクセスできるようになる。
別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、一時的なコンポーネントまたはツール。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
目標を達成するのに役立つ、一般的に認められている経験則。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
真または偽として評価することのできる論理的表現。たとえば、A>B。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
中心となるキーワードやアイデアの周囲に、用語、アイデア、タスク、または他の項目を表現し、関連付け、配置するために使われる図。マインドマップは、アイデアを作り出し、視覚化し、構造化し、分類するために記述する。学習、組織化、問題解決、意思決定、文書作成の補助として活用される。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
適切なスタブやドライバを併用した状態、または独立した状態でコンポーネントをテストできるユニットテストまたはコンポーネントテスト用の環境を提供するツール。デバッグ機能など、開発者を支援するその他の機能もある。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
日常言語またはビジネス言語で表現された、1つの文で構成されるユーザー要件またはビジネス要件。ユーザーが必要とする機能、その背後にある理由、何らかの非機能、および受け入れ基準を含む。
変更により引き起こされた、コンポーネントやシステムの品質の悪化。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
一つ以上のインシデントを引き起こしている未解明の原因。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
テスト対象のシステムの動作または入手したテスト結果を基に、動的に対処するテスト。対処テストでは、ほとんどの場合、計画サイクルが短縮されており、テスト対象を受け取るまでテスト設計とテスト実装のフェーズが実施されない。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
真または偽として評価することのできる論理的表現。たとえば、A>B。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
コンポーネントまたはシステムが取りうる状態を示し、ある状態から他への状態の変化の原因となる、（または）その結果として生ずる、イベントや状況を表すダイアグラム。
重要な懸念、問題、または機会を特定する評価の結果。
テスト担当者の経験・知識・直感をベースに行なうテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
ソフトウェアを実行せずにソースコードを解析すること。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。