Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
特定の方法でテスト対象とやりとりするユーザーまたは他の人、あるいはシステム。
プロジェクトをいくつかの（通常は、多数の）反復部分に分割して開発するライフサイクルの一種。一つの反復部分は、実行可能なプロダクトを（内部、あるいは、外部へ）リリースするという結果をもたらす、完全な開発ループである。
インストールプロセス中、インストールをガイドする説明書で最適の媒体で提供される。マニュアルガイド、段階的な処理手順、インストールウィザード、その他類似の手順記述などの形式をとる。
アジャイルソフトウェア開発の中で使用されるソフトウェアエンジニアリング方法論。中心となるプラクティスは、ペアプログラミング、徹底したコードレビュー、全てのコードの単体テスト、単純明快なコードなどである。
大きなユーザーストーリーのひとつ。1回のイテレーションではデリバリーできない、または更に小さなユーザーストーリーに分割できる程度の大きさのもの。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
物理的な接続がなく、デプロイやアクセス、マネジメントされるサービスの仮想的なデリバリーを可能にする技術。
物理的なシステム、あるいは、抽象的なシステムの代表的な動作特性を他のシステムで模倣すること。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
テスト活動をテストセッションとして計画するアプローチ
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに廃棄フェーズを含むこともある。注）これらのフェーズは重複することもあるし、反復することもある。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
質問または確認項目のリストを使用して行うレビュー技法。
責任を分離すること。これにより、客観的なテストを促進できる。
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。
一つ以上のテストケースをセットにしたドキュメント。
識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
活動、タスク、またはテストプロセスのイベントに関して、開始/終了日、時間、依存関係を識別できるリスト。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
組織のテストプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
大規模なプロジェクトで、テストマネージャに報告を行い、特定のテストレベルやテスト活動に責任を持つ個人。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
テスト対象となるシステムのことであり、テスト対象の一種。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。
テスト入力を生成することでテスト設計を支援するツール。テスト入力の生成は、CASEツールのリポジトリ(たとえば要件マネジメントツール)に格納している仕様、ツールの中に保存してある特定のテスト条件、またはコードから行なわれる。
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。
別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、一時的なコンポーネントまたはツール。
抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
一つのイテレーションにおける残作業と時間の関係を表すために公開されるチャート。このチャートは、イテレーションにおけるタスクの完了状況と傾向を示す。一般的に、X軸はスプリントにおける日数を表し、Y軸は残作業の量（通常、理想的なエンジニアリングの時間またはストーリーポイントのどちらか）を表す。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
真または偽として評価することのできる論理的表現。たとえば、A>B。
合意に基づく見積り技法の一つ。アジャイルソフトウェア開発で、ユーザストーリーの作業量または相対規模を見積るのに使用される。ワイドバンドデルファイ方法の一つの種類で、チームが見積る単位を表す一組のカードを使用する。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
相互関係のある活動のセット。入力を出力に変換する。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
日常言語またはビジネス言語で表現された、1つの文で構成されるユーザー要件またはビジネス要件。ユーザーが必要とする機能、その背後にある理由、何らかの非機能、および受け入れ基準を含む。
独自の適応性を持つ反復ソフトウェア開発プロセスフレームワーク。方向付け、推敲、作成、および移行の四つのプロジェクトライフサイクルフェーズで構成される。
変更により引き起こされた、コンポーネントやシステムの品質の悪化。
具体的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
専門家によるテスト見積り技法。チームメンバーから集めた知識を用い、正確な見積りをするもの。
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
システムを受け入れる判断に焦点を当てたテストレベル
品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。
品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。
品質に関して組織を指揮し、管理するための調整された活動。注記 品質に関する指揮および管理には、通常、品質方針および品質目標の設定、品質計画、品質コントロール、品質保証および品質改善が含まれる。JSTQB訳注）JIS Q 9000:2006より引用
一つ以上のインシデントを引き起こしている未解明の原因。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
コンポーネント、またはシステムの変更を契機に行うテストの一種。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
コンパイル時にオブジェクトコードに翻訳され、プログラムが走るときに手順に沿って実行されて、データに対して動作を行なうステートメント。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
一般市場の多数の顧客向けに同一の規格で開発されたプロダクトの一種。
定義されたプロセスに従うレビュー。形式に則った文書の作成を伴う。
テストツールの種類の1つ。定義したテストアイテム用の負荷を生成する。また、テストの実行中に、性能を計測・記録する。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
真または偽として評価することのできる論理的表現。たとえば、A>B。
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
コンポーネントまたはシステムの内部構造に基づいたカバレッジの測定値。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
システム統合法のアプローチの一つ。早い時期に、基本機能を動作させるために、コンポーネントやシステムを結合すること。
コンポーネントやシステムが、特定の条件の下で使用される場合に、定義または示唆されているニーズを満たす機能を備えている度合。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
コンポーネントまたはシステムが取りうる状態を示し、ある状態から他への状態の変化の原因となる、（または）その結果として生ずる、イベントや状況を表すダイアグラム。
重要な懸念、問題、または機会を特定する評価の結果。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
テスト担当者の経験・知識・直感をベースに行なうテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
要件、要件属性（たとえば、優先順位、信頼できる情報元）、注釈を記録し、要件の階層をたどる追跡や、要件変更管理を支援するツール。要件マネジメントツールの中には、あらかじめ定義した要件規約を基に、整合性や違反をチェックするような、静的解析をするものもある。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
性能テストの一種。さまざまな負荷でのコンポーネントやシステムの振る舞いを評価するために使用する。負荷については、予測される使用量の低、標準、ピークを一般的に使用する。
ユーザや顧客のサイトにインストールしたハードウェアやソフトウェア製品。この環境で、テスト中のコンポーネントやシステムを動作させる。運用環境のソフトウェアには、オペレーティングシステム、データベースマネジメントシステム、その他のアプリケーションを含むこともある。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。