ユーザビリティとアクセシビリティ

要求仕様から保守までのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。

身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。

それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。

イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。

レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。

一連のウェブアクセシビリティガイドラインの一部分。インターネットに関する主要な標準組織であるWorld Wide Web Consortium（W3C）のWeb Accessibility Initiative（WAI）が発行している。特に身体的な制約を持つ人がコンテンツを利用できるようにするための一連のガイドラインを …

誤ったデータを入力しても、通常運用を続けられるコンポーネントやシステムの能力。

間違った結果を生み出す人間の行為。

統合されたシステムが、特定の要件を満たすことを実証するためのテスト。

単純な10項目の質問から得られる態度尺度。使用性に関わる主観的な評価をまとめた全体的な意見を提供する。

プログラミング言語の実体。実行の最小単位。

ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。

テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。

コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。

テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。

テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。

テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。

コンポーネントやシステムのテストを実施する熟練した専門家。

テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。

達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。

全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。

1つ以上のテストケースのセット。

コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。

目標を達成するのに役立つ、一般的に認められている経験則。

（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。

プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。

テスト対象に直接関係するリスク。

ソフトウェアの取得、供給、開発、運用、保守、といったプロセスを体系的に評価すること。管理者や管理者の代理者が、進捗を監視し、計画やスケジュールの状態を判定し、要件やシステム割り当てを確認し、目的遂行用に最適化されるようマネジメントアプローチの効率を評価する。

リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。

使用性評価技法の一つ。ユーザの代表標本に、コンポーネントまたはシステムを使用した体験に基づいて、主観的評価を質問表にレポートするように依頼する。

ユーザインターフェースの設計に関わる低位レベルの固有のルールまたは推奨事項。異なる解釈が発生する余地はほとんどなく、設計者が異なっても同じ実装になる。組織がシステムを構築する際に、ユーザインターフェースの外観と振る舞いに一貫性を持たせるために頻繁に使用する。

システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。

ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。

リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。

一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、またはリスクの潜在する影響)で分類されたリスクのセット。特定のプロダクトリスクのタイプはそれを軽減(コントロール)できるテストタイプと関連付けられる。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。

ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。

将来、否定的な結果を生む要素。

プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。

特定のテストやテスト手順でコンポーネントやシステムを実行する前に満足すべき、環境と状態の条件。

設計のアプローチの一つ。ソフトウェア製品の使用に重点を置き、人的要因、人間工学、および使用性の知識や技法を適用することによって、ソフトウェア製品の使用性を高める。

ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。

使用性テストの典型的なタスクを実行する代表ユーザ。

使用性テストを実行する一連の手順を定めたドキュメント。モデレータが、ブリーフィングとセッション前インタビューの質問、使用性テストタスク、セッション後インタビューの質問の各状況を追跡するために使用する。

使用性テストにおけるテストセッション。このセッションでは、一人の使用性テストの参加者がテストを実行し、一人のモデレータがモデレートし、複数の観察者が観察する。

使用性テストを実行する活動。モデレータが指定し、使用性テストの参加者が指定期間内に完了する必要がある。

ソフトウェア製品が、特定の条件下で理解され、学びやすく、使用 しやすく、ユーザにとって魅力的である能力を判定するためのテスト。

コンポーネントまたはシステムの使用性に関わる要件。

システムを改善するため（形成的評価と呼ばれる）、またはシステムのメリットまたは価値を評価するため（総括的評価と呼ばれる）、システムの使用性に関わる情報を収集するプロセス。

指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用

あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。

コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。

コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。

制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。

システムを受け入れる判断に焦点を当てたテストレベル

ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。

使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。

品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。

コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。

専門家がレビューする非公式な使用性レビュー。専門家は、使用性の専門家、特定分野の専門家、またはその両方である。

評価方法の一種。特にコンポーネントまたはシステムが引き続き設計中である場合に、その品質を改善するために設計および使用する。

使用性テスト技法の一つ。テスト参加者は使用性テストのタスクを実行する間、自身の思考を発話して、モデレータおよび観察者に伝える。思考発話法は、テスト参加者を理解するのに役立つ。

コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。

(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。

非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。

公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)

ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

ある実体の特性を表すため、数字や種別を付加する手順。

重要な懸念、問題、または機会を特定する評価の結果。

一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

評価方法の一種。特にコンポーネントまたはシステムの設計が本質的に完了している場合に、それらの品質についての結論を収集するために設計および使用する。

ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。

コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。

コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。