このセクションでは、Windows アプリケーションの UI のテストに関連するいくつかのタスクについて詳しく説明します。
紹介
アプリケーション UI の有効性と全体的な使いやすさを完全に判断するには、それをテストする必要があります。 テストでは、可能な限り幅広い対象ユーザーに対して UI を使用することがいかに簡単か困難かを明らかにします。 アプリケーションのテストにかかる時間は十分に価値があります。
このトピックでは、一般的な使いやすさ、アクセシビリティ、自動化という 3 つの主要なテスト シナリオに焦点を当てます。
ユーザビリティ テスト
ユーザビリティ テストでは、実際のユーザーが実際に製品を使用する方法を調査することで、製品を評価する機会を提供します。 この分析により、実際のデータで、意図したユーザーとインターフェイスの設計に関する主要な前提条件がサポート (またはチャレンジ) されることが保証されます。 この経験データを収集することによってのみ、製品の UI がユーザーのニーズと期待にどの程度適合しているかを確認できます。
製品に対するユーザーの操作を観察し、ユーザーのフィードバックを聞くことで、見つけて使用するのが難しい可能性のある重要な機能が特定されます。 これらの結果に基づいて、必要に応じて UI を調整できます。 結果は製品に関するより良い意思決定を行い、全体的なユーザー エクスペリエンスを改善するための基礎を提供するため、ある程度の使いやすさテストなしで有用な製品を構築することはほとんど不可能です。
ユーザビリティ テストでは、プロジェクトライフサイクル全体に十分に統合されている場合にのみ、大幅な見返りが得られます。 1 つのユーザビリティ調査で問題を特定できますが、フォローアップ テストを行わないと、ソリューションがそれらの問題を解決したか、新しい問題を導入したかを判断することは困難です。
ユーザビリティ テストの主なシナリオは次のとおりです。
- ソフトウェア製品ベンダーの場合、製品の実際のユーザーをテストすることは、設計を評価していることを意味します。 アプリケーションの設計方法に基づいて、ユーザーは必要なタスクを完了できますか? 実際のタスクを実行している実際のユーザーをテストすると、フォローしている UI ガイドラインが製品のコンテキスト内で動作するかどうか、および一貫性がユーザーの作業を行う能力を助けたり妨げたりする場合も指摘できます。
- ソフトウェア製品購入者の場合は、ユーザビリティ テストを行って製品の購入を評価できます。 たとえば、会社では 2 万人の従業員の製品を購入することを検討する場合があります。 会社が費用を使う前に、問題の製品が従業員の仕事をより良くするのに本当に役立つかどうかを確認したいと考えています。 ユーザビリティ テストは、提案されたアプリケーションが公開された UI スタイル ガイドライン (内部または外部) に従っているかどうかを確認するのにも役立ちます。 UI ガイドラインは、購入の決定を行う際の主要な情報源ではなく、補助的な情報として使用することをお勧めしています。
詳細については、「ユーザビリティの実践: ユーザビリティ テスト」を参照してください。
アクセシビリティ テスト
アクセシビリティ テストには、UI デザインの 2 つの領域 (障瞧のあるユーザーのサポートと、自動テスト フレームワークによるプログラムによるアクセス) が含まれます。
障害のあるユーザーがアプリケーションにアクセスできるようにするには、次のテストが必要です。
- コンプライアンス - アプリケーションはアクセシビリティに関するさまざまな法的要件に準拠していますか?
- 有効性 - 障瞧のあるユーザーはアプリケーションを使用できますか?
- 有用性 - アプリケーションは障瞧のあるユーザーに対して適切な機能を公開していますか?
- 満足度 - 障害を持つユーザーがアプリケーションをどのように認識するか。
アプリケーションのこれらの側面のテストは、アクセシビリティ監査を通じて実現できます。これには、アクセシビリティの専門家によるアプリケーションの手動レビューと、無効なユーザーと支援技術デバイスの重点的なユーザビリティ調査が含まれます。
一見無関係に見えますが、自動テスト フレームワークのプログラムによるアクセス要件と支援技術デバイスの要件には密接な相関関係があります。 1 つをサポートすると、もう一方を有効にできるという追加の利点があります。 Windows アプリケーションでのアクセシビリティとテストの自動化の詳細については、「アクセシビリティ の」、「アクセシビリティのテスト」、および「Windows Automation API」を参照してください。