Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。
組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
テストアイテムの終了基準に対応する評価を提供するテストレポート。
セッションベースの探索的テストにおけるテスト活動のドキュメント。
テスト活動をプロジェクト中で管理（マネジメント）しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
テスト資産を後続のテストで使用できるようにし、テスト環境を十分に満足できる状態に残し、テスト結果を関連するステークホルダに伝える活動。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テスト対象となるシステムのことであり、テスト対象の一種。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
コンポーネントやシステムのテストを実施する熟練した専門家。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
テストケースを適切に生成するために使用する基準、またはテストのサイズを制限するためにテストケースを選択する際に使用する基準。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
個人を特定できる情報または機密情報を保護して、意図せず漏洩しないようにすること。
スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
目標を達成するのに役立つ、一般的に認められている経験則。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
真または偽として評価することのできる論理的表現。たとえば、A>B。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
高位のユーザ要件またはビジネス要件。主に、アジャイルソフトウェア開発で用いられる。ユーザが要求する機能とその背景にある理由、およびあらゆる非機能を獲得し、日常言語またはビジネス言語で表現される一つの文で構成する。また、受け入れ基準も含む。
アクターとコンポーネントまたはシステムとの間の対話における一連のトランザクション。視覚できる結果を伴う。アクターは、ユーザまたはシステムと情報交換するあらゆるものになりうる。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
テストアイテム(機能)やフィーチャーが、テストに合格したか失敗したかを判定するための判定規則。
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
一つ以上のインシデントを引き起こしている未解明の原因。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
リソースにアクセスすることを可能にする、人、またはプロセスに付与される権限。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
測定することによって、ある実体の特性に付加した数字や種別。
重要な懸念、問題、または機会を特定する評価の結果。
ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。
テスト担当者の経験・知識・直感をベースにテストケースを導き出したり選択したりする技法。
テスト担当者の経験・知識・直感をベースに行なうテスト。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
要件、要件属性（たとえば、優先順位、信頼できる情報元）、注釈を記録し、要件の階層をたどる追跡や、要件変更管理を支援するツール。要件マネジメントツールの中には、あらかじめ定義した要件規約を基に、整合性や違反をチェックするような、静的解析をするものもある。
人またはプロセスが、実際に、それが名乗っている人またはプロセスであることを確認する手順。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。