# 使用性テスト
## 概要
- 使用性テストは、ユーザがシステムを使用して、または使用する方法を習得して、と皇帝の状況で特定のゴールに到達できるという、使いやすさをテストする。

## 測定すること
1. 有効性 - 利用者が指定された利用の状況で、正確かつ安全に、指定された目標を達成できるソフトウェア製品の能力
2. 効率性 - 明示的な条件のもとで、使用する資源の量に退避して適切な性能を提供するソフトウェア製品の能力
3. 満足性 - 指定された利用の状況で、利用者を満足させるソフトウェア製品の能力
さらに、次の属性を測定することがある
4. 理解性 - ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、およびどのように利用できるかを利用者が理解できるソフトウェア製品の能力
5. 習得性 - ソフトウェアの適用を利用者が習得できるソフトウェア製品の能力
6. 運用性 - 利用者がソフトウェアの運用及び運用管理を行うことができるソフトウェア製品の能力
7. 魅力性 - 利用者にとって魅力的であるためのソフトウェア製品の能力

## 実施するタイミング
1. 発達的使用性テスト - 使用性設計の欠陥を識別して、設計をガイドするために、設計及びプロトタイプの段階で繰り返し実施するテスト
2. 総括的使用性テスト - 開発が完了したコンポーネントまたはシステムの使用性を測定し、問題を識別するために、実装後に実施するテスト

## 担当者が備えるべき専門性、知識、スキル
1. 社会学
2. 心理学
3. 国家標準(アクセシビリティ標準を含む)への適合
4. 人間工学

## 実施方式
1. ユーザが従う手続きのセットまたは指示のセットのいずれかを提供して、大量のユーザを準備する
2. 自由形式。ユーザは自由にソフトウェアを試す。

## 実施時に用意するもの
- 使用予定のシステムに可能な限り近い状況の下で行う必要がある
- ビデオカメラを備えたユーザビリティラボ、擬似オフィス、レビューパネル、ユーザ
- 開発メンバが観察できるようにする

## 工夫
- 他のテスト(e.g. システムレベルの機能テスト)の一部として実行することがある
- ライフサイクルのすべての段階で、使用性の欠陥の検出及びレポートに関して一貫した方式を達成するには、使用性ガイドラインが役立つことがある
    - さもないと「何が受け入れられない」使用性なのか判断するのが困難になる可能性がある
- 検証可能な使用性の仕様を要件に定義し、すべての類似プロジェクトに適用する使用性ガイドラインのセットを用意することは非常に重要である
    - 例えば、プロンプトとの明確性、活動を完了するのに必要なクリック数とか、使用性の統一性あるといいよね、的な

## 使用性テストの主な技法
### インスペクション、評価、またはレビュー
- 要求仕様および設計を使用性の観点からインスペクションまたはレビューすることは、ユーザの関与を高めて問題を早期に発見できるので、費用対効果が高い方法である
- ヒューリスティック評価は設計における使用性の問題を発見するのに使用できるので、イテレーティブな設計プロセスの一部として使用できる
- この評価では、少数の評価者によりインタフェースを検証し、認識済みの使用性原則(ヒューリスティック)に適合していることを判断する
- ユーザインタフェースがより視覚的である場合はレビューがより有効である

### プロトタイプを使用した動的な操作
- プロトタイプを洗練することができ、ユーザは完成品のルックアンドフィールが期待通りかどうかを把握できる

### 実際の実装の検証と妥当性確認
- 使用性の要件がある場合、テストケースを作成して検証する必要がある
- その時、機能性のシステムテストを流用することがある
- シンタックス(文法。入力欄は入力できる)及びセマンティクス(意味。わかりやすいメッセージとか)をテストするために開発することがある
- ブラックボックス技法、特に平文またはUMLを使用して定義できるユースケースを、使用性テストで使用することがある
- テストシナリオは、テスト実行方法の説明、フィードバックを受け取るためのインタビュー実施時間、セッション実施のための合意した手続きを含む必要がある

### 調査及びアンケートの実施
- システムを操作するときのユーザの振る舞いに関する所見やフィードバックを収集するために適用する
- SUMIやWAMMIなどの標準的な調査方法を使用することにより、以前の使用性測定のデータベースに対するベンチマークを実施できる
- SUMIは使用性に関する明確な測定値を提供し、これらの測定値は完了基準/受け入れ基準のセットとなる

## アクセシビリティテスト
- 法律に準拠する必要がある
- 多くの場合、統合テストレベルで発生し、システムテスト及び受け入れテストのテストレベルまで継続する
- 欠陥として判断するのは、通常、指定した規制またはソフトウェアに対して定義した標準をソフトウェアが満たさない場合