グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。
セキュリティ攻撃方法の一つ。悪意のあるSQLステートメントを入力フィールドに挿入して実行する。
それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。
最初は有益で一般的に使用できるように思われるが、実際には効果がない、または逆効果である反復的な活動、プロセス、構造、または再利用可能なソリューション。
インストールプロセス中、インストールを誘導するソフトウェア。いろいろな形態の媒体で提供される。インストールを実行し、インストール実施結果情報を出力し、オプション機能のガイダンスを表示するものが多い。
ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
脆弱性の一つ。悪意のあるコードを安全なWebサイトへ感染させるために攻撃者が悪用することを可能にする。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
プログラムにおけるサブルーチン間の呼び出し関係の抽象的表現。
セキュリティ攻撃方法の一つ。サービスできない正当なリクエストなどを大量に送りつけてシステムを過負荷状態にする。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース（たとえば、電子データ交換やインターネット）をテストすること。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
物理的なシステム、あるいは、抽象的なシステムの代表的な動作特性を他のシステムで模倣すること。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
テストスイートによって遂行されたステートメントのパーセンテージ。
ホワイトボックステスト設計技法の一つ。ステートメントを実行するテストケースを設計する。
予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
システムまたはコンポーネント、リソース、情報への不正なアクセスを成功させようとする試み。またはシステムの完全性を侵害しようとする試み。
許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに廃棄フェーズを含むこともある。注）これらのフェーズは重複することもあるし、反復することもある。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
どのような技術的アプローチをとるかで意見を一致させることを目的とした、ピアグループによるディスカッション。
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
テストケースを作成したり選択したりするための技法。
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
テスト実行に必要なスタブやドライバからなるテスト環境。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テストケースを作成したり選択したりするための技法。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。
テストケースを作成したり選択したりするための技法。
コンポーネントやシステムのテストを実施する熟練した専門家。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
テストケースを作成したり選択したりするための技法。
概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
テストスイートによって遂行された、判定結果のパーセンテージ。100%のデシジョンカバレッジは、100%のbranch coverage（ブランチカバレッジ）と100%のstatement coverage（ステートメントカバレッジ）の両方を意味する。
ホワイトボックステスト設計技法の一つ。判定を実行するテストケースを設計する。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
ホワイトボックステスト設計技法の一つ。変数の「定義と使用」の組を実行するようにテストケースを設計する。
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。
スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。
ドキュメントとソフトウェアの関連事項（たとえば、ある要件と、それを検証するテストケース）を識別する能力。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
Webサイト上に切断されたハイパーリンクが存在しないことを確認するために使用されるツール。
ウェブページで、他のウェブページへ導くためのポインタ。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
管理されている環境で、故障モードをシミュレーションするか、実際に故障を発生させて行なうテスト。故障の後、フェイルオーバー機能をテストし、データの損失および破損が発生しておらず、合意されている全てのサービスレベル（機能の可用性、応答時間など）を維持していることを確認する。
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とする。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
テストスイートによって遂行された分岐のパーセンテージ。100%のブランチカバレッジは100%のデシジョンカバレッジと100%のステートメントカバレッジの両方を意味する。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
他のデータアイテムのロケーションを指定するデータアイテム。たとえば、処理される次の従業員レコードアドレスを指定したデータアイテム。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
テスト時に、コンポーネントやシステムと同時に実行し、コンポーネントやシステムの振る舞いを監視、記録、分析するソフトウェアツールやハードウェア装置。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
ユーザの要件とニーズに重点を置いて、（シミュレートされた）運用環境で、使用することが予定されているユーザが実行する受け入れテスト。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを評価するプロセス。一般的に、それらのリスクの影響度と発生確率（可能性）を見積ることによって行なう。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
コンポーネントやシステムの振る舞いを測定する性能テストの一種。負荷（たとえば、同時実行ユーザ数やトランザクションの数）を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるか判定する。
テストされるコンポーネントやシステムが稼動中にユーザが行なうであろう活動内容を記した仕様書。ロードプロファイルは、特定の時間内に所定の運用プロファイルに準じ決められたトランザクションを処理する仮想ユーザを複数指定して構成する。
範囲外、若しくは、存在しない位置を参照しているポインタ。
ユーザに気づかれることなく、第三者により、通信（たとえば、クレジットカード決済情報）の傍受、模倣、改ざん、転送が行なわれる攻撃。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
特定のテストやテスト手順でコンポーネントやシステムを実行する前に満足すべき、環境と状態の条件。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
ソフトウェア製品が、特定の条件下で理解され、学びやすく、使用
しやすく、ユーザにとって魅力的である能力を判定するためのテスト。
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用
ソフトウェア製品の保守性を判定するテストのプロセス。
ソフトウェア製品の保守性を判定するテストのプロセス。
修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注）JIS X 0129-1:2003より引用
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
コンポーネントやシステムのテストにおいて、信頼性に関する故障を発見し、その欠陥を取り除いていくことで時間と共に信頼性が成長することを示すモデル。
ソフトウェア製品の信頼性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。
文書化された手順と要件に特徴付けられるレビュー。たとえば、インスペクション。
共通の資源を共有する共通の環境の中で、他の独立したソフトウェアと共存するためのソフトウェア製品の能力。 [ISO/IEC 9126] portabilityも参照のこと。 JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。
たとえば、プロダクトリスクまたは要件のような体系的な分析に基づくテスト。
テストスイートが遂行した条件と判定のパーセンテージ。100%の判定条件カバレッジは、100%の条件カバレッジと100%のデシジョンカバレッジを意味する。
判定の結果（これにより、どの分岐を選択するかが決まる）。
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。
コンポーネントやシステムの実行における全てのイベント (パス) のシーケンスを抽象表現したもの。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
コンポーネントやシステムの実行における一連のイベント（パス）。
（1）明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]JSTQB訳注）JIS X 0129-1:2003より引用
（2）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。
コンポーネントやシステムのソフトウェアを実行させて確認するテスト。
実行中のシステムやコンポーネントの振る舞い（たとえば、メモリの使用効率、CPUの使用状況）を評価するプロセス。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
ソフトウェア製品の回復性を判定するテストのプロセス。
ソフトウェア製品の回復性を判定するテストのプロセス。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
システムが故障から回復するまでに要する平均時間。これには一般的に欠陥が解決されていることを保証するテストが含まれる。
システムにおける故障から次の故障までの平均時間。MTBFは、通常、欠陥修正プロセスの一部として、障害が発生したシステムを直ちに修復することを想定した信頼度成長モデルの一部である。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。
ソフトウェア製品の拡張性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
他の測定値の見積りまたは予測に使うことができる測定値。
ランダムであるようにみえるが、実際にはいくつか事前に決められた順序に従って生成される一揃いのもの。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
物理的または機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、または実行の完全な打ち切りなどで特徴付けられる。
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
情報をエンコードするプロセス。認可されたもののみが一般的には特定の復号化キーまたは復号化プロセスを使用して元の情報を読み取れるようにする。
計算モデルの一つ。有限個数の状態と、それらの状態間遷移から構成される。状態遷移に対応する動作も記述できる。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
ソフトウェア製品の移植性を判定するテストのプロセス。
技術的かつ管理的な指示と監視を適用する規範。この規範の目的は、・構成アイテムの特性を機能的、物理的に識別・文書化すること、・特性に対する変更をコントロールすること、・処理の変更と実装の状況を記録し、報告すること、・特定の要求への整合を実証すること、である。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
コンポーネントやシステムの機能仕様の分析に基づいて実施するテスト。
ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
システム統合法のアプローチの一つ。早い時期に、基本機能を動作させるために、コンポーネントやシステムを結合すること。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
重要な懸念、問題、または機会を特定する評価の結果。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
複合条件を評価するためのプログラミング言語/インタープリタの技法。論理演算子の片方が最終結果を決定するのに十分である場合に、他方は評価されないことがある。
ソフトウェア製品の移植性を判定するテストのプロセス。
ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
ブラックボックステスト設計技法の一つ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。
統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
静的アナライザの一つ。コードに潜在する特定のセキュリティ脆弱性を検出する。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。
ソフトウェアにある欠陥の診断または故障原因の追及、およびソフトウェアの修正箇所の識別を行なうためのソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
真偽を評価できるステートメント。後続の判定ロジックの制御フローを決定する場合がある。
着目すべきシステムやコンポーネントを使って行なわれるタスクセットの描写。各タスクは、コンポーネント、システムと利用者のやりとりやそのときに起きる可能性のある事象に基づいて行なうことが多い。タスクは物理的というより論理的であり、複数のマシン上、ある一つのタイミングのものとして実行される。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
プロセスの開始を意図した実行ステートメント、若しくはポイントとして定義したプロセスステップ。
（たとえば、要件またはコードなどの）ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。
コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。