要求仕様から保守までのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。
身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。
イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
一連のウェブアクセシビリティガイドラインの一部分。インターネットに関する主要な標準組織であるWorld Wide Web Consortium（W3C）のWeb Accessibility Initiative（WAI）が発行している。特に身体的な制約を持つ人がコンテンツを利用できるようにするための一連のガイドラインを含む。
誤ったデータを入力しても、通常運用を続けられるコンポーネントやシステムの能力。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
単純な10項目の質問から得られる態度尺度。使用性に関わる主観的な評価をまとめた全体的な意見を提供する。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
コンポーネントやシステムのテストを実施する熟練した専門家。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
目標を達成するのに役立つ、一般的に認められている経験則。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
与えられた状況下で、組織の作業効率に寄与する優れた手法や革新的な実践法。他の同等な組織から、「最善」と認められることが多い。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
ソフトウェアの取得、供給、開発、運用、保守、といったプロセスを体系的に評価すること。管理者や管理者の代理者が、進捗を監視し、計画やスケジュールの状態を判定し、要件やシステム割り当てを確認し、目的遂行用に最適化されるようマネジメントアプローチの効率を評価する。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
使用性評価技法の一つ。ユーザの代表標本に、コンポーネントまたはシステムを使用した体験に基づいて、主観的評価を質問表にレポートするように依頼する。
ユーザインターフェースの設計に関わる低位レベルの固有のルールまたは推奨事項。異なる解釈が発生する余地はほとんどなく、設計者が異なっても同じ実装になる。組織がシステムを構築する際に、ユーザインターフェースの外観と振る舞いに一貫性を持たせるために頻繁に使用する。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
プロダクトまたはプロジェクトの全期間をフェーズに分割したもの。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
特定のテストやテスト手順でコンポーネントやシステムを実行する前に満足すべき、環境と状態の条件。
設計のアプローチの一つ。ソフトウェア製品の使用に重点を置き、人的要因、人間工学、および使用性の知識や技法を適用することによって、ソフトウェア製品の使用性を高める。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。
使用性テストの典型的なタスクを実行する代表ユーザ。
使用性テストを実行する一連の手順を定めたドキュメント。モデレータが、ブリーフィングとセッション前インタビューの質問、使用性テストタスク、セッション後インタビューの質問の各状況を追跡するために使用する。
使用性テストにおけるテストセッション。このセッションでは、一人の使用性テストの参加者がテストを実行し、一人のモデレータがモデレートし、複数の観察者が観察する。
使用性テストを実行する活動。モデレータが指定し、使用性テストの参加者が指定期間内に完了する必要がある。
コンポーネントまたはシステムの使用性に関わる要件。
システムを改善するため（形成的評価と呼ばれる）、またはシステムのメリットまたは価値を評価するため（総括的評価と呼ばれる）、システムの使用性に関わる情報を収集するプロセス。
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。
コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
専門家がレビューする非公式な使用性レビュー。専門家は、使用性の専門家、特定分野の専門家、またはその両方である。
評価方法の一種。特にコンポーネントまたはシステムが引き続き設計中である場合に、その品質を改善するために設計および使用する。
使用性テスト技法の一つ。テスト参加者は使用性テストのタスクを実行する間、自身の思考を発話して、モデレータおよび観察者に伝える。思考発話法は、テスト参加者を理解するのに役立つ。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
ある実体の特性を表すため、数字や種別を付加する手順。
重要な懸念、問題、または機会を特定する評価の結果。
一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
評価方法の一種。特にコンポーネントまたはシステムの設計が本質的に完了している場合に、それらの品質についての結論を収集するために設計および使用する。
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。