回答。

非機能テストは、ビジネス機能の実行だけでなく、使いやすさ（ユーザビリティ）、パフォーマンス、安全性、適応性、アクセシビリティの観点からシステムを検証することです。

この質問の歴史: テストの発展初期には、「動作する/動作しない」に重点が置かれていましたが、競争の激化と製品の品質に対する要求の高まりに伴い、便利さ、動作速度、障害を持つ人々へのアクセスなどの付随的なパラメータにも注意が払われるようになりました。これが非機能テストの発展に影響を与えました。

問題: テスターはしばしば、非機能的パラメータを手動で正式に定義し評価する方法がわかりません。主観性が生じます：あるユーザーにとって便利なことが、別のユーザーにとっては不便であることがあります。明確なチェックリストや基準がないことが状況を悪化させます。

解決策: テスターは次のことを行うべきです：

• アクセシビリティのためのWCAGやユーザビリティのためのISO 9241などの標準およびガイドラインを使用する。
• テキストと背景のコントラストチェックのためのカラーアナライザーや、アクセシビリティ確認のためのスクリーンリーダーシミュレーターなどの特殊なツールを使用する。
• ユーザーエクスペリエンス、ナビゲーション、要素の可読性をチェックするためのチェックリストを作成する。
• 様々な経験を持つ実際のユーザーを引き込んでユーザーテストを行う。

重要な特徴：

• 完成したテストケースだけでなく、「生のユーザーシナリオ」で作業すること。
• 発見された非機能的問題をできるだけ具体的に文書化する必要性。
• 分析のためのサードパーティツールを使用する能力（例：Lighthouse、Axe、NVDA、JAWS、Color Contrast Analyzer）。

ひっかけ質問。

自動化されたテストがある場合、ユーザビリティの手動テストなしで済ますことは可能ですか？

いいえ。ユーザーエクスペリエンスは非常に主観的で、多くの側面は手動分析や実際のユーザーに問い合わせることでのみ明らかにされることができます。

アクセシビリティを自動スキャナーだけで確認することは十分ですか？

いいえ。自動チェックは通常、問題の20〜30％しか特定できません。他の問題は、キーボードナビゲーションやスクリーンリーダーでの読み取りなどの手動インタラクションによってのみ確認できます。

クライアントの中に障害者がいない場合、アクセシビリティをテストする必要がありますか？

はい。法律、品質基準、および製品の将来性は高いアクセシビリティを要求します。また、一部のユーザーは一時的な制約を抱えている可能性があります（例：怪我）。

一般的なミスとアンチパターン

• 影響を過小評価して非機能要求を軽視する。
• 標準への参照なしに結果を文書化する。
• 「不快」や「使いづらい」といった具体性のない表現でバグを説明する。

実生活の例

ネガティブケース

テスターはボタンのラベルの低コントラストに気付かず、色覚障害のあるユーザーはテキストを見ることができませんでした。

利点:

• テストにかかる時間の節約。

欠点:

• ユーザーからの苦情が増え、サポートへの問い合わせが増加し、評判が損なわれました。

ポジティブケース

テスターは無料のコントラストチェックツールを使用し、アクセシビリティのチェックリストを作成しました。

利点:

• リリース前にアクセシビリティの欠陥を早期に発見。
• ユーザーの忠誠心が向上しました。

欠点:

• テストサイクルの延長。
• 追加の標準やツールを学ぶ必要がありました。