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